I can't believe you guys want further screwing around with the C preprocessor. I want all that crap completely out of the system. We are very close to that.
Matt On Sun, Feb 6, 2011 at 1:00 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > On Feb 6, 2011, at 12:16 AM, Jed Brown wrote: > > > 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? > > Getting them into etags would be good. > > > > > >> On Feb 4, 2011 1:03 AM, "Barry Smith" <bsmith at mcs.anl.gov> wrote: > >> > >> > >> On Feb 3, 2011, at 1:35 PM, Jed Brown wrote: > >> > >> > On Thu, Feb 3, 2011 at 16:27, Barry Smith <bsmith at mcs.anl.gov> wrote: > >> > > >> > > >> >> 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 :-). > >> >> > >> > > >> > How to handle tests that need to actually be executed, in a batch > >> > environment? > >> > > >> > > >> >> 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?) > >> >> > >> > > >> > 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. > >> > > >> > >> 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 > >> > >> #if defined(PETSC_HAVE_FOO) where is the test of foo > >> > >> have > >> > >> #if > defined(PETSC_HAVE_FOO_BUILDSYSTEM_CONFIG_MATTSCRAZYFILE_MATTSCRAZYMETHODINTHATFILE) > >> > >> now I can always go directly to the test. Ideally the links would be > bi-directional but that is hard. > >> > >> Barry > >> > >> > >> > >> > On Thu, Feb 3, 2011 at 16:27, Barry Smith <bsmith at mcs.anl.gov> wrote: > >> > 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. > >> > > >> > 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. > >> > > >> > 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. > >> > > >> > 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 :-). > >> > > >> > How to handle tests that need to actually be executed, in a batch > environment? > >> > > >> > 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?) > >> > > >> > 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. > >> > > > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110209/404aab45/attachment.html>
