On Tue, May 4, 2010 at 6:52 AM, Jed Brown <jed at 59a2.org> wrote: > 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).
All the build metadata is in an OO database in Python. builder.py extracts it in order to do the build. Matt > > Jed -- 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/20100504/874969e9/attachment.html>
