dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Tuesday 02 June 2009 22:52:42 Martin Sandve Alnæs wrote:
> On Tue, Jun 2, 2009 at 10:11 PM, Johan Hake <hake@xxxxxxxxx> wrote:
> > On Tuesday 02 June 2009 17:05:28 Martin Sandve Alnæs wrote:
> >> On Tue, Jun 2, 2009 at 3:17 PM, Johan Hake <hake@xxxxxxxxx> wrote:
> >> > On Tuesday 02 June 2009 14:56:45 Martin Sandve Alnæs wrote:
> >> >> On Tue, Jun 2, 2009 at 1:43 PM, Johan Hake <hake@xxxxxxxxx> wrote:
> >> >> > On Tuesday 02 June 2009 12:37:51 Martin Sandve Alnæs wrote:
> >> >> >> On Tue, Jun 2, 2009 at 12:34 PM, Johannes Ring <johannr@xxxxxxxxx>
> >
> > wrote:
> >> >> >> > On Tue, June 2, 2009 12:24, Martin Sandve Alnæs wrote:
> >> >> >> >> On Tue, Jun 2, 2009 at 10:47 AM, Johan Hake <hake@xxxxxxxxx> 
wrote:
> >> >> >> >>> On Tuesday 02 June 2009 10:28:11 Martin Sandve Alnæs wrote:
> >> >> >> >>>> I've tried to use dorsal on my home laptop which I just
> >> >> >> >>>> upgraded to Jaunty.
> >> >> >> >>>> I got some problems with trilinos (Harish: same as on my work
> >> >> >> >>>> laptop), and will recompile now after removing all
> >> >> >> >>>> trilinos.pc files around the system.
> >> >> >> >>>>
> >> >> >> >>>> I see from scons --help in dolfin that the path has been set
> >> >> >> >>>> correctly there:
> >> >> >> >>>>
> >> >> >> >>>> withTrilinosDir: Specify path to Trilinos (
> >> >> >> >>>> /path/to/withTrilinosDir ) default: None
> >> >> >> >>>>     actual: /opt/fenics904
> >> >> >> >>>>
> >> >> >> >>>> I've found two issues I will call bugs:
> >> >> >> >>>>
> >> >> >> >>>> 1) dolfin scons didn't copy the trilinos.pc it generated to
> >> >> >> >>>> the installation directory. Should be an easy fix in dolfin
> >> >> >> >>>> scons.
> >> >> >> >>>
> >> >> >> >>> This sounds strange. This line in the SConstruct file should
> >> >> >> >>> do that:
> >> >> >> >>>
> >> >> >> >>>  # We also like to install all generated pkg-config files.
> >> >> >> >>>  buildDataHash["pkgconfig"] +=
> >> >> >> >>>  
> >> >> >> >>>  scons.globFiles(Dir("#/scons/pkgconfig/").srcnode().abspath,
> >> >> >> >>> "*.pc")
> >> >> >> >>
> >> >> >> >> I can find no such line:
> >> >> >> >>
> >> >> >> >> martinal@martinal-znote:~/dev/fenics904/dolfin-0.9.2$ find
> >> >> >> >> -name SConscript
> >> >> >> >> ./data/SConscript
> >> >> >> >> ./doc/SConscript
> >> >> >> >> ./dolfin/SConscript
> >> >> >> >> ./demo/SConscript
> >> >> >> >> ./test/SConscript
> >> >> >> >> ./sandbox/ilmarw/assembler_bench/Stokes_2D_TH/SConscript
> >> >> >> >> ./sandbox/ilmarw/assembler_bench/Laplace_2D/SConscript
> >> >> >> >> ./sandbox/ilmarw/assembler_bench/ICNS_3D_Momentum/SConscript
> >> >> >> >> ./sandbox/ilmarw/assembler_bench/Elasticity_3D/SConscript
> >> >> >> >> ./sandbox/ilmarw/assembler_bench/Stokes_2D_Stab/SConscript
> >> >> >> >> martinal@martinal-znote:~/dev/fenics904/dolfin-0.9.2$ find
> >> >> >> >> -name SConscript | xargs egrep buildData
> >> >> >> >
> >> >> >> > In DOLFIN 0.9.2 buildDataHash is called ret and the line you are
> >> >> >> > looking for is 381 in dolfin/SConscript.
> >> >> >> >
> >> >> >> >>> Where is your trilinos.pc situated?
> >> >> >> >>
> >> >> >> >> Which one? I had several before, one in the path.
> >> >> >> >> scons made a new one placed in the repository,
> >> >> >> >> now I've copied that manually to the installation directory.
> >> >> >> >> The libgaleri problem is now gone after the rebuild.
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> Compiling C++ demos works fine now, but "import dolfin" gives:
> >> >> >> >>
> >> >> >> >> ImportError: /opt/fenics904/lib/libdolfin.so.0: undefined
> >> >> >> >> symbol: _Z26KSPMonitorTrueResidualNormP6_p_KSPidPv
> >> >> >> >>
> >> >> >> >> In [2]:
> >> >> >> >> Do you really want to exit ([y]/n)?
> >> >> >> >> martinal@martinal-znote:~$ c++filt
> >> >> >> >> _Z26KSPMonitorTrueResidualNormP6_p_KSPidPv
> >> >> >> >> KSPMonitorTrueResidualNorm(_p_KSP*, int, double, void*)
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> Turns out that petsc isn't handled correctly either. It's built
> >> >> >> >> and installed by dorsal,
> >> >> >> >> and dolfin scons gets the right directory for it,
> >> >> >> >>
> >> >> >> >> withPetscDir: Specify path to PETSc ( /path/to/withPetscDir )
> >> >> >> >>     default: None
> >> >> >> >>     actual: /opt/fenics904
> >> >> >> >>
> >> >> >> >> But no pkg-config file has even been generated in this case:
> >> >> >> >> martinal@martinal-znote:~/dev/fenics904/dolfin-0.9.2$ ls
> >> >> >> >> scons/pkgconfig/ boost.pc  gmp.pc  mtl4.pc  parmetis.pc
> >> >> >> >>  scotch.pc trilinos.pc
> >> >> >> >
> >> >> >> > No, because you already have one that is found in
> >> >> >> > $PKG_CONFIG_PATH.
> >> >> >>
> >> >> >> I consider this behaviour a significant bug. A new one should be
> >> >> >> generated if the $PKG_CONFIG_PATH version doesn't match the
> >> >> >> manually specified version.
> >> >> >
> >> >> > This issue is returning, again and again. An old installed
> >> >> > pkg-config file screws the construction and installation of new
> >> >> > ones. Been there me too...
> >> >> >
> >> >> > The present "solution" has been to either manually delete it or run
> >> >> >
> >> >> >  scons install -c
> >> >> >
> >> >> > The later does only remove any pkg-config files in the install path
> >> >> > and might miss out on others.
> >> >>
> >> >> That is not at all an acceptable solution, it requires that I modify
> >> >> other parts of the system, parts that I may not even have access too.
> >> >>
> >> >> > So you suggest that we should check for the version of any
> >> >> > installed pkg-config files and compare that to any manually
> >> >> > specified libraries, let it be using FOO_DIR or withFOODir?
> >> >>
> >> >> Not sure about FOO_DIR, but withFOODir is a direct command
> >> >> to the build system that should not be replaced by the default
> >> >> system-wide option.
> >> >>
> >> >> > This is probably a not so intrusive check, however we should
> >> >> > remember that caching is a feature. If we add too many checks the
> >> >> > whole point of having cached pkg-config files goes away.
> >> >>
> >> >> This has nothing to do with cache (conceptually, don't know about
> >> >> the implementation), this was the _first_ installation using dorsal.
> >> >
> >> > If you have a pkg-config file installed, scons has no way of knowing
> >> > that it should not use that. If it is an erronious system wide file
> >> > you cannot delete, we have a problem.
> >>
> >> Yes it has, I specify which directory it should use on the command line.
> >> The information is there, but the scons system _choose_ to not use it.
> >
> > As it is now dolfin scons first check if there are a package config file
> > installed in the pkg-config path. Is it there then we assume this is the
> > right one. No further checks are done, so any withFooDir informations are
> > not used.
> >
> > This goes into the whole design of the dolfin (simula) scons which is
> > centered around pkg-config. The point with the withFooDir and any FOO_DIR
> > environment variables are to help the pkg-config generators to generate a
> > suitable pkg-config file, and then install this.
>
> The consequence of this is that:
>
> 1) dolfin scons cannot generate pkg-config files for my
>     local libraries on a system with a global installation.
>
> 2) dorsal doesn't work as intended because library paths
>     are not respected by dolfin scons.
>
> 3) if somebody installs a global petsc.pc at our cluster,
>     every user must provide pkg-config files manually
>     and cannot use dolfin scons or dorsal properly.
>
> and probably many more, as witnessed by many many user problems...

