dolfin team mailing list archive

[Johan Jansson <johanjan@xxxxxxxxxxxxxxxx>]

On Tue, Oct 25, 2005 at 09:26:39PM -0500, Anders Logg wrote:
> As you may have noticed, I have reorganized the build structure of
> DOLFIN and removed the fake installation in $toplevel/include and
> $toplevel/lib that was previously done automatically when running
> make.
> 
> Motivation:
> 
>  - Simpler and more standard build, could remove some home-made
>    scripts
> 
>  - Cleanup of Makefiles for demos
> 
>  - Demos now compile against the same installation as any user
>    programs outside of the source tree, which means that we can
>    detect errors that one would previously only see when compiling a
>    program against an installed version of DOLFIN
> 
> Consequences:
> 
>  - make install needed before make demo
> 
>  - make install needed before make test
> 
>  - make install needed before compiling PyDOLFIN
> 

> A hint for developers: use
> 
>     ./configure.local
> 
> instead of ./configure, which basically does
> 
>     ./configure --prefix=`pwd`/local
> 
> but you don't need to write it. This will configure DOLFIN for
> installation in $toplevel/local, so you don't need to specify an
> installation directory outside of the source tree when working on
> demos.

This system looks very nice, always good to clean up.

>    Compilation of PyDOLFIN is currently broken since I'm a little
>    unsure of how we want it organized. The simplest thing would be
>    to require make install of DOLFIN before compiling PyDOLFIN and
>    have a target make pydolfin like with demos and tests. The problem
>    with this solution is that one would probably like to include the
>    installation of PyDOLFIN in make install, and some of the demos
>    should run against an installed version of PyDOLFIN. So we might
>    need to do something special just for PyDOLFIN so it compiles
>    against the source tree (but not against a fake install). All the
>    needed variables are exported from configure.ac, so it shouldn't be
>    much of a problem. (But I'm unsure if the variables are exported to
>    Makefile.in or if we need a Makefile.am in src/pydolfin)
> 
> 
> /Anders

I don't know how to solve this either yet. I think we can live with
this setup for now though. The variables are exported to
Makefile.in. I didn't want to use automake since one of the targets is
a shared library, and automake has conventions which need to be worked
around in this case (it forces libtool, shared libraries have to be
named a certain way, etc.). Potentially automake can be used in the
future.

  Johan