[petsc-dev] reminder never use #include "mylocalinclude.h" in PETSc source

[Matthew Knepley]

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>