dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Jun 04, 2009 at 06:19:13PM +0200, Anders Logg wrote:
> On Thu, Jun 04, 2009 at 06:10:29PM +0200, Martin Sandve Alnæs wrote:
> > On Thu, Jun 4, 2009 at 5:52 PM, Anders Logg <logg@xxxxxxxxx> wrote:
> > > On Thu, Jun 04, 2009 at 12:37:57PM +0200, Johan Hake wrote:
> > >> On Thursday 04 June 2009 12:23:59 Harish Narayanan wrote:
> > >> > Martin Sandve Alnæs wrote:
> > >> > > On Thu, Jun 4, 2009 at 11:14 AM, Johan Hake <hake@xxxxxxxxx> wrote:
> > >> > >> On Thursday 04 June 2009 10:59:39 Johannes Ring wrote:
> > >> > >>> On Thu, June 4, 2009 10:46, Johan Hake wrote:
> > >> > >>>> [snip]
> > >> > >>>>
> > >> > >>>>> 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...
> > >> > >>>>
> > >> > >>>> True.
> > >> > >>>>
> > >> > >>>>> 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 )
> > >> > >>>>
> > >> > >>>> Also true.
> > >> > >>>>
> > >> > >>>>> 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".
> > >> > >>>>
> > >> > >>>> Ok, I can discuss it with Johannes and see if there are any good
> > >> > >>>> solution for
> > >> > >>>> this.
> > >> > >>>>
> > >> > >>>> Suggestion 1:
> > >> > >>>> Trigger construction of a specific pkg-config file during compilation.
> > >> > >>>>
> > >> > >>>>   scons configFoo configBar
> > >> > >>>>
> > >> > >>>> These options will come in addition to other options. Maybe more
> > >> > >>>> explicit towards mentioning pkg-config
> > >> > >>>>
> > >> > >>>>   scons generatePkgConfigFoo generatePkgConfigBar?
> > >> > >>>>
> > >> > >>>> Suggestion 2:
> > >> > >>>> Put the generation of pkg-config files into a standalone script.
> > >> > >>>>
> > >> > >>>>   generate-pkg-config Foo Bar
> > >> > >>>>
> > >> > >>>> Instead of generate-pkg-config-file we could for example have:
> > >> > >>>>
> > >> > >>>>   dolfin-config, config?
> > >> > >>>>
> > >> > >>>> I think 1 integrates better with the present system.
> > >> > >>>>
> > >> > >>>> Any comments from the others?
> > >> > >>>
> > >> > >>> I like better suggestion 1, however, it should be possible to generate
> > >> > >>> new pkg-config files whenever withFooDir=/path/to/foo is specified on
> > >> > >>> the command line. Isn't that better?
> > >> > >>
> > >> > >> Maybee, less options is good. However as it is now this will then be
> > >> > >> cached, and scons will trigger the build each time.
> > >> > >>
> > >> > >> A solution that might work is to make that option uncachable. So
> > >> > >> whenever withFooDir=/path/to/foo is explicitly used we try to generate a
> > >> > >> pkg-config file. Anyhow that option is only used once, for building
> > >> > >> Foo's pkg-config file (if not any others are found on the system :) ) so
> > >> > >> making it an uncached option would make sense.
> > >> > >>
> > >> > >> However it is not very logical that the construction of a pkg-config
> > >> > >> file should be triggered when a directory is passed.
> > >> > >>
> > >> > >> Johan
> > >> > >
> > >> > > A related issue: it is very common to run "scons <options>", look at the
> > >> > > output, and abort the build with ctrl+c if some library isn't found. It
> > >> > > would be nice if we had a configuration step that didn't start the build.
> > >> > > This step should probably be the same as what's discussed above?
> > >> >
> > >> > And the opposite would be nice too. i.e. To be able to do scons
> > >> > <something> and not need to configure.
> > >> >
> > >> > e.g. I was having some trouble with boost and so I removed it. I then
> > >> > tried to unmake and uninstall dolfin by scons -c and scons -c install,
> > >> > and they both fail because of a lack of boost (which gets flagged on an
> > >> > unnecessary configure).
> > >>
> > >> Splitting the build and configure part is kind of logical. I think the simula
> > >> scons was built to remove the distintion between these two ;) However the
> > >> complexity of dolfin starts to require more composite logics.
> > >>
> > >> So, based on the options passed to the configuration step, enableFoo
> > >> withFooDir aso, we check whats available, create pkg-config files store them
> > >> locally. Give the user information about the result of the config step.
> > >>
> > >> The build step will then just build (or clean) what ever specified in some
> > >> cached option file, which is generated by the configure step.
> > >>
> > >> Any locally stored pkg-config files produced from the configure step will be
> > >> installed during an installation step.
> > >>
> > >> This should be possible with some refactoring of the code, but I think we need
> > >> some consensus about it. simula scons is also used by other packages too.
> > >
> > > I agree. We need configure + build:
> > >
> > > 1. The configure step checks for required packages, using pkg-config.
> > >
> > > 2. If a required package is not found,
> > 
> > OR if a specific version is requested on the commandline,
> 
> Yes.

Don't know if this was discussed, but I think that when the build
system finds a pkg-config file on the system (in PKG_CONFIG_PATH)
which it uses, then that file should be copied to the cache directory.
This directory then contains not only the generated files but all the
files that are actually used during building. The cache directory then
becomes a configuration directory rather than a cache, which makes it
very clear which configuration is used for building.

-- 
Anders

Attachment: signature.asc
Description: Digital signature