Re: extending automake

On Sat, 19 Apr 2008, Bob Rossi wrote: Unfortunately, both of you are talking over my head. I don't have all that much experience with make. However, I've worked on a lot of open source projects, and all of them do this common task. They generate files during build time, and modify BUILT_SOURCES

Re: '#####' comment handling in aclocal

Hi Ralf, > http://www.gnu.org/software/automake/manual/html_node/General-Operation.html Thank you for helping me out with that link. I changed the distribution format of the Autoconf Macro Archive to avoid '#' style comments. > IIRC the rationale is that one may want to have comments that

Re: extending automake

On Sat, Apr 19, 2008 at 05:51:35PM +0200, Ralf Wildenhues wrote: > * Brian Dessent wrote on Sat, Apr 19, 2008 at 04:45:54PM CEST: > > It would be equally difficult as in the case with MULTITARGETS and > > foo_{TARGETS,SOURCES,COMMAND}, no? > > Well, the first step in exploring this further would b

Re: extending automake

* Brian Dessent wrote on Sat, Apr 19, 2008 at 04:45:54PM CEST: > Ralf Wildenhues wrote: > > > Do you mean that, given that keyword, all rules of the form > > target1 target2 : prereq ... > > command ... > > > > should be rewritten to be a multiple-target rule? > > Yeah. > > > Ugh. Th

Re: extending automake

Ralf Wildenhues wrote: > Do you mean that, given that keyword, all rules of the form > target1 target2 : prereq ... > command ... > > should be rewritten to be a multiple-target rule? Yeah. > Ugh. That would > violate the "input appears in output" quite heavily. Sure, but that's alr

Re: extending automake

* Brian Dessent wrote on Sat, Apr 19, 2008 at 03:59:19PM CEST: > Ralf Wildenhues wrote: > > > > The MULTITARGETS and foo_{TARGETS,SOURCES,COMMAND} syntax that you came > up with is certainly in line with the Automake wa

Re: extending automake

Ralf Wildenhues wrote: > This thread has some ideas: > > > If you (or anybody) finds the above useful, and think the setup is > general enough for several use cases, we can think about how to > integrate it into Automa

Re: extending automake

* Brian Dessent wrote on Sat, Apr 19, 2008 at 02:42:57PM CEST: > > That brings up the next logical point, can anyone comment on the > feasibility of some kind of generalized "tool X reads A and outputs Y > and Z" construct to help solve the "tools generating multiple outputs" > case without having

Re: extending automake

Ralf Wildenhues wrote: > Well, this scheme can easily be generalized to one stamp file per set of > output files, no? And then it parallelizes well, too. Yes, I suppose if you named the stamp with a filename derivable from that of the .xml filename you could generalize this without having to wri

Re: extending automake

Bob Rossi wrote: > verbose). Why are you not sure this is a good idea? I sort of feel like there are "workspaces", the configure area and the make area. This parallels the idea that there are configure-substituted variables and make-substituted variables, the latter can be changed/overridden whe

Re: extending automake

On Fri, Apr 18, 2008 at 09:23:59PM -0700, Brian Dessent wrote: > Bob Rossi wrote: > > I would like to automake this by writing a wrapper like, > > AM_GEN(foo.xml) > > I'm not sure that configure-time is where you want to deal with this. Wow, your answer is great, and shows how little I actually

Re: extending automake

Hi Bob, Brian, * Brian Dessent wrote on Sat, Apr 19, 2008 at 06:23:59AM CEST: > Method B, not GNU make specific, using a single witness stamp along the > lines of what is suggested in the manual: [...] > pyxml-stamp: $(PYXMLFILES) > @rm -f pyxml-tmp > @touch pyxml-tmp > (set -e;