[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNU autogen code generation
Re: GNU autogen code generation
Sun, 2 May 2010 18:58:55 +0200
On 29 April 2010 00:04, Bruce Korb <address@hidden> wrote:
> Hi Matěj,
> On Wed, Apr 28, 2010 at 1:48 PM, Matěj Týč <address@hidden> wrote:
>> 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
> The template defines what files get output. It is entirely programmable.
> The base name may or may not be used, but nearly always is.
> And then there are the man page templates. The base name is nearly
> always wrong, since it won't match the program name.
>> 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)
> Likely, but I've had occasion where I was making 8 (??!!) different tables
> in different parts of a very large program. There were 8 output files.
> (Actually more, but that gets into stuff that is too complicated and
>> 4. Multiple .def files can target one .tpl file, but I also dare to
>> that it is rather a rare case.
> Not at all. The "options.tpl" template(s) are used by many programs.
> As are various associated man page templates.
>> 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?
> What *could* happen is to name some option to the thing similar to whatever
> gcc uses and have it emit a dependency file showing all the output files
> dependent upon all the input files. Such a patch would gratefully be
> accepted. :)
This "dependency tracking" stuff also came to my mind.
Howerer, I think that if you wont implement it, nobody ever will. I am
a student of physics and I already got involved with two open source
libraries, so I just don't have time to study another source code,
although I have the motivation.
The others here probably don't have the motivation, but maybe somebody
here knows the right way of how these things are supposed to be done
in the smart way, so maybe they could drop some advice...
I can do some m4 coding, I have already learned that pretty well, so I
think we are able to do something about this, but it seems to be
obvious to me that since AutoGen is your child, it won't be possible
without your active, maybe even "very active" :-) involvement.
>> Maybe something like that could work to express that certain Makefile.am
>> depends on a .tpl template?
> gcc does exactly that, but I believe their solution is that if you
> update Makefile.tpl
> or Makefile.def, then you are responsible for regenerating the stuff.
> My recollection
> may be wrong, though, because I didn't do that coding and it was long
> ago and far
>>> AM_MISSING_PROG([AUTOGEN], [autogen]) ?
>> As a side note, I have found quite difficult to find any documentation
>> about this macro :-)
> Mr. AutoGen is curious, to, as he hasn't played with that either. :)
OK, I have sent Ralf a minimal example using AutoGen with autotools,
and I have also sent a reply message to the Autoconf list instead of
Automake, so I have corrected that now by forwarding that message to
the automake list.
Sorry if this bothers you.
That message contains a download link for the minimal example, if you
can host it somewhere where it will last longer than 10 downloads,
please feel free to do so.
The question is what should be the next step.
What I would liketo have (and I can't imagine that Bruce wouldn't :-)
would be a "smart" and convenient support for GNU Autogen.
The current way of doing it is not particulary smart (the user has to
do quite a lot of things manually), but it should work for any simple
I can write something about this for the Automake manual, would it be OK?