Fwd: GNU autogen code generation

[Matěj Týč]

---------- Forwarded message ----------
From: Matěj Týč <address@hidden>
Date: 28 April 2010 22:48
Subject: Re: GNU autogen code generation
To: autoconf <address@hidden>


On Wed, 2010-04-28 at 08:01 +0200, Ralf Wildenhues wrote:
> 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.

So I have posted a xz-packed distribution tarball.
http://rapidshare.com/files/382723627/autogenam-0.0.0.tar.xz.html
It works quite nicely thanks to suggestions of all of you.

>
> 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.

I am quite sure that one .tpl and .def tuple can result in multiple
files, all of them having the same basename, but possibly different
extensions.
       1. Autogen "eats" the .def file.
       2. It finds ONE .def file thanks to the information taken from the def
file and optional command line switch
       3. It looks to the .tpl file and generates results (I dare to say that
most often it is just one file per template)
       4. Multiple .def files can target one .tpl file, but I also dare to say
that it is rather a rare case.

What came to my mind, as Mr. Autogen listens, what about equipping
autogen with some "hint generator"? Like that I would pass it a
definitions file and it would tell what it is up to, so automake
wouldn't have to parse the stuff?
It would make things easier, although only that recent versions of
autogen would be supported...
How does this sound?

>
> 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.

That's interesting, I have found out that if I modify configure.ac,
Makefile.am or something else, it is recognized and autoconf/automake
are called in order to get things right after my interference.
Maybe something like that could work to express that certain Makefile.am
depends on a .tpl template?

>
> > > 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])  ?

As a side note, I have found quite difficult to find any documentation
about this macro :-)

>
> > > 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.

> > > 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'?

I was actually thinking of m4sugar and autom4te, but I meant the general
problem of generating files - like what to put to _SOURCES and how to
ensure that everything gets distributed without having to mention every
intermediate file in some variable...
I would like to be as high-level as possible, normal makefiles are
quite cryptic.

>
> Cheers,
> Ralf