As I mentioned in a previous message, I am no longer seeking the C89
standard--too many functions would need new bu_* versions.
Take malloc() as an example. Let's pretend it is not in any standard. I wouldn't create a bu_malloc() just because -std=c89 hides the declaration if I knew every C compiler since Kernigan and Ritchie scribbled "main()" on a napkin supported it. Even if it wasn't prevalent but we only ever called malloc() to allocate foobar objects, we might decide different API altogether was in order (e.g., maybe a bu_foobar() function).
It's not formal compliance merely for the sake of compliance, but for practical portability. Portability on systems that we (by definition?) don't have common access to because they are old, rare, or even don't yet exist. This means every single symbol requires review and a judgement call, but we've fortunately been down this road before with a codebase that predates all of the standards... ;)
So I am striving for C99 and POSIX 200112L together.
Okay, that's just as useful.. The trick with C99 will be Windows compilation as they intentionally have not supported many features and the different compilers have dramatically different behavior (e.g., cygwin vs msvc2008 vs msvc201X). We shouldn't cheat with WIN32 wrappers too, because that's all changing.
To get the proper function checks we need to strictly control the
compiler settings. I have found that the check_c_source_runs()
function documentation says it relies on the current setting of [snip]
but I don't think it's working correctly--hence the fallback
try_compile (and try_run if needed).
These are platform-specific (and likely never be part of a standard) ... and
But aren't fileno. fdopen, and posix_memalign covered by all POSIX <= 200112L?
Ah, and that's part of the rub. We builder testers have a limited set
of tools at hand, but I suspect we cover the bulk of the use cases
among us. Is it time for a survey?
If you go to http://www.google-melange.com/gci/org/google/gci2012/brlcad and put "compile" in the Title, it'll filter down to some of the relevant tasks. There are build logs and even some patches but they require careful scrutiny.
We should establish a set of OS/compiler/architectures for debugging,
etc., and publish what combos we test with. User's who want to run
on something different must make their wishes known (and, hopefully,
volunteer their environment for testing).
This page is relevant: http://trac.webkit.org/wiki/AdvantagesOfJenkinsOverBuildbot
Better stats, easier interface.
I notice the HACKING release section calls for a minimum of testing on
two platforms--I suggest we put a mandatory minimum "platform" and
compiler test table there.
Don't want to make anyone use any particular platform. If we need or want to get specific, we should set up a VM and test that environment. I'd like to leave it up to devs to use good judgement.
That notion as it's currently written is more about mitigating risk than providing assurance. If it's tested on at least two platforms, it's unlikely that a third will introduce any major issues (even Windows). Personally, I tend to test on three or four operating systems with at least two different compilers when it comes time to release.
And I'm happy with that, I just want it defined as C99 + POSIX 200112L
so we can stress the trunk to achieve that (all so I can use C++-style
comments!!).
That's a tricky one. MSVC will not allow // comments in C files (with /Za) and even GCC isn't technically c99-complete. Fortunately, both can be overcome but one aspect of being compliant is then being able to REQUIRE compliance from any new tools we use going forward (like how we currently require c89-compliance). Doable, but tricky.
// All the more reason we need a c89 baseline. :)
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
