automake
[Top][All Lists]
Advanced

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

Re: how to extend the Makefile templates?


From: Harald Dunkel
Subject: Re: how to extend the Makefile templates?
Date: Wed, 17 Aug 2005 13:17:06 +0200
User-agent: Debian Thunderbird 1.0.2 (X11/20050402)

Ralf Wildenhues wrote:
>>
>>This would assume that I am allowed to change the foreign
>>Makefile.am files,
> 
> 
> Yes.  What prevents this?
> 

The version control system, maybe? Code coming
from another business units that I have to use
as is? Or simply because it is read-only?


> 
>>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 some_snippet.am?  Well, you can adjust
> the path for subpackages.  A bit more work, but still not much.
> 

Of course I can manually append include statements to all
files, verify whether the include statement has been included
before, or avoid some Makefile.am files when doing this. But
I could run sed over some Makefile templates, or even write
Makefiles on my own, too, so this no argument. Why not add
this functionality to Automake? Processing the Makefile.am
files is Automake's job, anyway. Surely I don't have as
much experience in m4 processing as you, but I doubt that it
is that difficult.

> 
>>If something like this is supposed to be run, then it
>>should work on the generated Makefile.in files. (That
>>would be the job of automake, anyway.) The some_snippet.am
>>would have to be converted into some_snippet.in 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 Makefile.am
> before running automake?  Is it because you are neither the
> packages' author nor do you have the tools to modify the
> package?
> 

I am not the owner of all the packages I want to include
in my project. It is a modular environment, i.e. other
projects might want to use the same modules, but with
their own configure.ac. The module developers should not
have to care about additional build targets we want to
introcude for each project (e.g. how to handle the coverage
reports, or to create purify executables, or to provide a
common test framework for all).

> 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?
> 

This is our own test framework (well, it would be, if there
would be a way to push some common code into all Makefiles).

> 
>>My suggestion would be something like this: Some macro in
>>configure.ac
> 
> 
> You suggest adding stuff to configure.ac.
> 

No, I would like to get a macro I can use in configure.ac.

> Why is it that you may adjust configure.ac (and possibly
> subpackages' configure.ac files?) but not Makefile.am files?
> 

I don't touch the configure.ac in the subpackages. The top
level configure.ac is created by using information stored in
the modules, in a file describing my own configuration
parameters, in a project configuration file, plus some
framework.

> 
>>      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.
> 

See above.

> 
>>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.
> 

I would like to have a modular solution for a problem that
(in my experience) comes up very often: How to create your
own recursive targets. I think we have the chance to improve
Automake very much here.


Regards

Harri




reply via email to

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