I can't believe you guys want further screwing around with the C preprocessor. I want all that crap completely<div>out of the system. We are very close to that.</div><div><br></div><div> Matt<br><br><div class="gmail_quote">
On Sun, Feb 6, 2011 at 1:00 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On Feb 6, 2011, at 12:16 AM, Jed Brown wrote:<br>
<br>
> Isn't this just making up for the editor (and perhaps static analysis challenges with Python)? As long as the definition is explicit, grep -r HAVE_FOO config/ should locate the definition. For the other direction, you can grep the source tree (fast if it's in memory or indexed). So how about a couple Emacs functions for this instead of writing fragile file system paths into the configuration macros?<br>
<br>
</div> Getting them into etags would be good.<br>
<div><div></div><div class="h5">><br>
><br>
>> On Feb 4, 2011 1:03 AM, "Barry Smith" <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
>><br>
>><br>
>> On Feb 3, 2011, at 1:35 PM, Jed Brown wrote:<br>
>><br>
>> > On Thu, Feb 3, 2011 at 16:27, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
>> ><br>
>> ><br>
>> >> Then you are not going to like my next idea. I think that "configure"<br>
>> >> tests should be imbedded directly into the source code and evaluated at<br>
>> >> compile time to determine what gets built etc. In other words no distinction<br>
>> >> between configure and build time :-).<br>
>> >><br>
>> ><br>
>> > How to handle tests that need to actually be executed, in a batch<br>
>> > environment?<br>
>> ><br>
>> ><br>
>> >> This also eliminates the possibility of "incorrect semantic information in<br>
>> >> comments" since the comments won't be "requires X Y and Z" but instead the<br>
>> >> actual tests. Having the test code for a functionality being in a different<br>
>> >> place than the use of a functionality is not a good model (the obvious<br>
>> >> problem with what I say is that the use might be in 50 places so should I<br>
>> >> have the same test in 50 places?)<br>
>> >><br>
>> ><br>
>> > And should the test be executed in all 50 places, or should the result be<br>
>> > cached? Since C code is context dependent, it would be hard to prove that it<br>
>> > was actually the same test in all 50 places, even if it resided in a common<br>
>> > header.<br>
>> ><br>
>><br>
>> Yes directly imbedding the tests is probably not practical but how about a naming convention that points directly to the test from the source. Now sometimes one has to hunt around to find the test associated with a particular #if since they could be in some many locations. For example instead of<br>
>><br>
>> #if defined(PETSC_HAVE_FOO) where is the test of foo<br>
>><br>
>> have<br>
>><br>
>> #if defined(PETSC_HAVE_FOO_BUILDSYSTEM_CONFIG_MATTSCRAZYFILE_MATTSCRAZYMETHODINTHATFILE)<br>
>><br>
>> now I can always go directly to the test. Ideally the links would be bi-directional but that is hard.<br>
>><br>
>> Barry<br>
>><br>
>><br>
>><br>
>> > On Thu, Feb 3, 2011 at 16:27, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
>> > Configure is only slow because it has grown into this monster over time; a complete refactoring should bring it down to barely a minute or so.<br>
>> ><br>
>> > Even a minute is a long time compared to 3 seconds which is what an incremental build with a couple new/modified implementation files should take.<br>
>> ><br>
>> > But configure needs to run a lot of tests which involves invoking the compiler a lot of times (it needs to run the compiler on tiny test programs to generate understandable errors as soon as possible, squashing it together into a big compilation later is bad because errors become confusing). I'm not sure that <1 minute is achievable, but I hope it is.<br>
>> ><br>
>> > Then you are not going to like my next idea. I think that "configure" tests should be imbedded directly into the source code and evaluated at compile time to determine what gets built etc. In other words no distinction between configure and build time :-).<br>
>> ><br>
>> > How to handle tests that need to actually be executed, in a batch environment?<br>
>> ><br>
>> > This also eliminates the possibility of "incorrect semantic information in comments" since the comments won't be "requires X Y and Z" but instead the actual tests. Having the test code for a functionality being in a different place than the use of a functionality is not a good model (the obvious problem with what I say is that the use might be in 50 places so should I have the same test in 50 places?)<br>
>> ><br>
>> > And should the test be executed in all 50 places, or should the result be cached? Since C code is context dependent, it would be hard to prove that it was actually the same test in all 50 places, even if it resided in a common header.<br>
>><br>
><br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener<br>
</div>