Re: Dependencies and other issues with generated files

[Stefano Lattarini]

On 06/28/2012 01:25 PM, David Sveningsson wrote:
>
>>>     app_SOURCES = test.foo main.c
>>
>> I'm not sure how well listing the .foo file in _SOURCES is going to
>> work, although someone who knows more about automake guts might be able
>> to tell us exactly what happens.  You should probably list the .c file
>> here, or in nodist_app_SOURCES if the generated source file is not meant
>> to be distributed.
> 
> The source is meant to be distributed, not the generated file. The tool
> will be required to build. Adding it to sources seems to work but maybe
> it is wrong and only works by accident.
>
Actually, this usage is covered by the testsuite (albeit undocumented),
so you should be pretty safe.  Note however that support for it has been
removed from Automake-NG (the Automake fork aimed at targeting GNU make
only).

>> Automake does not, and cannot, generate clean rules for files it does
>> not know about.  So I'm afraid that's your job.  Such rules are usually
>> pretty easy to write, for example if you have all your .foo files in a
>> variable:
>>
>>  FOOFILES = a.foo b.foo c.foo
>>
>> and the tool generates .c and .h files from a .foo file, then something
>> like
>>
>>  CLEANFILES = $(FOOFILES:.foo=.c) $(FOOFILES:.foo=.h)
>>
>> is probably sufficient.  For more involved cases, you might add a
>> --clean option to your tool which deletes any files that it generates,
>> and then call it from clean-local.
> 
> But it knows .c is compiled to .o and clean it properly. Does automake
> have such filename mappings hardcoded?
>
Basically yes, and in a quite messy way actually.  Sorry.

> Would it be possible to add a custom primary such as
> 
>     app_FOOFILES = a.foo b.foo
> 
> kind of similar to "python_PYTHON"?
>
Not without patching Automake itself.  Automake is pretty inflexible in
this regard.

> Thanks for the help so far!
> 

Regards,
  Stefano