On Mon, 3 May 2010 16:08:56 -0700, Barry Smith <bsmith at mcs.anl.gov> wrote: > Perhaps we should change them to use <>
I think this would be good. > It is best to keep them with their corresponding source code. > > Eventually our source code won't even live directly on the file > system nor found by looking in the file system. Prepare for PETSc-4, written entirely in Squeak Smalltalk. > BTW: the reason I cared yesterday and "complained" about the very > small number of "wrong" files was my attempt to get PETSc source into > a GUI based development system (Xcode in particular, but Eclipse and > Developer Studio are other important cases). Currently PETSc handles > active and inactive source code (depending on what configure options > are used) by "markers" in the makefiles. GUI systems don't/cannot > understand these so my solution is to build links to the active source > code that can then be easily passed to the GUI system. This breaks if > you assume the .h files are in the same directory as the .c. I recently set this up with Eclipse. No need to produce links from a mirror source tree, it builds by running make from various directories (just like we normally do on the command line). I would like to be able to algorithmically generate Eclipse targets (currently you essentially right-click, create target, and type the name of the target; this is more overhead than building from Emacs), but I don't think Eclipse supports such a thing. I did have to manually add the include path $PETSC_DIR/$PETSC_ARCH/include (and possibly other nonstandard paths found at configure time) for each "configuration", I don't know how to automate that. The semantic analysis seems to all be correct and fast. Note that the default option is for the indexer to use only the "default" configuration, rather than for the active configuration, which is not desirable if you have e.g. both real and complex configurations around. The indexer would find unresolved headers for files in the source tree that should be disabled in the current configuration (e.g. matlab), but the notification is unintrusive (you have to go looking for it) and there is never an attempt to build these files. I certainly didn't have to create a bunch of symlinks into the source tree. (My biggest problem with Emacs+CEDET is that (a) it doesn't have an AST which makes the analysis sometimes faulty and (b) it's single-threaded and doesn't have a "real" database backend so semantic analysis is painfully slow and intrusive so I have to throttle it. If only I could learn to tolerate Eclipse's limitations as an editor...) Note that there are configuration systems, perhaps most notably CMake, that make a big deal of writing native build files for many IDEs. I don't know how difficult this would be if all the build metadata was available in Python (instead of living in the makefiles located in every directory, or perhaps just by parsing those; I haven't looked at Matt's builder.py). Once that metadata is available, it shouldn't be difficult to write a non-recursive makefile. Actually, it's also possible to write nonrecursive makefiles that recursively include subdirectory makefiles (rather than recursively invoking make, much faster and actually correct), though these solutions usually use GNU make extensions (not strictly necessary, but it allows more flexibility). Jed
