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. >> >
