On Wed, Dec 11, 2013 at 1:03 PM, Brad Chamberlain <[email protected]> wrote:
>
> 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);
>
While I have had issues with software that has used Autoconf in the past it
has been a while since that has been the case. The advent of modern
package management systems and programs like pkg-config have made their use
a lot less problematic.
> * 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);
>
>
Just like there can be poorly written Makefile based build systems there
can be well written CMake/Autoconf based systems. Most projects that use
these systems these days can be installed by running `cmake; make; make
install`. That one line at the beginning can add a lot of benefits to
users and developers alike though.
> * 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;
>
>
CMake, at least, has built in and dedicated support for cross-compiling:
http://www.cmake.org/Wiki/CMake_Cross_Compiling. It shouldn't be too hard
to tell CMake (and I imagine the same is true for Autoconf) that there are
accelerators present on the target system.
> * 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 can only speak from my own personal experience here, but I have used
CMake for my own personal projects as well as for developing Clang, and I
generally like it and prefer it to Autoconf. One added benefit to CMake is
that the most recent release adds support for generating Ninja build files,
which tend to be faster than Makefiles.
> * 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.
>
>
I believe that there are other places besides bswap.h that we could use the
functionality provided by a configuration system. One example would be the
enabling of C++11 features if a compiler is present that supports them.
RValue references and move semantics not only make code easier to read but
also provide performance improvements.
>
> 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?
>
>
I don't know why it would be considered a heavier approach than maintaining
a hand written set of Makefiles. Additionally, any attempt to provide
additional functionality in the Makefiles would be re-inventing the wheel.
CMake and Autoconf were specifically designed pieces of software for a
specialized task. It is very likely that they already provide the features
and functionality you would want to add to the current Makefile system,
with the benefit that they a) already have them and b) they have been
tested and used by others.
Using global environmental variables, such as CHPL_DEVELOPER, prevents some
common use cases. For example, when I'm working on Clang I have a separate
development and release build directory. This lets me run the test suite
very quickly in the release build directory as well as get tracing and
assert information from the development build directory. By using a
configuration system each build directory has its own setup and I don't
have to mess with command line options, Makefile internals, and
environmental variables to get things to behave appropriately.
> 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?
>
>
I have not seen evidence otherwise in Chapel specifically, but I do know
that the combination of debug symbols and asserts causes Clang's test suite
to run 3x slower when compiled in debug mode.
> 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...?
>
>
As far as I'm concerned, asserts and other developer tools should have zero
effect on the actual behavior of the compiler. Asserts are used to
double-check a property that is supposed to be ensured by other
invariants. For example, I might require a function to only be called when
a function isn't generic. This should be ensured on the caller side and
the assert on the callee side only serves to make sure I don't break that
invariant. Once the test suite passes in debug/developer mode the assert
can be discarded. If the assert isn't triggered during testing, but is
triggered in production, that indicates that the test suite doesn't cover
all of the cases it should.
> 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.
>
>
Because asserts tend to halt a program unceremoniously and refer to
locations in source code they can be less than useful to many users.
Usually you would want runtime checks that produce some diagnostics that
are useful to the user and don't require them to modify the source code of
the compiler itself. In short, asserts halt a program and a release build
of a program shouldn't halt unless it succeeded at its task or has a useful
and understandable reason for why it didn't succeed that can be fixed by
the user.
> 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.
>
>
One reason I would like a configuration system is because I have written a
more generalized tracing infrastructure for my own needs but I wouldn't
want to release it to the wider community without others being able to turn
it off very easily and still retain all of the other features enabled by
setting CHPL_DEVELOPER.
- Chris
-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
