On Wed, Oct 2, 2013 at 10:09 AM, Christopher Sean Morrison <[email protected]> wrote: > Mmm, lots of goodies to discuss. Thanks Tom! > I know you've been hitting up three standards simultaneously, but does that > imply that you have any one of them (c89, c99, posix.1) working cleanly > already?
I'll try to answer most of your questions in the following ramble: As I mentioned in a previous message, I am no longer seeking the C89 standard--too many functions would need new bu_* versions. Looking at the 7 functions that don't fall under C99, 4 have bu_* replacements and the other 3 are satisfied with POSIX 200112L. So I am striving for C99 and POSIX 200112L together. >From your previous guidance, too much hackery/define fiddling inside the code is bad and we should should rely instead on the defined in brlcad_config.h which is the result of the master CMakeLists.txt. > What's the difference with the check_c_source_compiles() and > check_s_source_runs()? We should go with the simplest solution. 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: # CMAKE_REQUIRED_FLAGS = string of compile command line flags # CMAKE_REQUIRED_DEFINITIONS = list of macros to define (-DFOO=bar) # CMAKE_REQUIRED_INCLUDES = list of include directories # CMAKE_REQUIRED_LIBRARIES = list of libraries to link 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? > 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 ... > 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. 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? We can cover a lot of things with VirtualBox or other virtual hos solutions, and I now have a Mac Mini I'm going to use on my network. I don't normally "do Windows" but I could look into that. The Intel compiler for Linux is available free for Open Source work I believe. 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). 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. The buildbot we discussed some time ago would certainly help, but it's not a reality yet. > I don't think no-action is viable for any of them as that will make compile > succeed, but wrong runtime behavior. No? I agree, and have eliminated them as I am working on the C99 + POSIX 200112L compile/test. > 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 Agree. > 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. ... > 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. 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!!). Best regards, -Tom ------------------------------------------------------------------------------ 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
