dolfin team mailing list archive

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

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,

> it tries to generate the
> pkg-config file.


> 3. The build step just builds, using pkg-config to get libraries.
>
> This way, caching is the same as stored configuration so there should
> be little confusion about caching.

Martin