Allan Caffee wrote: > Thank you both for your speedy responses. > > On Wed, Feb 25, 2009 at 7:04 PM, Jan Engelhardt <jeng...@medozas.de> > wrote: >> In one project I use -- though not a "header + main makefile" but >> a "main makefile + subordinates" layout --: >> >> # Makefile.am (http://tinyurl.com/dhxfwf) >> bin_PROGRAMS = >> include bar/Automakefile >> include foo/Automakefile >> >> # bar/Automakefile >> bin_PROGRAMS += bar >> >> # foo/Automakefile >> bin_PROGRAMS += foo >> >> that is, setting all variables ever used to "" before appending to them. > > That is certainly one possibility. Unfortunately though that means that > in the Makefile.am files you _must_ use += since Automake will error out > if you assign more than one value to a variable (within the same > Automake conditional block). But I was hoping for away that wouldn't > require the author of Makefile.am to change their syntax. I want to > "sneak" some additional files onto the clean list. > > Hopes and dreams aside that is much cleaner for the case I provided. I > think I'll use this instead if I can't turn up a more encapsulated > approach. Thanks!
I'm not an expert on automake, but perhaps you've chosen the wrong solution to your problem: maintainer-cleaning some additional files. I would have thought target maintainer-clean-local was invented for this purpose! :) (However, I have never needed to use it.) See for instance http://www.gnu.org/software/automake/manual/html_node/Clean.html#index-maintainer_002dclean_002dlocal-751 > > > On Wed, Feb 25, 2009 at 7:36 PM, Bob Friesenhahn > <bfrie...@simple.dallas.tx.us> wrote: >> Modern automake supports += syntax. > > Modern Automake does support appending. But only appending to a > variable that has already been set. My understanding is that Automake > handles appending in a way very similar to that shown above, using temp > variables which depending on the Automake conditionals defined, may or > may not be empty. This allows it to sidestep implementations of Make > which don't allow +=. Perhaps we could just drop the error about > appending to an undefined variable and treat it as setting the variable > if not already set. I don't know how this would effect the reporting of > "multiply defined" variables though. > > The real reason I think it would be nice to have this flexibility is for > macro authors to be able to add files to be cleaned up/distributed > without requiring the users to manually add anything to their setup. So > assuming anything I just said was actually correct, how difficult would > it be to safely allow this? > > ~Allan Jeroen.
