On Fri, Apr 25, 2008 at 09:19:58AM -0400, Bob Rossi wrote: > On Fri, Apr 25, 2008 at 06:54:08AM +0200, Ralf Wildenhues wrote: > > * Bob Rossi wrote on Fri, Apr 25, 2008 at 03:41:20AM CEST: > > > On Sat, Apr 19, 2008 at 01:22:29PM -0400, Bob Rossi wrote: > > > > They generate files during build time, and modify BUILT_SOURCES... > > > > > > > > In fact, think of the bison or flex extension (adding .y or .l files to > > > > the _SOURCES variable). That is just another use of this general > > > > functionality that I'm talking about. In some sense, it would be like me > > > > adding foo.xml to the _SOURCES, but telling automake how to turn that > > > > into a .c file. I want to run foo.py, whereas automake runs bison or > > > > flex. > > > > > > > > I'm sure that if this was implemented, a LOT of projects would use it. > > > > So, is there something I can do to help implement it, with my little > > > > experience writing make file rules? > > > > > > Ping, whatever happened to this idea? You guys think it's stupid? > > > > I don't see a way to formulate it sufficiently general so that it would > > be useful for more than just a couple of projects. > > > > bison and flex need special-cased handling in automake, how do you > > propose foo.py would not? > > I think Brian stated it perfectly, > > 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 to emit big ugly stamp rules in Makefile.am or > > ... > I know you are smart, so you must see the pattern. How hard would it be > to implement something like this? I don't know how automake works under > the hood, but I think the syntax could be something like, > AM_TOOL_GEN([toolname],[input1,input2],[output1,output2])
Hi Ralf, You busy or thing the idea is no good? Thanks, Bob Rossi