dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

Thanks! Works like a charm.

-- 
Anders


On Mon, Jun 08, 2009 at 03:55:48PM +0200, Johannes Ring wrote:
> 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.
> >
> >
> 
> 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev

Attachment: signature.asc
Description: Digital signature