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