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
