dolfin team mailing list archive

[Harish Narayanan <harish.mlists@xxxxxxxxx>]

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).

Harish