Re: ok to use autogen to generate Makefile.in?... alternatives?

Re: ok to use autogen to generate Makefile.in?... alternatives?

[Bruce Korb]

Nathanael wrote:
> OK, I'm getting some decent reasons not to use autogen.

OK, I'm getting curious to know what they are.
I hope they are addressable.  OS/X is, as I know
it is working there.

> I have also found it rather finicky, and the dependence
> on guile does trouble me (since guile is rather finicky).

*sigh*  There was a long argument several years ago about
what language should be used as the "extension" language.
The ingrown cruft had to go, but Perl? Tcl? Guile won.
I am interested in hearing any trouble reports.

Daniel wrote:
> Nathanael, I don't think there's anything in there that you can't do
> with even the limited set of SH that we consider portable!

That is true, until you decide you want to doc the standard
targets and subdirectories, for example.  I'm sure they are
both touring complete.  :-)  The issue is flexibility, adaptability
and comprehensibility.  Just look at the "target_flags" usage
and explain how that is "easy" in a shell script.  It can
be done, I suppose.  I just think this way is cleaner.

-- 

Bruce Korb <first initial + last name at gnu dot org>
AG URL: http://autogen.sourceforge.net

Re: ok to use autogen to generate Makefile.in?... alternatives?

[Daniel Jacobowitz]

On Fri, Apr 05, 2002 at 07:47:41PM -0800, Bruce Korb wrote:
> 
> Nathanael wrote:
> > OK, I'm getting some decent reasons not to use autogen.
> 
> OK, I'm getting curious to know what they are.
> I hope they are addressable.  OS/X is, as I know
> it is working there.
> 
> > I have also found it rather finicky, and the dependence
> > on guile does trouble me (since guile is rather finicky).
> 
> *sigh*  There was a long argument several years ago about
> what language should be used as the "extension" language.
> The ingrown cruft had to go, but Perl? Tcl? Guile won.
> I am interested in hearing any trouble reports.
> 
> Daniel wrote:
> > Nathanael, I don't think there's anything in there that you can't do
> > with even the limited set of SH that we consider portable!
> 
> That is true, until you decide you want to doc the standard
> targets and subdirectories, for example.  I'm sure they are
> both touring complete.  :-)  The issue is flexibility, adaptability
> and comprehensibility.  Just look at the "target_flags" usage
> and explain how that is "easy" in a shell script.  It can
> be done, I suppose.  I just think this way is cleaner.

Obviously it's possible; I dare say the subset of SH autoconf uses is
Turing complete.  I meant that it could be done without undo grossness,
though.

As with many other languages, it's possible to write readable shell
code.  I'm sure I wasn't the only one on this list who looked at that
autogen fragment and had no idea what it did.  The syntax looks
straightforward and fairly intuitive, but I'd still be much quicker to
grasp it in shell.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: ok to use autogen to generate Makefile.in?... alternatives?

[Nathanael Nerode]

On Fri, Apr 05, 2002 at 07:47:41PM -0800, Bruce Korb wrote:
> Nathanael wrote:
> > OK, I'm getting some decent reasons not to use autogen.

> OK, I'm getting curious to know what they are.
> I hope they are addressable.  OS/X is, as I know
> it is working there.

* People want minimal and extremely portable dependencies: preferably
only things already needed
* Guile is a fairly large dependency and has suffered from
intermittent porting and installation issues
* Some gcc/gdb/etc maintainers don't like autogen.

Note that I'm still inclined to use autogen, personally.  But one of my
top priorites is to make something that the people who will have to
maintain it will be satisfied with.  (My top priority is to make
something *I'll* be satisfied with, hence the rejection of mass uses of
sed in the Makefile.)

> > I have also found it rather finicky, and the dependence
> > on guile does trouble me (since guile is rather finicky).
Oh, you'd probably appreciate examples. :-)

Warning: now going off topic for gcc list.

