dolfin team mailing list archive

[Martin Sandve Alnæs <martinal@xxxxxxxxx>]

On Tue, Jun 2, 2009 at 11:25 PM, Johan Hake <hake@xxxxxxxxx> wrote:
> 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

I don't have a problem with pkg-config being _the_ system,
but the command line interface does not give that impression.
It cannot be required that the user knows scons internals or takes
even a casual glance at the implementation of the build system...

In particular, there is no mention of pkg-config in scons --help,
README, or INSTALL, and the help messages do not suggest
that they may be ignored if the wind comes from the north:
withPetscDir: Specify path to PETSc ( /path/to/withPetscDir )

If scons makes it hard to design the interface freely, why not
have a separate script to generate selected pkg-config files?
I don't care more for "scons configFoo" than
"configure withFooDir=/here/I/am withBarDir=/here/I/am".

Whatever solution is chosen, it must be possible to say
explicitly that "hey, I want to use foolib from /bar/foolibdir,
please make me a pkg-config file for that build and ignore
any global defaults that you find".

Martin