[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issues with subdir-objects enabled
From: |
Gavin Smith |
Subject: |
Re: Issues with subdir-objects enabled |
Date: |
Thu, 24 Apr 2014 16:59:51 +0100 |
On Tue, Apr 22, 2014 at 5:06 PM, Nick Bowler <address@hidden> wrote:
> On 2014-04-22 16:15 +0100, Gavin Smith wrote:
>> Is support for setting variables with names of source directories
>> after automake is run (with configure scripts, or on the command line
>> when make is run) is needed? If not, could variables in the paths of
>> source files ("$(testd)") above could be expanded when automake is
>> run?
>>
>> So Makefile currently has lines like
>>
>> include $(testd)/test-imgloader.Po
>>
>> and this would become
>>
>> include ctests/test-imgloader.Po
>>
>> with no opportunity to change the value of testd. Then config.status
>> could read the name of the file from Makefile and create it properly.
>
> Even if the value depended on configure-time substitutions (@address@hidden
> style) I think there would be no problem here (maybe other problems
> though) because the depfiles creation step happens afterwards.
>
> Make-time substitutions for this sort of thing would be exceptionally
> weird and I can't imagine it actually working properly in current
> versions of Automake.
>
> If config.status knew how to perform the variable substitutions
> I think there would be no problem. This may be too tricky to
> implement in portable shell. However, the same substitutions
> could be done by postprocessing Makefile.in so I don't see why
> it could not be done at Automake-time.
Here's my attempt at a fix. I couldn't find anything to expand
variables defined in the Automake::Variable module so I've written
code to expand these, with a maximum level of expansion in case of
cyclic definitions. One complication is that variables can be defined
conditionally, so I tried to check that they weren't. The error
messages here leave something to be desired - there may be some way of
continuing instead of having a fatal error, and the messages don't say
what source files are affected - it is not obvious how to get this
information.
expand_dependency_includes.patch
Description: Text Data