Some nasty finickiness showed up in writing the pseudo-macro at the top
of the template file.  Putting certain collections of comments in (the
sort on a line starting with #) broke everything mysteriously.  My best
guess -- well, actually I have no idea what caused it.

Some finickiness showed up when writing the definitions file.  I spent a
*ridiculous* amount of time debugging it.  The trouble was in the first
line.  This worked:
autogen definitions Makefile.tpl;

These didn't:
autogen definitions "Makefile.tpl";
autogen definitions 'Makefile.tpl';
autogen definitions 'Makefile';
autogen definitions "Makefile";

This didn't, but only because 'Makefile' existed:
autogen definitions Makefile;

The other irritation I've had is the curious syntax of the definitions
file.
targets = {target = "foo"; }; 
targets = {target = "bar"; }; 
targets = {target = "baz"; }; 
...
is pretty redundant.  I'd be inclined to generate it with autogen :-)
I couldn't figure out a shorter way to do it even if I gave up
target_flags.  There probably is one, but I couldn't find it.

(And if I leave out a semicolon, I get a completely opaque error
message -- 'semicolon expected' would be preferable!)

It also looks unnatural to a typical programmer; assigning to the same
variable over and over?  I'm not 100% sure what a different syntax would
be, but if I could write
targets = {"foo"; "bar"; "quux", flags="--SILLY"; "baz" }
I'd probably make a lot of the people reading the code happier, and save
a few keystrokes.

Of course, this all may be possible, or may have been rejected for very
good reasons.  Just my immediate thoughts.

--Nathanael

Re: ok to use autogen to generate Makefile.in?... alternatives?

[Nathanael Nerode]

On Fri, Apr 05, 2002 at 07:47:41PM -0800, Bruce Korb wrote:
> Daniel wrote:
> > Nathanael, I don't think there's anything in there that you can't do
> > with even the limited set of SH that we consider portable!
> 
> That is true, until you decide you want to doc the standard
> targets and subdirectories, for example.  I'm sure they are
> both touring complete.  :-)  The issue is flexibility, adaptability
> and comprehensibility.  Just look at the "target_flags" usage
> and explain how that is "easy" in a shell script.  It can
> be done, I suppose.  I just think this way is cleaner.

Although I agree that autogen is cleaner...

Doing this with a shell script may be clean *enough* for me (using the
standard that rejected massive Makefile use of sed).  Then again, it
may not.  I may mess around with it for a while.  (Hey, I always need
practice in shell script anyway...) 

For some reason, I hadn't thought of using sh script for
this before; thanks for the suggestion, Daniel. 

I'm thinking the majority of the shell script would be giant
here-documents for the static and repetitive parts.  Around each
here-document would be a short section appending it to the target file.
For the repetitive parts, there would also be nested for
loops with appropriate variable setting, and these variables would be
substituted into the here-document. 

The lack of data structures in shell script may be a problem (as
pointed out by Bruce).  The question is how easy it is to work around.
It is an important issue, since I anticipate more such
'specializations' will be needed in the toplevel Makefile.

Off to mess around...

--Nathanael

Re: ok to use autogen to generate Makefile.in?... alternatives?

[Bruce Korb]

Nathanael Nerode wrote:

> * People want minimal and extremely portable dependencies: preferably
> only things already needed

Can't blame anyone here.  Adding new tools is not in the spirit
of KISS.  My hope is to add value to make it worth that cost.
I believe I did that in the case of fixincludes.

> * Guile is a fairly large dependency and has suffered from
> intermittent porting and installation issues

That used to be the case.  I had thought they had worked
through it now.  Are there still issues?

> * Some gcc/gdb/etc maintainers don't like autogen.

:-)  Sorry.  Can't fix that.

> Warning: now going off topic for gcc list.

[[ off topic issues diverted to autogen-users list ]]

I thought I might toss in another reason for.  Assume:

>   target = { name = all; what = "all \"standard\" targets";
>     doc = <<-  END_OF_DOC
> 	Use this pseudo (phony) target to build the primary target.
> 	Sometimes there are secondary targets, too, but you will
> 	need to examine each Makefile.in to determine if that is true.
> 	END_OF_DOC;
>   };

etc.  Then consider:

> @menu[+
>  FOR target +]
> * target [+ name +]::  [+ what +][+
>  ENDFOR +]
> @end menu
> [+ FOR target +]
> @node target [+ name +]
> @subsubsection [+ what +]
> [+ doc +]
> [+ ENDFOR +]

I don't know about you, but even I feel a little hazy about the
distinction between "mostlyclean", "clean", "distclean", and
"maintainer-clean".  Why the hyphen and what happened to "clobber"?
How do we tell others what they mean and ensure that the list
is up to date?  I have an idea ... :-)

Cheers,
	Bruce
-- 

Bruce Korb <first initial + last name at gnu dot org>
AG URL: http://autogen.sourceforge.net

Re: ok to use autogen to generate Makefile.in?... alternatives?

[Bruce Korb]

Nathanael,

One other "bene" you might consider:

  http://Autogen.SourceForge.Net/doc/autogen_3.html#SEC81

Using that function will allow you to write "normal"
shell scripts and have it converted into a single-line
script, as required by make.

-- 

Bruce Korb <first initial + last name at gnu dot org>
AG URL: http://autogen.sourceforge.net

Re: ok to use autogen to generate Makefile.in?... alternatives?

[Tom Tromey]

>>>>> "Bruce" == Bruce Korb <bkorb@pacbell.net> writes:

Bruce> I don't know about you, but even I feel a little hazy about the
Bruce> distinction between "mostlyclean", "clean", "distclean", and
Bruce> "maintainer-clean".  Why the hyphen and what happened to "clobber"?
Bruce> How do we tell others what they mean and ensure that the list
Bruce> is up to date?  I have an idea ... :-)

These things are all documented in the GNU Coding Standards.