Yes, and I recognize that.

> > This causes unexpected behaviours, as reported by you and others, when
> > you are used with an other system. Personally I think dolfin scons
> > reliance on pkg-config is nice.
>
> There is no conceptual conflict between relying on pkg-config as the
> fallback system
> and adhering to the command line arguments the user provides to
> override defaults.
> If this is impossible to program in dolfin scons, then something is
> seriously wrong
> in the design of either scons itself or dolfin scons.

Nothing is impossible, it just get more spagetti like (as if it wasn't from 
before :P ). The point is that pkg-config is not the fallback system it is 
_the_ system.

> > However I see two ways of solving the issue.
> >
> >  1) add an un cachable option to scons to re build all pkg-config files
> >     this will use any withFooDir variables. The generated pkg-config file
> >     will be installed and used in subsequence builds.
>
> Something like
>   scons configure withTrilinosDir=/opt/fenics904
> ?

Yes, why not? It was not what I intended. I more thought of:

  scons rebuildPkgconfigFiles

which then would rebuild pkg-config files for all included packages. Probably 
not what we want as we sometimes want to use some system wide pkg-config 
files.

> Basically an explicit configure step, but only if you ask for it directly.

This will then create a pkg-config file which will be cached and used for any 
preceding builds.

> Could we also have
>   scons build
> which skips the entire configuration phase? This takes some time today.
> Then we can have just
>   scons install # does everything
> or separate steps:
>   scons configure myoptions # no build
>   scons build # no configure, just build using cached configuration
>   scons install # full configuration check, build, install

Not sure what you mean with configuration. Configuration in our system is only 
done when there are no pkg-config files installed. In a normal scons build 
call no configuration is done. 

As we have not profiled the system I do not know what actually taking time. I 
assume you have turned of the compiler check. Then I _think_ the process of 
finding out what file should be rebuild, using md5sum check, takes some time.

It should however be possible to add some sort of configure option which only 
would try to create any specified pkg-config files.

What with:

  scons configFoo withFooDir=/here/I/am configBar 

Here configFoo will tell scons to regenerate Foo's and Bar's pkgconfig file, 
using any information available to do this. This can then be the non cached 
option discussed above.

Johan