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

[Jed Brown]

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