dolfin team mailing list archive

["Johannes Ring" <johannr@xxxxxxxxx>]

Hi,

I have added a configuration step to the DOLFIN build process, making it a
three step process as requested:

    scons configure
    scons
    scons install

The last two steps can still be done in one single step, but it is not
advisable since if the compilation fails, only parts of DOLFIN will be
installed.

All options must now be specified during the configuration step, that is,
one can no longer do things like

    scons install prefix=/some/path

but one rather have to run the configure step again (with the prefix
option) and then install:

    scons configure prefix=/some/path
    scons install

(The options veryClean and DESTDIR still works outside of configure.)
The configuration options are only available in the configure step, so

    scons configure --help

will list these options, while

    scons --help

will only list the standard SCons options.

I have made no changes to simula-scons, only SConstruct and the main
SConscript are changed, however, there are plans to move more of the code
in these two files into simula-scons later.

How does this sound? I will wait with the push until we agree that this is
the behavior we want because these changes also requires me to do some
updates to the buildbot.

Johannes


On Thu, June 4, 2009 23:16, Anders Logg wrote:
> 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
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev
>