In case we do end up with buffers with contents at the BUFSIZ limit,
make sure we leave room to set a null termination char. Not always
clear where these buffers might get used or re-used, so just bump their
size across the board.
Getting an intermittent failure on Windows where the expscan.h header
apparently isn't present on the file system soon enough for the build to
succeed (a subsequent reinvocation of the build command does succeed.)
Try the standard technique of making another file write depend on the
outputs of the header and src file, then define a target depending on
that sentinel file and make the obj libraries depend on that target.
BRL-CAD's supporting system for building this will need some updates
once we require a newer re2c - to make testing easier in the meantime,
don't require the newer version.
This is a classic problem - the file copy will begin, the file will be
"present" in some sense on the file system, and build steps that need it
will begin - but they won't find what they actually need because the
copy isn't fully executed. The standard approach for this is to add a
second file which is only created after the first is done, and then make
the target depend on the second file rather than the first.
The relatively complicated logic trying to pull in the git sha1 id for
each build is proving fragile in some scenarios. Just go with a
simpler encoding of the defined library version.
This has proven to be more trouble than it is worth - changes
to the lexer and parser inputs are relatively rare at this point,
and different versions of re2c/lemon can break the checks.
In #359 I identify a race condition between multiple parallel invocations
of cmake, which can arise naturally during ctests. Now that the file
contents will not change without an intervening git commit, it is
sufficient to ensure that the parallel invocations use distinct temporary
file names with high probability.
As analyzed in #359, if the header contains the current time, it will
be updated while running the testsuite; this, in turn, causes multiple
cmake processes to attempt to update targets like lib/libexpress.so.2.0.0
at the same time, causing test failures.
On this platform, TEST_NULLPTR fails, even though nullptr and
nullptr_t are supported:
/home/jepler/src/stepcode/build/CMakeFiles/CMakeTmp/src.cxx:4:23:
error: converting to 'bool' from 'std::nullptr_t'
requires direct-initialization [-fpermissive]
int main() {return !!f();}
~^~
Subsequent to this failure, the workaround definitions in sc_nullptr.h
prevent standard C++ headers (which must refer to real nullptr) to fail.
The failure occurs because the C++ standard apparently does not state
that operator! may be used on nullptr. Despite this, some compilers
have historically allowed it. g++ 6.3's behavior appears to be aligned
with the standard.
As requested by @brlcad, ensure that the function 'f' is used from main,
to avoid a clever (but not nullptr-supporting) compiler from somehow
skipping 'f' altogether, creating a false positive for nullptr support.
bitbybit3d