[Top][All Lists]

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

Re: how to extend the Makefile templates?

From: Ralf Wildenhues
Subject: Re: how to extend the Makefile templates?
Date: Wed, 17 Aug 2005 11:02:25 +0200
User-agent: Mutt/1.4.1i

Hi Harald,

* Harald Dunkel wrote on Wed, Aug 17, 2005 at 10:15:57AM CEST:
> Ralf Wildenhues wrote:
> > * Harald Dunkel wrote on Tue, Aug 16, 2005 at 12:39:46PM CEST:
> > 
> >>I would need some way to add recursive targets to all generated
> >>Makefiles, without asking every owner of every
> >>to append some include statement or some keyword to be replaced

> > For other people (e.g. me), requirements such as above would be much
> > easier to understand if a good reason for it was given as well.
> > I mean, what is it that prevents you from doing something like this
> > 
> >   find $top_srcdir -name | while read file
> >   do
> >     echo 'include $top_srcdir/' >>"$file"
> >   done
> > 
> This would assume that I am allowed to change the foreign
> files,

Yes.  What prevents this?

> it assumes that this command wasn't run before,

This can easily be checked.  You also need to do this
only _once_.  And never again.

> and it assumes that there is no AC_CONFIG_SUBDIRS.

Why? This is trivial to check, too.  Oh, you mean you would
need several copies of  Well, you can adjust
the path for subpackages.  A bit more work, but still not much.

> If something like this is supposed to be run, then it
> should work on the generated files. (That
> would be the job of automake, anyway.) The
> would have to be converted into in
> $(top_srcdir), and this would break the $(top_srcdir)
> variable for all Makefiles in subdirectories.

I don't understand this.  Why can't you change
before running automake?  Is it because you are neither the
packages' author nor do you have the tools to modify the

Please clarify the reason for your seemingly unreasonable
constraints.  To me, they make no sense, because here:

> I would like to add recursive targets to extend the test
> framework (e.g. to not stop testing completely if a
> single unittest fails in a subdirectory deep inside), or
> to recursively create a coverage report, to add common
> build targets for the documentation, and so on.

What is the test framework composed of?  Simple Automake TESTS/
check_* stuff, or Autotest, or DejaGNU, or something else?

> My suggestion would be something like this: Some macro in

You suggest adding stuff to

Why is it that you may adjust (and possibly
subpackages' files?) but not files?

>       AM_ADD_TARGET([mytarget],[dependencies],
>               some
>               program
>               lines
>               could
>               go here
>       )
> It could be used to create targets "mytarget" and "mytarget-am"
> as for the existing recursive targets, to add mytarget-recursive
> to $(RECURSIVE_TARGETS), to add it to .PHONY, and so on.

I can see the usefulness of something vaguely similar to this,
but I don't see why you need it in the issue you describe.

> Of course this might introduce problems, too (e.g. when using
> recursive targets in the dependencies). It would be necessary
> to document the difference between "install" and "install-am",
> for example.

To summarize: you still have not convinced me, that the problem
you really want to solve is best solved the way you describe.
If you can make the problem space clear, there may be a chance
that someone can suggest a better way to solve it.


reply via email to

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