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
