Re: GNU autogen code generation

[Ralf Wildenhues]

Hello Matěj,

* NightStrike wrote on Wed, Apr 28, 2010 at 12:49:56AM CEST:
> On Tue, Apr 27, 2010 at 4:20 PM, Matěj Týč wrote:
> > What I would like to have is some integration of autogen with autoconf
> > like YACC and LEX have.
> > Which means that I would like to specify the template and definitions
> > file in _SOURCES variable and Automake could take care of the rest:
> >        - Generating intermediate sources
> >        - Compiling those sources
> >        - Distributing both autogen sources (= templates and definitions) and
> > intermediate sources so even users who don't have autogen installed can
> > compile the source.

The first step to that is to have an example package, and hand-written
rules for everything.  So that you (and we) know the logic.  The next
step is to look at how lex and yacc are handled in automake.in, and try
to create a new language alongside that.

One semantic difference to lex/yacc handling is that here, we have two
different input files, the .def and the .tpl one.  How would
generalizations look like?  You have one .def per generated .c file but
only one global .tpl file?  Or one .tpl file per generated .c file but
only one global .def file?  Or a mish-mash?  If the latter, then the
problem is how to communicate that to automake.

automake can (and does sometimes) look into the source file contents of
the files it deals with (e.g., texinfo files are checked for
@setfilename); but such a strategy is very fragile and should be done
only if absolutely necessary.  Rationale: the user edits the file but
forgets the need to rerun automake if contents changed.

> > So i have some questions:
> >        - Wouldn't it be worth to have an AM_PROG_AUTOGEN macro since autogen
> > is GNU software?

I guess; but this doesn't have to come first.

> >        - If not, is there a way how to easily achieve similar functionality
> > using current automake capabilities?

AM_MISSING_PROG([AUTOGEN], [autogen])  ?

> > For example if I know that every file foo.def and foo.tpl pair results
> > in foo.c, maybe I could have the following rule in Makefile.am:
> > .def.c: $(basename $<).tpl
> >        $(autogen) autogen -o $@ $<

Note that this rule has a few unportabilities: $(basename ...) is GNU
make-sim, and dependencies in inference rules are not portable either.

> > But how to settle the distribution problem? I would probably need to put
> > foo1.c foo2.c to something_SOURCES
> > and
> > foo1.tpl foo1.def ... ... to EXTRA_DIST

Yes.  Well, once automake has support you would put foo1.tpl foo1.def to
foo_SOURCES and automake would put foo1.c foo2.c to some variable that
also lists distributed files.  Or, if you put foo1.tpl foo1.def in
nodist_foo_SOURCES, then automake would not distribute foo1.c foo2.c
either.

> > but one would like to have those tpls and defs in SOURCES and the rest
> > generated automatically, like for YACC and LEX.
> > What do you think?
> 
> Someone will probably correct me, but you could try putting those
> sources that you are building into BUILT_SOURCES.

I will correct you.  :-)

BUILT_SOURCES is not needed here.  It is generally only needed for
generated headers, where, with the very first build, 'make' cannot know
which object files depend upon the header, so it needs to build them
very early.

> > As a side note, I was thinking about generating code using m4 and some
> > macro package, and since it is not so uncommon to generate code, I would
> > like to ask what is the good approach to this since the automake manual
> > doesn't tell very much about this...

The Autoconf manual has chapters about using M4 idioms within
configure.ac scripts, but the resource to use plain M4 is, well, the M4
manual.  Writing rules that use m4 is not different to other plain
makefile rules, so the Make manual can help there.  Automake copies
almost all of Makefile.am to the Makefile so your rules will end up
there.  Or maybe you're asking here about 'info Automake Extending'?

Cheers,
Ralf