Hi Chris -- I'll give you my take on your main question (should we use autoconf/cmake?), with the caveat that it's just my opinion. Others may disagree (and should if I'm wrong). But this probably explains why we are where we are:
* generally, as a user, I don't like installing autoconf-oriented programs -- I find it an annoying mechanism, in spite of its benefits. My preference is to engineer the things that I care about using Makefile hierarchies (which is, in large part, why we are where we are); * I think we've received far more "easiest install ever!" and "thank goodness you didn't use autoconf!" related comments from users than we have complaints (from users or developers) that we don't use it, which has somewhat served to validate my prejudices (for better or worse); * I worry about the utility of autoconf in cross-compilation scenarios (which is often the case for supercomputer settings). Autoconf-related packages seem to typically have workarounds for such scenarios that typically feel more fragile than our current infrastructure. I also worry about how useful autoconf will be in the presence of accelerators; * I don't know much about Cmake and, in my ignorance, had hoped that maybe I'd like it much better than autoconf, but the initial positive buzz I remember hearing about it seems to have been replaced with similar discontent... * I think the number of cases where we've been bitten by bswap.h has been (thankfully) small. I.e., the downsides of the current system haven't been painful enough to necessitate moving away from it, IMO. If this got worse over time (as our dependences on the OS grew or our user base was using a wider spectrum of platforms that pointed to fragility), I'd definitely reconsider my whole stance. For the specific issues you're bringing up, though (user vs. developer capabilities), autoconf seems to me like a heavy-handed solution to me -- isn't it? I.e., it wouldn't be difficult to engineer these capabilities to simply depend on whether or not CHPL_DEVELOPER is set, right? My guess is that the primary compilation overheads of Chapel are related far more to the size of the generated code/AST, and to naive algorithms (say, O(n**2) rather than O(n) choices) rather than failure to compile out any of these capabilities, which is why this hasn't been prioritized in any significant way. Have you seen evidence otherwise? Of course, the downside of changing the behavior of such things between developer- and user-mode is that any testing which the developer does will bear less resemblance to what end-user testing would produce (in the event of bugs). If there is a significant performance hit to these features then this wouldn't be a reason to keep the status quo, but if it's in the noise...? W.r.t. asserts, I think there's some disagreement within the team about whether asserts should be disabled for users or not. Personally, I'd like to see two flavors of asserts, one that would be disabled in a release and another that's always used, but I'm not sure whether anyone else agrees with me. W.r.t. the tracing for function disambiguation, I think only laziness caused me not to tie this to something like CHPL_DEVELOPER... Combined with the fact that the capabilities I added seemed unlikely to be useful to anyone other than me (which probably just means I shouldn't have committed them in the first place without making them more useful). This was done at a time that I was, admittedly, thinking less about a broad open-source community and more about our smallish group at that time. -Brad On Wed, 11 Dec 2013, Chris Wailes wrote: > In the course of my work with the Chapel codebase I've noticed that there > are some bits of code that are only of interest to developers but they are > either always compiled (asserts) or their compilation is controlled by a > macro defined in a source file (tracing for the function disambiguation > process). In the first case code that isn't needed for a release build is > included in the binary, thereby making it slower and larger. In the second > case the distinction between a development build and a release build is > actually encoded in the repository. > > Both of these issues could be addressed by using a configuration system > like CMake or autoconf that would set macros controlling the visibility of > development code. In addition, this could help with situations that arise > from developing Chapel with different compilers and library versions, like > the one we had with bswap.h. > > Is there any interest in getting a configuration system rolled out for > Chapel? > > - Chris > ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
