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
Bison and flex both fall under that category. If we don't want to change
them for historical reasons, that is fine, I understand.
However, I would guess that a majority of projects generate some source,
and they could all use the above construct. I'm guessing that most of
them have a rule like i have, a wrong one. So, the advantages would be,
- automake could safely generate the rule to ensure that tool X gets
run when it needs to (if Y and Z change)
- the rule would be hopefully correct, improving most projects
- automake could add the clean rules, and whatever other rules it
normally adds for a _SOURCES or _INCLUDES file.
So, in Mike Mueller's situation, he could do,
tool flex reads foo.l and outputs foo.c and foo.h
He would also include foo.c and foo.h in _SOURCES and _INCLUDES like
any other file, and automake would natually handle those files like
any other file. This allows people to use the new feature because they
put the .c file in _SOURCES instead of the normal way of putting the .l
file in the _SOURCES.
In my situation, I would do,
tool foo.py reads foo.xml and generates foo.h and foo.cc
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])
What do you think?
Bob Rossi
