automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Include directive for all generated Makefile.in


From: Ralf Wildenhues
Subject: Re: Include directive for all generated Makefile.in
Date: Thu, 15 Apr 2010 08:02:06 +0200
User-agent: Mutt/1.5.20 (2009-10-28)

* Steffen Dettmer wrote on Wed, Apr 14, 2010 at 11:53:56AM CEST:
> On Wed, Apr 14, 2010 at 7:53 AM, Ralf Wildenhues <address@hidden> wrote:
> > > would it be a potential possibility instead to `overwrite and
> > > specialize' some macro?
> >
> > With "some macro", you mean "some prepended or appended makefile.am
> > snippet" here, right?
> >
> > Well, my idea of the above would be that if you used
> >  AM_MAKEFILE_APPEND([bot1])
>  [...]
> 
> Yes, of course. The idea is good!
> 
> > Do you have a good use case for this overwriting (that would
> > justify this complication)?
> 
> No, I don't have any.
> 
> It's just that some of our (completely unrelated) source
> generation tools (written in Perl) internally use some to write
> content. First we had some prepend/append hooks but later found
> it stronger to overwrite the content writing functions.

Well, can you give a specific example?  I can probably see that this
might be useful, but having a convincing example always helps.
Really, designing new interfaces should be done right.

We could easily have a fairly fat interface
  AM_MAKEFILE_INCLUDE([fragment], [placement], [pattern], [id])

where fragment names the file to include, placement is 'top' or 'bottom'
or so, pattern matches the Makefile.am files to affect, and id a string
or number which could mean that a later fragment with the same id will
replace the earlier one.

I am just not seeing how it can be useful.  All the decisions of which
fragments to include where _still_ have to be done at the time automake
is run, the only variation postponed to configure run time you get is
conditionals and @substitution@ expansions (as usual) within the files.

> Probably all this are examples of DONT-DOs because relying on
> internals that change without prior notice.

We are purely speaking about new, to-be-public, user interfaces here.
Things that users should be able to use with Automake 1.12.  None of
the above applies to current Automake.

> But I think this is out of scope here. Much too complicated and
> it would be more customizing automake than using a feature of it.

Well, it is true that Automake is less easily extensible than it could
be.  The above could be a step in the right direction.

Thanks,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]