dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

Nice work! I'm about to leave for vacation, so I can only give some
quick comments (see below). I will be more helpful when I return.

/Anders

On Sat, Jul 16, 2005 at 04:53:49PM -0400, Faheem Mitha wrote:
> 
> 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.

We should probably follow Debian policy and put the static libraries
in the dolfin-dev package.

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

Even if this turns out to be a problem specific to the NSE module
(which isn't ready yet), maybe we should require that DOLFIN is
installed for the demos to compile? What happens now is that all
header files and libraries are copied (symlinked) to the include and lib
subdirectories to emulate an install of DOLFIN. The advantages of
avoiding this and do a proper 'make install' would be:

1. We could avoid the extra step of copying which is not standard
anyway.

2. Less chance of making mistakes (compiling demos in source works but
not compiling the demos against an installed version of DOLFIN).

3. We can remove the extra alternative to compile the demos in the
source tree in the demo Makefiles (and also in the script
dolfin-config).

The disadvantage would be that to compile the demos, one has to do a
'make install'. (But this could be with $prefix'=~/ or $prefix=~/local/
so you don't have to be root to do it, as long as $prefix/bin/ is in your
PATH (so dolfin-config is found).

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

You should be able to do 'make clean' and then 'make' without doing
'./configure' in between to regenerate Makefiles removed by 'make
clean'.

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

I have not used the 'dist' and 'distclean' targets much. I tried it at
some point and it didn't do exactly what I wanted so I wrote my own
scripts for creating releases (scripts/preparedist, scripts/makedist),
but we should probably take a look at this again and see if we can
make it work.

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

This wouldn't be necessary if we required 'make demo' to compile
against an installed version of DOLFIN.

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

OpenDX is also open-source and available in Debian (as package 'dx').

ParaView is open-source but not in Debian (http://www.paraview.org).

MATLAB and GiD are proprietary. I don't have access to GiD myself, but
I must confess that I sometimes use MATLAB... although I try to use
Octave most of the time.

> >>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.
> 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
> 

-- 
Anders Logg
Research Assistant Professor
Toyota Technological Institute at Chicago
http://www.tti-c.org/logg/