dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

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

> Johannes