dolfin team mailing list archive

[Faheem Mitha <faheem@xxxxxxxxxxxxx>]

Hi,

Sorry about the slow response.

I've now got preliminary packages for dolfin at

deb http://aurora.dulci.biostat.duke.edu/~faheem/debian/ ./
deb-src http://aurora.dulci.biostat.duke.edu/~faheem/debian/ ./

apt-get source dolfin
apt-get install libdolfin libdolfin-dev

Please test them out.

The static libraries are in libdolfin, probably in violation of Debian 
policy, with headers in libdolfin-dev as normal. However, it seems 
possible these libraries are needed at runtime. See below.

These packages still cannot be used to successfully compile the demos in 
src/demos. The problem is that not all the header file are installed by 
make install.

I am currently testing this, and see at the moment that (at least) 
dolfin_navierstokes.h, dolfin/NSEMomentum.h, dolfin/NSEContinuity.h, 
dolfin/NSESolver.h are not installed.

Please look into this. For the moment, I'd running the demos, and adding 
the installs in manually as the errors occur.

Replies/comments to previous message follow.

On Thu, 7 Jul 2005, Anders Logg wrote:

> On Thu, Jul 07, 2005 at 09:12:28PM -0400, Faheem Mitha wrote:

> > I see quantities of stuff that does not get removed. Among these, lots of
> > Makefiles and .a files in src.

> The Makefiles are generated by configure, so these can't be removed by
> make clean. It's not a good thing to have a Makefile remove itself... :-)

I don't see why. Can you give me a reason?

> The .a files in src should be removed by make clean. They do for me
> when I do make clean.

Not for me. Did you check this with a version control system? Actually, 
I'm using distclean. Is that not recommended?

> > Also, 'include' and 'lib' directories are created at the top level of the
> > source tree, and header and library files respectively are put in them.
> > These are not removed either.
>
> The symbolic links in include and lib are generated by make in
> src/post/Makefile, by calling src/post/libs.sh. I guess it should work
> to put in an extra target clean in src/post/Makefile.am and a suitable
> script that removes the symbolic links.

That would be good. Then I could simplify my clean target in debian/rules.

> > Would it not be easier to put these files directly into the install
> > targets? Why is it necesary to create these directories?
>
> Because then we can build all demo programs in src/demo as if DOLFIN
> was installed on the system. This emulates an installation of DOLFIN
> without having to do a make install.

Ok.

Currently, I'm working around the fact that src is not actually cleaned by 
'make clean' by the ugly hack of moving src/ out of the way before 
anything else is done, and moving it back when the 'clean' target in 
debian/rules is called.

It would be nice if something like this could be avoided, by having a 
clean target that actually cleans src/ completely.

> > 2) Some files look like they should not have been shipped with the source.
> >
> > There are some Makefiles in the demo directories, though these, like all
> > the others, look like they created by automake/autoconf, since there are
> > Makefile.am and Makefile.in's present.
>
> In src/demo/ we have generated Makefiles in all directories not
> containing code. At the bottom level, each demo program has a simple
> hand-written Makefile which is not generated. The idea is that if
> someone wants to write a simple program using DOLFIN, they can just
> copy the code in a demo directory along with the Makefile. (Or they
> can use their own build-system.)

Ok.

> > Also, was it necessary to ship config.guess and config.sub? These files
> > appear to be modified by the build. I'm fairly clueless what these are
> > used for, sorry.

This build modification was an error on my part. The template generated by 
dh_make had some lines which modified these. Not sure why.

> > 3) I can try to figure out the build-depends and depends on my own but I
> > am lazy. So, can someone tell me what they should be?
> >
> > Build-Depends: Required at build time.
>
> The ones I can think of right now are libxml2-dev (Debian package) and
> PETSc version 2.3.0. There are probably other stuff we depend on that
> is more standard.

As it happens, there is other stuff, some of which your configure script 
should probably detect, but curently doesn't.

The following list of build dependencies was generated with the help of 
pbuilder. Build, wait for failure, add to build-depends. Repeat.

debhelper (>= 4.0.0), libxml2-dev, libpetsc, libncurses5-dev, mpich-bin, 
libmpich1.0-dev, lapack3-dev, refblas3-dev | atlas3-base-dev

Note that the configure script does not look for anything after PETSc, as 
far as I can tell. Adding tests for the other things should be easy.

> To work with variational forms, one needs to have the FIAT 0.2.3 and
> FFC 0.1.9 from the FEniCS web site installed. These in turn have
> dependencies. It's not necessary to have FFC and FIAT to use DOLFIN,
> but some parts of DOLFIN require it.

Can you specify which parts of DOLFIN require these? I'll hold off 
packaging these till I've experimented a little bit with DOLFIN.
[snip]

> Something for visualization (MATLAB, Octave, OpenDX, GiD, Tecplot or
> Paraview/VTK). This is more post run-time.

Most of these look proprietary. Perhaps Octave in a suggests?

> > 3) DOLFIN only creates static libraries by default. How can one generate
> > shared libraries?
>
> We should learn to use libtool and generate shared libraries. This is
> something we have to learn how to do, and it will take more than 5
> minutes.

Ok.

One (fairly important) question with regard to this. If I link against the 
DOLFIN static libraries, then should I still require these libraries at 
runtime? I'd have thought not, but based on preliminary evidence, this 
does not appear to be the case.

                                                              Faheem.