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 <l...@simula.no> 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 <h...@simula.no> > >> 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@fenics.org > http://www.fenics.org/mailman/listinfo/dolfin-dev
signature.asc
Description: Digital signature
_______________________________________________ DOLFIN-dev mailing list DOLFIN-dev@fenics.org http://www.fenics.org/mailman/listinfo/dolfin-dev