dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Sun, Jul 17, 2005 at 06:12:17PM -0400, Faheem Mitha wrote:

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

Perhaps this is what distclean should do.

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

Yes, they are created automatically by automake/autoconf so they are
already there (but not in use and not tested).

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

Great!

/Anders