Mmm, lots of goodies to discuss. Thanks Tom!
With my mods over the last couple of week I believe I have almost
fulfilled the requirements for demonstrating strict standards
compilation and testing for the BRL-CAD trunk. Basically my mods so
far have been:
realpath
This is a BSD4.4 oldie so it should be okay to use when it exists regardless of conformance. If the function exists but is not declared when a standard is being enforced, we can just declare it (in brlcad_config.h).
gethostname
Ditto. It's even older.
strcasecmp
strncasecmp
fdopen (POSIX.1-1990)
fileno (POSIX)
These are platform-specific (and likely never be part of a standard) ... and we rely on them pretty extensively. We also cannot implement them (because they would be different for every version of libc we encounter) nor stub them empty (because we rely on them). The fdopen() function can just be declared when it's not available like the above, but fileno() may be tricky as it's usually a macro.
Lets leave fileno() for last. We should look at how we might create BU api that avoids the usage altogether (i.e., not bu_fileno() but bu_something_else() that encapsulates what it was being used for).
posix_memalign (POSIX.1d)
I have no-action replacements
for the other 3 if wanted.
3. Added reliable CMake code to test for those 7 functions. Note
that the CMake try_compile and try_run functions are the ones I
believe should be used for rigorous function testing in order to
properly control the compiler setting for consistency.
What's the difference with the check_c_source_compiles() and check_s_source_runs()? We should go with the simplest solution.
As an aside, I think it's important to keep build infrastructure separate from our source code, which would imply either moving the new compat dir into misc/CMake/, embedding them like our other tests (e.g., see the HAVE_THREAD_LOCAL testing), or integrating their testing into stand-alone proper cmake modules of their own (best, but most work).
I see the changes Cliff just made to CMake and I don't really
understand. IMHO, the goal should be the strict use during
debug--otherwise I don't see how we ever advance. Those standards
have been around for over 10 years! To quote Bjarne Stroustrup (from
the 4th edition of "The C++ Programming Language" [C++11]), page vi:
"if you stick to older styles [standards], you will be writing
lower-quality and worse-performing code.
I agree and don't think anyone is suggesting we stick to older standards. However, we can't break the build or cripple runtime while issues are sorted out. The defaults for Debug and Release compilation need to succeed with no ill-effects on runtime. As far as I understand, we don't yet have that at any level, so we need a flag. That was the motivation for suggesting a "compliance" flag that lets us turn on the next level being chased.
I think I've said it before, but remember the goal isn't to remain compliant with multiple standards nor to support strict c89 in perpetuity. It's to baseline on a standard, fully chase it down, demonstrate it with some timeframe of stability, and then move on to the next one. Once compliant, we can add it to distcheck-full or make it the default so that it stays compliant until we get the next level fixed.
Note that this all will need to be tested not just cross-platform but with more than gcc+llvm. The Windows, Intel, and IBM compilers come to mind, maybe Embarcadero too. If we did things right, compilers that didn't work before should start working.
Please let me know if I'm misunderstood anything. It's great to see this progress being made.
Cheers!
Sean
------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
_______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
