dolfin team mailing list archive

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

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?

Martin