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

[Barry Smith]

On May 4, 2010, at 4:52 AM, Jed Brown 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).

    Cannot do this with Xcode.

>  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.

    Same problem for Xcode.

>  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).

    I want to get rid of make/makefiles completely.  Just use python.

    Barry

>
> Jed