-
Notifications
You must be signed in to change notification settings - Fork 41
Description
build subdirectory of this project is an exception to the convention that header-only libraries do not have that. This forces to check for this exception in some parts of Boost's build scripts e.g. (https://github.com/boostorg/boost/blob/master/Jamroot#L264-L266).
I wanted to move these maintenance rules to build.jam and eliminate the exception. But it turns out the rules depend on Wave, which would result in this project depending on Wave, which is obviously bad.
But then I tried building the targets, which failed, so I looked closely at the rules.
Line 14 in 6fba35a
| W = ../../../tools/wave/build//wave ; |
../../..tools/wave is not a thing. I guess, it was a thing in 2009. The actual (relative) location of the tool today seems to be ../../wave/tool/build.
Line 11 in 6fba35a
| $(>[1]) -S../../.. $(>[2]) -o $(<) |
Uses source 1 as the program, and source 2 as the preprocessed file. But Target definitions instead pass the file to preprocess as the first argument, and the preprocessor as the second.
Line 17 in 6fba35a
| : preprocess_arity_loops.cpp $(W) : wave : <location>build/timestamps |
Targets are put into build/timestamps subdirectory of the build project. So, the rules do not update build/timestamps/whatever, they create build/build/timestamps/whatever.
Line 11 in 6fba35a
| $(>[1]) -S../../.. $(>[2]) -o $(<) |
That
-S../../.. thing adds an include directory. That's not an include directory of FunctionTypes, and even if it was, that's not enough, because FunctionTypes has dependencies.
Given all that, build/Jamfile has no chance of performing its function. My intuition is that nobody has used it in at least 17 years (since the commit that introduced most of the stuff mentioned above). So, I suggest the entire directory is removed.