dolfin team mailing list archive

[Faheem Mitha <faheem@xxxxxxxxxxxxx>]

On Sun, 17 Jul 2005, Anders Logg wrote:

> On Sat, Jul 16, 2005 at 04:53:49PM -0400, Faheem Mitha wrote:

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

Agreed.

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

I think that would be a good idea. It would make life easier for 
packagers, for one thing.

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

Ok. But how about creating another target that returns the tree to the 
preconfigure state? Perhaps 'make allclean'? This is useful for packagers, 
who otherwise have to write their own clean target, which is messy and 
inefficient.

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

I don't follow. Were the dist and distclean targets created automatically 
somehow then?

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

True.

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

I see someone filed a wishlist bug for it in April.

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

Ok, I'll add OpenDX.                                       Faheem.