Actually, there's no explanation for the hyphen.  And of course
`clobber' isn't mentioned since it isn't part of the standards.

Tom

Re: ok to use autogen to generate Makefile.in?... alternatives?

[Alexandre Oliva]

On Apr  6, 2002, Nathanael Nerode <neroden@doctormoo.dyndns.org> wrote:

> I'm thinking the majority of the shell script would be giant
> here-documents for the static and repetitive parts.  Around each
> here-document would be a short section appending it to the target file.
> For the repetitive parts, there would also be nested for
> loops with appropriate variable setting, and these variables would be
> substituted into the here-document. 

Alternatively, you could write a Makefile.in with some autoconf
AC_SUBST_FILEs filling in the repetitive parts.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: ok to use autogen to generate Makefile.in?... alternatives?

[Daniel Jacobowitz]

On Fri, Apr 05, 2002 at 08:24:02PM -0500, Nathanael Nerode wrote:
> OK, I'm getting some decent reasons not to use autogen.  I have also
> found it rather finicky, and the dependence on guile does trouble me
> (since guile is rather finicky).
> 
> I'm going to put the key code (from the utils case) which makes me want
> to use autogen here:
> 
> (from the template file)
> # Everything from here on down is generated by FOR loops in autogen.
> [+ FOR targets +]
> # Glue for [+target+].
> [+ FOR subdirs +]
> [+target+]-[+subdir+]: configure-[+subdir+]
> 	cd [+subdir+] && $(MAKE) [+target_flags+] [+target+]
> .PHONY: [+target+]-[+subdir+]
> [+ ENDFOR subdirs +][+ ENDFOR targets +]
> # Glue for configure.
> [+ FOR subdirs +]
> configure-[+subdir+]: [+subdir+]/Makefile
> [+subdir+]/Makefile: config.status
> 	test -d [+subdir+] || mkdir [+subdir+] ; \
> 	cd [+subdir+] && $(abs_srcdir)/[+subdir+]/configure $(subconfigure_args)
> .PHONY: configure-[+subdir+]
> [+ ENDFOR subdirs +]

Nathanael, I don't think there's anything in there that you can't do
with even the limited set of SH that we consider portable!  Have you
considered a Makefile.in.sh?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: ok to use autogen to generate Makefile.in?... alternatives?

[Nathanael Nerode]

OK, I'm getting some decent reasons not to use autogen.  I have also
found it rather finicky, and the dependence on guile does trouble me
(since guile is rather finicky).

I'm going to put the key code (from the utils case) which makes me want
to use autogen here:

(from the template file)
# Everything from here on down is generated by FOR loops in autogen.
[+ FOR targets +]
# Glue for [+target+].
[+ FOR subdirs +]
[+target+]-[+subdir+]: configure-[+subdir+]
	cd [+subdir+] && $(MAKE) [+target_flags+] [+target+]
.PHONY: [+target+]-[+subdir+]
[+ ENDFOR subdirs +][+ ENDFOR targets +]
# Glue for configure.
[+ FOR subdirs +]
configure-[+subdir+]: [+subdir+]/Makefile
[+subdir+]/Makefile: config.status
	test -d [+subdir+] || mkdir [+subdir+] ; \
	cd [+subdir+] && $(abs_srcdir)/[+subdir+]/configure $(subconfigure_args)
.PHONY: configure-[+subdir+]
[+ ENDFOR subdirs +]


(and from the definitions file)
targets = { target = "all"; 
            target_flags = '$(FLAGS_TO_PASS)'; };
targets = { target = "install"; };
targets = { target = "mostlyclean"; };
targets = { target = "clean"; };
targets = { target = "distclean"; };
targets = { target = "maintainer-clean"; };

subdirs = { subdir = "spu"; };
subdirs = { subdir = "sparclite"; };
subdirs = { subdir = "wince"; };

As you can see, the double for loop makes an otherwise extremely
irritating segment fairly tidy.

Using GNU make would allow the emulation of one FOR loop, but not two.
Which might be good enough, but still leaves many repeated blocks to
synchronize. Using 'sed' inside make rules might conceivably be able to
emulate some of this, but would still leave huge blocks of similar name
pairs (see the existing top level Makefile), and would slow down the
Makefile, and make it less readable.

I could also just distribute the Makefile.in resulting from the
template, which is completely human-readable, and theoretically
human-maintainable. (I designed the template based on a specific
handwritten version, so I know it's possible -- the only irritation is 
the necessary synchronization of so many blocks, in 'two dimensions'.)

I could also write a custom program in perl with a restricted subset of
autogen's functionality specifically for this problem, which was the
approach I was originally considering before I found autogen.

This could also conceivably be done with m4, but it's beyond my talents.

There is probably a way to add appropriate functionality to automake,
but again, I don't understand automake internals very well, and it looks
like a major project.  (Plus which I'm not that fond of automake
conventions anyway.)

Thoughts?

--Nathanael Nerode