Hi People,
There is an active debate which started in autoconf-patches, and moved
into private messages between Alexandre and I.
We agreed we should have this thread public, and it is included below.
The first message tries to summarize the issues, but it also includes
my own opinion, which is not quite fair. For your information:
<<-
Akim> Alexandre, I think our debate is interesting enough to be make
Akim> public. Would you mind if we send all this thread to autoconf@?
Alexandre> Absolutely. (no, I wouldn't :-)
OK, I'm sending the digest this message being included.
Alexandre> Except for the minor issue that it starts with a message
Alexandre> that presents the two proposals with a clear favoring of
Alexandre> yours. But I can live with that.
I'll send the digest with the <<-lines->> included as a prologue.
->>
Akim
Subject: Topics
Topics:
Autoconf Extension Files
Re: Autoconf Extension Files
Re: Autoconf Extension Files
Re: Autoconf Extension Files
Re: Autoconf Extension Files
Re: Autoconf Extension Files
Re: Autoconf Extension Files
Hi Alexandre,
Well, I believe this time we might need a referendum on this issue?
Below is a draft of a message I intend to send to autoconf@ to try to
see what people think about it.
Personally I can change my mind, but if I'm convinced. Up to now,
although I think I can feel what you feel, I am still not convinced
1. my scheme is hard to learn, 2. yours is easier.
What do you think of this:
Subject: Autoconf Extension Files Handling
Hi People,
We are revamping autoreconf.
autoreconf addresses several issues. One of its tasks is in general
addressed by the Makefile: update files which dependencies have been
updated. Another task it addresses is what scripts like `compgen.sh'
or `bootstrap' do: starting from a hand written files only, run
aclocal, autoconf, automake, libtoolize, gettextize, autoheader etc.
We are in the process of replacing aclocal. As a first sketch,
autoreconf handles by itself what used to be done by aclocal. We can
still debate whether the processing should be done within autoreconf,
or if autoreconf should delegate the task to another tool, but there
is another point, more important, where there are two different
proposals:
how to handle the Autoconf extension files (aka m4/*.m4).
The Separate Files Approach
---------------------------
All the extension files are automatically imported into an m4/ (or
whatever the name) directory, and aclocal.m4 is merely a set of
m4_include of these files: there is no dependency upon non Autoconf
macros which are not in the local tree.
Of course this means that the maintainer must ship these files. It
can be totally automated by Automake, but it's not written yet.
The maintainer has nothing to do at all to ensure the completeness
of the local copies/symlinks of the extensions files, but if she
disagrees, she just has to rm, cp or ln what ever version she wants.
In particular the maintainer need never modify aclocal.m4 manually.
The All Mighty Aclocal Approach
-------------------------------
Aclocal.m4 is controlled by the maintainer either by hand, or via a
new tool à la aclocal. This file has well defined sections via tags
(BEGINNING OF.../END OF...), which makes it possible to have
1. sections written by hand, 2. definition of macros coming from
library extensions files, 3. some m4_include just as in the previous
scheme.
The maintainer has to maintain aclocal.m4 manually (either via
editing, or thanks to options such as --update-inner-m4-file init.m4
etc.), and the local extension files too. But if she doesn't use
m4_include at all, the dist rule just needs to ship aclocal.m4,
which is what Automake does.
I am opposed to the second approach. Before criticizing, let's
present the pros:
1 Some young developers such as Joe D. Velopper, will probably shoot
himself in the foot and forget to ship the extensions files because
Automake does not support it yet. Even more likely if he doesn't
use Automake.
2 Why the heck should I see so many little extension files pollute my
local directory where a single file will do?
My cons:
Answering 1., I just don't want to consider the limitations of the
other tools as a real argument. Let's work on Automake instead. And
if those people are not using Automake, then they will be able to use
the samples we provide in the docs. In addition, frankly, anybody
using Autoconf and Automake is not just Joe D. IMHO, he'll be smart
enough to know what to do. And after all shipping one broken package
is no big deal, someone will just tell him what happened, and he'll
fix his package.
Answering 2., there is AC_CONFIG_AUX_DIRS, which can (and should) be
used to hide those files. Maintainability is much more important than
the number of files.
Why do I want the separate files approach?
Well, first of all because there are already too many tools, and too
many options to learn to have the Autotools work properly, we just
don't need another choice. IMHO there are places where additional
choices are just additional entropy: packages will start being
different uselessly, you'll have to study the configure set up to find
the proper options to pass to the tools etc. Here, cp, mv and ln is
the only interface I want to deal with, I see no reason for
introducing another tool which mimics this via options.
I really don't think I am being Mike X. Pert here, think of Joe who
will have to learn all this too! Just imagine the learning curve for
another tool with several options, as opposed to cp, mv, ln. I do
think Mike and Joe will agree this is much simpler.
Since I want a single unified approach, the separate files approach
seems the natural answer: that's basically what everybody does. And
people do this because these files are actually very alive, and often
need editing. Since, in addition, these files can come from a lot of
different places, it is important to keep them separate.
But after all, I mainly explained why I think the multiple files
scheme should be possible. You could imagine some flags set once for
all that tell this new tool that you wish to stick to the multiple
files scheme, then why prevent people from using the other scheme if
they wish?
Because I really don't think we need two answers to a single need.
That makes the tool(s) more complex. It means more documentation to
write, more software to write and maintain for us, and for the user it
means more documentation to read, and additional means to misuse a
tool. We shouldn't provide choices when they are not needed. Making
the choice for the user means we asked ourselves the questions, and
answered them. We are probably more knowledgeable than he is, we have
some experience he doesn't have. One way to help him is to make
choices for him. One way to help him is to have him read a limited
amount of documentation, use a single tool, and still have a set up
like the grownups.
Thanks for taking the trouble of summarizing the points, and for
running them through me first. It made it clear that part of my
suggestion didn't make it to you.
On Jul 31, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> 1. my scheme is hard to learn, 2. yours is easier.
I don't think your scheme is harder to learn. It's just easier to
make mistakes using it. It doesn't help ensure that starters do The
Right Thing, which is to ship all the m4 sources. That's the main
advantage of the scheme I propose. I understand it's a little bit of
additional work for advanced users, but they can afford it, starters
can't, and will probably blame autoconf for the mistake, and I'll
agree with them.
> We are in the process of replacing aclocal. As a first sketch,
> autoreconf handles by itself what used to be done by aclocal.
I don't think this is a good idea. IMO, we should do aclocal.m4
maintenance in a separate program, that autoreconf would run. Where's
that argument for keeping things separate again? :-) :-)
> All the extension files are automatically imported into an m4/ (or
> whatever the name) directory, and aclocal.m4 is merely a set of
> m4_include of these files: there is no dependency upon non Autoconf
> macros which are not in the local tree.
So the user can no longer write code in aclocal.m4? How about
existing packages that already have m4 code in aclocal.m4? How about
those using automake, that have the extension code in acinclude.m4
copied to aclocal.m4? These are issues we have to consider when
proposing the change, under the principle of backward-compatibility
we've all sworn to abide to :-)
> The maintainer has nothing to do at all to ensure the completeness
> of the local copies/symlinks of the extensions files
He has to run autoreconf or the new aclocal, just like in the ``All
Might Aclocal'' approach. This can't be used as an argument in favor
of your proposal.
> In particular the maintainer need never modify aclocal.m4 manually.
Ditto. s/need/needs/
> The maintainer has to maintain aclocal.m4 manually
Nope. It's just like autoreconf, but, instead of copying files and
inserting m4_include statements, the tool will insert the files
inline. From the point of view of the user, there's no difference at
all, except that he won't have to worry about including additional m4
files in the distribution (i.e., no difference at all, if using
automake).
> I am opposed to the second approach.
I'd prefer that personal positions didn't show up in neutral
expositions.
> 2 Why the heck should I see so many little extension files pollute my
> local directory where a single file will do?
I'd rephrase this as: most of the times, the maintainer only cares
about the macros as a user, i.e., he only needs their definitions, he
doesn't really care about how they're defined, what other macros in
what other files they depend upon, whether definitions are given in
different files on different releases of the packages that supply the
macro definitions. He often doesn't intend to to modify them locally.
Having all the needed definitions centralized in a single aclocal.m4
means he won't have to have files he doesn't understand or really care
about in his distribution. Not a big deal, but new users might be
frightened by the amount of ``junk'' in his package.
> In addition, frankly, anybody using Autoconf and Automake is not
> just Joe D.
All of us have, at some point, been a Joe D. when we started using
autoconf. We've all struggled to understand its assumptions. Why
should we make it any harder by telling them not to forget to include
any extension files besides aclocal.m4, if they happen to use any
extension macro?
If you were a starter, using autoconf 2.13, wouldn't you just copy the
macro file you want to use to aclocal.m4 and be done with it? If you
were given the ability to m4_include files, would you still create
aclocal.m4 with a sole m4_include statement, and keep the m4 file
separate? I think I wouldn't. I'd rather keep it simple.
> And after all shipping one broken package is no big deal, someone
> will just tell him what happened, and he'll fix his package.
Or say he doesn't care, the macros can be downloaded from the macro
repository and from this and that packages. Or blame autoconf and
become resistant to use it for other projects.
I've had enough trouble with people of the Kaffe team finding issues I
considered very minor to be major annoyances, to the point of the team
being strongly inclined to drop libtool, automake and possibly
autoconf from the Kaffe building engine. I'm *very* concerned about
introducing one more minor issue.
> Answering 2., there is AC_CONFIG_AUX_DIRS, which can (and should) be
> used to hide those files. Maintainability is much more important than
> the number of files.
For people who care about maintaining the files, I agree completely.
But abstraction is also a very important issue that you're failing to
consider.
> Well, first of all because there are already too many tools, and too
> many options to learn to have the Autotools work properly, we just
> don't need another choice.
This is no argument in favor of your choice. We will need another
tool, the difference is on what this tool is going to do.
> packages will start being different uselessly
Isn't this an argument in favor of having a single aclocal.m4 per
package? Then, they'll be more similar.
> you'll have to study the configure set up to find the proper options
> to pass to the tools etc.
Again, this is an argument in favor of the all-mighty aclocal.m4.
> Here, cp, mv and ln is
> the only interface I want to deal with, I see no reason for
> introducing another tool which mimics this via options.
The point you're missing is that most users *won't* be using cp, mv
and ln, they'll be using whatever aclocal tool we provide them with.
cp, mv and ln to modify m4 extension files are for Mike X. Pert.
> I really don't think I am being Mike X. Pert here, think of Joe who
> will have to learn all this too!
But he shouldn't have to learn all this to start using autoconf.
> Just imagine the learning curve for another tool with several
> options, as opposed to cp, mv, ln.
Precisely.
> Since I want a single unified approach, the separate files approach
> seems the natural answer: that's basically what everybody does.
Which everybody are you talking about? What research have you done to
conclude this? I'll give you a very simple example. I've just
started helping a Russian user use autoconf for the GNU marst package.
He'd never had any previous experience with autoconf. He's not even
using automake. Go figure the way GNU marst's build environment is
structured. You may even want to ask him what he'd prefer.
> And people do this because these files are actually very alive, and
> often need editing.
For those people who maintain them. Those that don't are just users,
and we shouldn't require them to become maintainers of those files
too. Abstraction is the key.
> Since, in addition, these files can come from a lot of different
> places, it is important to keep them separate.
They'll be separate, just in a single file. Are you arguing for us to
stop shipping tarballs and instead post every file in separate in
ftp.gnu.org? What's your point?
> Because I really don't think we need two answers to a single need.
It's not a single need. What you're failing to see is that there are
different kinds of autoconf users. There are those that maintain
their own set of m4 extensions, who *want* their macros to be in
separate files, and those that just use them, who care about the
macros, and would rather abstract the very existence of files away.
> for the user it means more documentation to read
Which solution are you arguing for, again? Previously, you said that,
in order to have multiple m4 files, the user would just have to follow
our example in the documentation, and he might well miss that point.
With the all-mighty aclocal.m4, that wouldn't be necessary.
> and additional means to misuse a tool
Ditto.
> We are probably more knowledgeable than he is, we have some
> experience he doesn't have.
But we shouldn't force him to become as knowledgeable as we in his
first project. Let's give him time to learn why it's better to have
separate m4 extension files when he maintains his own set of extension
macros. Meanwhile, he'll live with a solution that abstracts away
this issue for him.
> One way to help him is to make choices for him.
If they're the right choices. I don't think they are, for a beginner.
--
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 *Please* write to mailing lists, not to me
| Thanks for taking the trouble of summarizing the points, and for
| running them through me first.
You're welcome :) I like working with you. In fact, if we go to the
referendum, I'd like that we have a common document, or at least
something ``objective'', and then our comments.
| It made it clear that part of my suggestion didn't make it to you.
Hm, I'm not sure I understand this :( Is it
it made it clear that there are arguments for my suggestion
that you don't know/don't consider.
or something like this?
| On Jul 31, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
|
| > 1. my scheme is hard to learn, 2. yours is easier.
|
| I don't think your scheme is harder to learn. It's just easier to
| make mistakes using it. It doesn't help ensure that starters do The
| Right Thing, which is to ship all the m4 sources. That's the main
| advantage of the scheme I propose. I understand it's a little bit of
| additional work for advanced users, but they can afford it, starters
| can't, and will probably blame autoconf for the mistake, and I'll
| agree with them.
Personally I don't think it is so likely, but it is, definitely, but I
really can't imagine something big happen because of this. I don't
see much difference with `forgetting' to distribute the Bison sources,
or acconfig.h etc. All this are common errors, and I'm somewhat
against a Fisher Price Autoconf just for this :)
| > We are in the process of replacing aclocal. As a first sketch,
| > autoreconf handles by itself what used to be done by aclocal.
|
| I don't think this is a good idea. IMO, we should do aclocal.m4
| maintenance in a separate program, that autoreconf would run. Where's
| that argument for keeping things separate again? :-) :-)
There is none. I don't see much point in having a separate program,
but I don't see much against it either. From the point of view of the
documentation it just means moving some of autoreconf elsewhere. I'm
really fine with it, and I also agree it's more open. It'd be stupid
to have autoreconf have special options just for these part.
What I want to avoid is extra options to handle the different cases
where I think a single behavior is enough.
In the long run, even Joe will be tired to pass options to acimport
(we need a name, but that's for later :), not to mention Mike :)
| > All the extension files are automatically imported into an m4/ (or
| > whatever the name) directory, and aclocal.m4 is merely a set of
| > m4_include of these files: there is no dependency upon non Autoconf
| > macros which are not in the local tree.
|
| So the user can no longer write code in aclocal.m4? How about
| existing packages that already have m4 code in aclocal.m4? How about
| those using automake, that have the extension code in acinclude.m4
| copied to aclocal.m4? These are issues we have to consider when
| proposing the change, under the principle of backward-compatibility
| we've all sworn to abide to :-)
My view on backward compatibility here is simple: either you obey the
old scheme, in which case autoreconf does nothing, or aclocal
(recognized via its comment) in which case autoreconf runs, or
finally, using m4_includes, also recognized by some signature.
We can easily have tons of guards to protect the innocents from
override their hand written code.
| > The maintainer has nothing to do at all to ensure the completeness
| > of the local copies/symlinks of the extensions files
|
| He has to run autoreconf or the new aclocal, just like in the ``All
| Might Aclocal'' approach. This can't be used as an argument in favor
| of your proposal.
In the AMA you have to pass options to specify what's the behavior you
want, that's what I meant.
| > In particular the maintainer need never modify aclocal.m4 manually.
|
| Ditto. s/need/needs/
Thanks :)
By manually I meant `has to pass options'. I was referring to a brand
stupid `autoreconf' with no flags.
| > The maintainer has to maintain aclocal.m4 manually
|
| Nope. It's just like autoreconf, but, instead of copying files and
| inserting m4_include statements, the tool will insert the files
| inline. From the point of view of the user, there's no difference at
| all, except that he won't have to worry about including additional m4
| files in the distribution (i.e., no difference at all, if using
| automake).
|
| > I am opposed to the second approach.
|
| I'd prefer that personal positions didn't show up in neutral
| expositions.
Agreed.
| > 2 Why the heck should I see so many little extension files pollute my
| > local directory where a single file will do?
|
| I'd rephrase this as: most of the times, the maintainer only cares
| about the macros as a user, i.e., he only needs their definitions, he
| doesn't really care about how they're defined, what other macros in
| what other files they depend upon, whether definitions are given in
| different files on different releases of the packages that supply the
| macro definitions. He often doesn't intend to to modify them locally.
| Having all the needed definitions centralized in a single aclocal.m4
| means he won't have to have files he doesn't understand or really care
| about in his distribution. Not a big deal, but new users might be
| frightened by the amount of ``junk'' in his package.
You know, really, I wonder what kind of Joes you have in mind. This
is an endless debate. Some people might complain Automake distribute
INSTALL, since now the procedure is well known. Who care ABOUT-NLS?
Why the heck do I need install-sh while my platform has a perfect
install? Why should I need config.guess and config.sub?
People have to understand we're fighting a war for them. Let them
excuse our suits!
Moreover, they are fighting with us, they will probably have to take a
look at those &^£$ files. Then, the separated approach is more
natural. But they'll need something like `acimport --split' :(
| > In addition, frankly, anybody using Autoconf and Automake is not
| > just Joe D.
|
| All of us have, at some point, been a Joe D. when we started using
| autoconf. We've all struggled to understand its assumptions. Why
| should we make it any harder by telling them not to forget to include
| any extension files besides aclocal.m4, if they happen to use any
| extension macro?
:)
I agree with the prologue, but not with the conclusions. We all made
mistakes, we all shipped some oldish config.guess, or forgot some
file. I use Autoconf for a2ps before the existence of Automake. But
none of my users complained. Some drew my attention on some problems,
right, but that's nothing as opposed to the bugs there are in a2ps :)
Nothing happened. I was just learning.
Today I think I learned it right, and really I don't think I needed a
baby park in which I learned the Autotools using Babyconf, Babymake
etc. I just needed some time to learn, and learning one scheme or the
other would have taken the same amount of time, but the fact I would
have learned a second once I realize the limitations of the first
approach.
| If you were a starter, using autoconf 2.13, wouldn't you just copy the
| macro file you want to use to aclocal.m4 and be done with it? If you
| were given the ability to m4_include files, would you still create
| aclocal.m4 with a sole m4_include statement, and keep the m4 file
| separate? I think I wouldn't. I'd rather keep it simple.
In your exposure you show you already know the extension of Autoconf
goes via aclocal.m4.
It's, IMHO, equally simple to teach acimport and nothing more.
And, to be honest, I really believe people's first extensions of
Autoconf are AC_DEFUN inside configure.in itself :)
| I've had enough trouble with people of the Kaffe team finding issues I
| considered very minor to be major annoyances, to the point of the team
| being strongly inclined to drop libtool, automake and possibly
| autoconf from the Kaffe building engine. I'm *very* concerned about
| introducing one more minor issue.
Wow! I didn't know. But today, don't they have a collection of m4
files already?
My concerns goes also to the people who are used to walk in the
packages, those free lancers you never heard of who sometimes send a
patch against your package. I'm concerned by the homogeneity of all
the packages because of all these people. We have to keep it uniform
so that there is no wondering on how the package configuration works.
We all are this kind of users. Several times (not many, agreed), I
ran a couple of diffs upon some m4 files to check whether they were up
to date, to check whether I could trust their gettext.m4 for
instance. You can't do that with AMA. Or you need `acimport --diff'
something?
There are just way too many tools you no longer can use. Again, think
of libtoolize! You'd have to acimport afterwards, or have libtoolize
acimport?
All I can see is additional complications just to have Joe learn his
first HelloWorld, while as soon as he'll want to do HelloWorld 0.2,
he'll be using something more open to extensions.
| > Answering 2., there is AC_CONFIG_AUX_DIRS, which can (and should) be
| > used to hide those files. Maintainability is much more important than
| > the number of files.
|
| For people who care about maintaining the files, I agree completely.
| But abstraction is also a very important issue that you're failing to
| consider.
What abstraction are you referring too?
| > Well, first of all because there are already too many tools, and too
| > many options to learn to have the Autotools work properly, we just
| > don't need another choice.
|
| This is no argument in favor of your choice. We will need another
| tool, the difference is on what this tool is going to do.
Let's agree for the tool, having acimport is sane. I'm referring to
the options. I'm referring to the bizarre status of aclocal.m4, half
hand written, half generated.
| > packages will start being different uselessly
|
| Isn't this an argument in favor of having a single aclocal.m4 per
| package? Then, they'll be more similar.
:) :) :)
Well, you're definitely right. My point was ``extendable packages
will be different uselessly''.
| > you'll have to study the configure set up to find the proper options
| > to pass to the tools etc.
|
| Again, this is an argument in favor of the all-mighty aclocal.m4.
Nope, it's an argument for the single approach.
Let me put it this way: I agree the ``always everything in
aclocal.m4'' (as is actually the case currently) is also an approach
that I like for its qualities: it's predictable, it's simple, and
that's a single thing to learn: running aclocal.
The fact is nobody likes this. You can't really depend upon
aclocal.m4 to make or submit a patch etc. so people are shipping their
sources to this end.
So, seeking for another uniform solution, let's just make this the
official way.
You know, maybe some day your Joe using Babyacimport will receive
mails from people telling him he should really use the m4_include
approach, because it's really inconvenient to fix his macros when they
are in the middle of automake stuff.
Maybe Mike has a superb macro will checks for bell 0.3 and whistle
1.3, but someone will have to edit his aclocal to extract it.
Sometime, somehow, Joe will regret his decision, the very decision we
left over him, and maybe will complain we didn't guide him on the
maintainability-extandability road.
| > Here, cp, mv and ln is
| > the only interface I want to deal with, I see no reason for
| > introducing another tool which mimics this via options.
|
| The point you're missing is that most users *won't* be using cp, mv
| and ln, they'll be using whatever aclocal tool we provide them with.
| cp, mv and ln to modify m4 extension files are for Mike X. Pert.
No, I don't think I'm missing this. Joe, who wants to know nothing,
will just run acimport as he used to run aclocal. And indeed, Mike
will play with cp, mv, ln.
But Joe, you know how smart Joe can be :), will quickly see his
configure depends upon the files which are in m4/, and his intuition
will tell him things about ln, cp and mv, while his intuition has
probably little to tell about acimport --inline-file, acimport
--replace-inner-file etc.
| > I really don't think I am being Mike X. Pert here, think of Joe who
| > will have to learn all this too!
|
| But he shouldn't have to learn all this to start using autoconf.
Hm, them this is valid for both sides, isn't it? Or I missed your
point.
| > Just imagine the learning curve for another tool with several
| > options, as opposed to cp, mv, ln.
|
| Precisely.
Aaaaah :)
We'll never manage to make it :)
| > Since I want a single unified approach, the separate files approach
| > seems the natural answer: that's basically what everybody does.
|
| Which everybody are you talking about? What research have you done to
| conclude this? I'll give you a very simple example. I've just
| started helping a Russian user use autoconf for the GNU marst package.
| He'd never had any previous experience with autoconf. He's not even
| using automake. Go figure the way GNU marst's build environment is
| structured. You may even want to ask him what he'd prefer.
OK, everybody is too wide.
You know, even those people who know nothing at all, but are using
Autoconf with the set up I propose, even if they miss to ship some of
the macros, then these macros are likely to be widespread macros, say
Automake's. Then, again, maybe nothing big happens, since the guy who
wants to touch the package certainly has Automake.
I'm trying to make Autoconf easier. I really do. I do think about Mr
marst in as many ways as I can. I tried to include much of the
autowisdom I learned the hard way in the documentation. I simplify
the interface as much as I can. I try to awake dead bodies such as
autoreconf because they have a role to play in the simplified unified
interface. I am really concerned by these people, I've been one of
them, and if today I'm an Autoconf maintainer, it is precisely because
of the failures of Autoconf: I *had* to become an expert to have a2ps
configure as I wanted it to.
One of my main motivation in Autoconf is precisely to help all the
Akimitos who are suffering now. In some way, I do want Babyconf.
But here, I don't think we are really hitting a sharp corner.
| > And people do this because these files are actually very alive, and
| > often need editing.
|
| For those people who maintain them. Those that don't are just users,
| and we shouldn't require them to become maintainers of those files
| too. Abstraction is the key.
Agreed, but not at the expense of complications.
In fact, this is why I agreed to have only two behaviors: either
acimport is just another aclocal (but I'd prefer to still copy the m4
files locally, but this is debatable), or the behavior I suggest.
It's that thing in between that makes the interface explodes in a
variety of options.
We can leave with `acimport --inline' and `acimport --include' (Hm,
bad names :), but not with `acimport --update-inner-file gettext.m4'.
This time we really have the abstract Babyconf, and the Autoconf for
grownups, and neither camp is paying the price of the other.
But the solution in between is expensive in terms of needed knowledge.
| > Since, in addition, these files can come from a lot of different
| > places, it is important to keep them separate.
|
| They'll be separate, just in a single file. Are you arguing for us to
| stop shipping tarballs and instead post every file in separate in
| ftp.gnu.org? What's your point?
I was trying to explain why m4 files deserve a different approach than
the all mighty missing. All mighty missing can exist, Automake or
Autoconf can centralize its ``modules''. But m4 files do not fit this
picture: there are way too many.
So they have to remain independent entities so that you can look for
them, change them, include them etc.
Yes, I'm saying that having to look into aclocal.m4 is a limitation in
this case.
| > Because I really don't think we need two answers to a single need.
|
| It's not a single need. What you're failing to see is that there are
| different kinds of autoconf users. There are those that maintain
| their own set of m4 extensions, who *want* their macros to be in
| separate files, and those that just use them, who care about the
| macros, and would rather abstract the very existence of files away.
But why then did you refuse the `only one of the two pure approaches'
proposal?
| > for the user it means more documentation to read
|
| Which solution are you arguing for, again? Previously, you said that,
| in order to have multiple m4 files, the user would just have to follow
| our example in the documentation, and he might well miss that point.
This was just for make dist, but granted :)
| With the all-mighty aclocal.m4, that wouldn't be necessary.
I'm precisely referring to its all-mightism. If it had not this
double nature of m4_include and inlined sections, I agree it would be
simple too.
| > We are probably more knowledgeable than he is, we have some
| > experience he doesn't have.
|
| But we shouldn't force him to become as knowledgeable as we in his
| first project. Let's give him time to learn why it's better to have
| separate m4 extension files when he maintains his own set of extension
| macros. Meanwhile, he'll live with a solution that abstracts away
| this issue for him.
I hear you :)
| > One way to help him is to make choices for him.
|
| If they're the right choices. I don't think they are, for a beginner.
I hear you well :)
Well, really, why not the `one of the two pure approaches'?
Akim
PS/ Well, if we don't consider the patches, I think we're exchanging
the longest messages ever between us :)
On Jul 31, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> | Thanks for taking the trouble of summarizing the points, and for
> | running them through me first.
> You're welcome :) I like working with you. In fact, if we go to the
> referendum, I'd like that we have a common document, or at least
> something ``objective'', and then our comments.
> | It made it clear that part of my suggestion didn't make it to you.
> Hm, I'm not sure I understand this :( Is it
> it made it clear that there are arguments for my suggestion
> that you don't know/don't consider.
> or something like this?
Yep. You hadn't fully understood the way my suggestion would work.
> Personally I don't think it is so likely, but it is, definitely, but I
> really can't imagine something big happen because of this. I don't
> see much difference with `forgetting' to distribute the Bison sources,
> or acconfig.h etc.
Nobody forgets acconfig.h because it's only used in the presence of
automake, and automake takes care of it. In the case of m4 macro
files, one may easily forget about it because they aren't needed to
build the package, just to hack on it. So most people won't even
notice they're missing.
> What I want to avoid is extra options to handle the different cases
> where I think a single behavior is enough.
That's where we disagree. There are two kinds of wanted behaviors:
that of a newbie autoconf user and that of an expert user. I'm fine
with arranging for this tool to support only the newbie by default, as
long as it doesn't prevent the expert from having his macro files
separated. I'm not fine with forcing a newbie to care about that.
> In the long run, even Joe will be tired to pass options to acimport
> (we need a name, but that's for later :), not to mention Mike :)
How about aclocal?
I intend to built it upon GNU art (ARchiver of Text), which I'm
designing.
GNU art (which would probably be part of autoconf) would be a tool to
add/remove/extract sections from text files. Autoconf would use it to
manage not only aclocal.m4, but also missing. It will have to have
lots of options, to allow for this and other kinds of uses, but we'd
provide aclocal and acmissing as front-ends to art. Even if we choose
to support only the m4_include solution in aclocal.m4, we'd probably
still use some form of `art' :-) to add the m4_include statements.
> My view on backward compatibility here is simple: either you obey the
> old scheme, in which case autoreconf does nothing, or aclocal
> (recognized via its comment) in which case autoreconf runs, or
> finally, using m4_includes, also recognized by some signature.
And you claim this to be simpler than allowing for guarded
m4_include/whole files in aclocal.m4? Where's the single-choice
decision? The solution I propose is fully backward-compatible, while
still supporting the advanced uses Mike X. Pert wants. The one you
propose requires not only Mike X. Pert to re-work a little bit his own
aclocal.m4 (since he certainly already uses some form of include), but
also all poor Joe D. Vellopers to do so in order to start benefitting
from the new way of managing stuff.
> We can easily have tons of guards to protect the innocents from
> override their hand written code.
My point is that we just shouldn't overwrite aclocal.m4. We should
append to it, or update guarded sections of it, never generate it from
scratch.
> | > The maintainer has nothing to do at all to ensure the completeness
> | > of the local copies/symlinks of the extensions files
> |
> | He has to run autoreconf or the new aclocal, just like in the ``All
> | Might Aclocal'' approach. This can't be used as an argument in favor
> | of your proposal.
> In the AMA you have to pass options to specify what's the behavior you
> want, that's what I meant.
You don't have to pass any options. You *may* pass them, to change
the default. Same difference.
> By manually I meant `has to pass options'. I was referring to a brand
> stupid `autoreconf' with no flags.
You're assuming (i) autoreconf is the tool that manages aclocal.m4 and
(ii) the default is not the one you want. (i) is certainly not the
way to go, and I think we can agree on that in advance. (ii) means
you feel the battle is already lost. Come on, man, fight! :-) :-)
> Why the heck do I need install-sh while my platform has a perfect
> install? Why should I need config.guess and config.sub?
If you only care about *your* platform, you probably won't even be
distributing your package, so there's little point in caring about
what gets distributed.
In fact, you don't need those files. automake doesn't force you to
have them, it just warns you if you don't.
> I agree with the prologue, but not with the conclusions. We all made
> mistakes, we all shipped some oldish config.guess, or forgot some
> file.
My point is: why should we make yet another mistake easier for one to
make? And bear in mind that it's not just about packaging
distributions. It's also about maintaining CVS trees. I've had
enough trouble with other maintainers of Kaffe failing to understand
how the pieces fall together that I'd rather have some very simple
default that hopefully would get them satisfied.
> In your exposure you show you already know the extension of Autoconf
> goes via aclocal.m4.
Yup. Anybody who wants to use extensions will certainly stumble
across this fact.
> It's, IMHO, equally simple to teach acimport and nothing more.
Yup. The nothing more is precisely what I've been arguing for. No
need to look at what files acimport has installed and go fix
Makefile.in to get them distributed, and cvs add them.
> And, to be honest, I really believe people's first extensions of
> Autoconf are AC_DEFUN inside configure.in itself :)
Indeed. But then, there's the autoconf macro archive.
> Wow! I didn't know. But today, don't they have a collection of m4
> files already?
No. Just the small collection of files needed by libtool, and all
those Makefile.am files whose syntax they don't understand (even
though it's just a Makefile!), plus the dependencies between
acinclude.m4, configure.in, aclocal.m4, configure, Makefile.ins,
acconfig.h, config.h.in, config.h, etc.
> My concerns goes also to the people who are used to walk in the
> packages, those free lancers you never heard of who sometimes send a
> patch against your package. I'm concerned by the homogeneity of all
> the packages because of all these people. We have to keep it uniform
> so that there is no wondering on how the package configuration works.
What could be more uniform than a single aclocal.m4 per package?
That's where anybody would look at first. Granted, if it m4_includes
other macro files, ok, anybody can figure what m4_include means. But
Mr. Rand M. Hacker will certainly look at aclocal.m4 first. And he'll
probably be glad to be able to type C-s and find the macro he's
looking for in there, instead of having to figure out in which file
the macro is defined.
> We all are this kind of users. Several times (not many, agreed), I
> ran a couple of diffs upon some m4 files to check whether they were up
> to date, to check whether I could trust their gettext.m4 for
> instance. You can't do that with AMA. Or you need `acimport --diff'
> something?
You'd `aclocal --extract foo.m4' then run plain diff.
> There are just way too many tools you no longer can use. Again, think
> of libtoolize! You'd have to acimport afterwards, or have libtoolize
> acimport?
libtoolize would aclocal in the macro.
> All I can see is additional complications just to have Joe learn his
> first HelloWorld, while as soon as he'll want to do HelloWorld 0.2,
> he'll be using something more open to extensions.
The point is precisely to keep Joe willing to use autoconf. If we
keep it simple for the starter, he'll remain with us and eventually
know enough to want to manage separate m4 files. Then, he'll add
AC_MACRO_DIR(m4) to the beginning of aclocal.m4 and the new aclocal
will start to get m4 extensions installed in m4 for him. Until then,
he'd be able to use autoconf without worrying about it.
> What abstraction are you referring too?
Abstracting away the fact that m4 extensions are defined in separate
files, provided by different sources, that may change over time.
> I'm referring to the bizarre status of aclocal.m4, half hand
> written, half generated.
I don't see anything wrong with that. There's part of it that is
hard-written (in the automake world, that's acinclude.m4, duplicated
in aclocal.m4), and there's part of it that is either a couple of
m4_include statements or a couple of guarded files. No big deal.
> | > packages will start being different uselessly
> |
> | Isn't this an argument in favor of having a single aclocal.m4 per
> | package? Then, they'll be more similar.
> :) :) :)
> Well, you're definitely right. My point was ``extendable packages
> will be different uselessly''.
What's an extendable package?
> The fact is nobody likes this.
Ask beginners. Unfortunately, the autoconf mailing list is full of
Mike X. Perts that want, with all their forces, to keep their ability
to split their macros across multiple files, that don't consider it a
big deal that some newbies may make a couple of additional mistakes as
they start using autoconf. I'm *very* worried about introducing yet
another element of complexity in autoconf, because of my unfortunate
with Kaffe. I agree it's not a major complexity, and it's something
every user would eventually figure out, but I'd rather avoid the
mistake at first, and let the user learn.
> You can't really depend upon aclocal.m4 to make or submit a patch
> etc. so people are shipping their sources to this end.
m4 files are sources only for people who maintain them. For plain
users (I mean, the developers that want to use the macros in their
configure.ins), those need not be faced as sources. They probably
wouldn't care if we shipped a frozen m4 file. But we won't, because
there's no way (AFAIK) to extract the sources from a frozen m4 file.
In the case of the all-mighty aclocal.m4, there is, and it's so easy
that you don't even need GNU art or aclocal --extract. You can
cut&paste it as well. However you prefer.
> You know, maybe some day your Joe using Babyacimport will receive
> mails from people telling him he should really use the m4_include
> approach, because it's really inconvenient to fix his macros when they
> are in the middle of automake stuff.
Good. Then he'll learn about this great feature without having made
any mistake. And he'll like it, and start using it. It will cost him
just the addition of a line in aclocal.m4, and a little bit of
additional complexity in aclocal. I think it's worth it.
> Maybe Mike has a superb macro will checks for bell 0.3 and whistle
> 1.3, but someone will have to edit his aclocal to extract it.
Mike will ship them separately, for sure. And then, extracting files
is no big deal.
> Sometime, somehow, Joe will regret his decision, the very decision
> we left over him, and maybe will complain we didn't guide him on the
> maintainability-extandability road.
You may be right. Then I'll ask him whether he'd have liked to have
to care about all those files in the beginning. He may even say he
would, but I won't believe him, because, by then, he'll already be an
X. Pert, and will are more about his convenience than about
difficulties that other new users may have to face.
> No, I don't think I'm missing this. Joe, who wants to know nothing,
> will just run acimport as he used to run aclocal.
He'll have to adjust the Makefiles and cvs add the files. This may
become *very* annoying.
> But Joe, you know how smart Joe can be :), will quickly see his
> configure depends upon the files which are in m4/, and his intuition
> will tell him things about ln, cp and mv, while his intuition has
> probably little to tell about acimport --inline-file, acimport
> --replace-inner-file etc.
You're mixing the interface of aclocal with its implementation. The
fact that it stores macros in separate files instead of in-lining them
in aclocal.m4 is an implementation detail. Even if we decide that the
way to go is to have macros separated, it's still an implementation
detail, and we're still going to have to offer options for the user to
update macro files and stuff. The point is that the default of having
separate files is an implementation detail that isn't hidden from the
user. He still has to take care of each individual file. No big
deal, but it prevents us from changing the implementation without
modifying the interface. That's important for maintainability.
People would be free to play with cp/mv/ln, but they'll be breaking
the abstraction layers, and they shouldn't blame us if we eventually
change the implementation. They should be using the public interface
or accepting the risk.
> | > I really don't think I am being Mike X. Pert here, think of Joe who
> | > will have to learn all this too!
> |
> | But he shouldn't have to learn all this to start using autoconf.
> Hm, them this is valid for both sides, isn't it? Or I missed your
> point.
He shouldn't be forced to learn about the separation of macro files.
> I'm trying to make Autoconf easier. I really do.
So am I.
> Agreed, but not at the expense of complications.
What complications? Why do you think having an m4_include statement
in aclocal.m4 and a separate .m4 file any simpler than a single
aclocal.m4? I fail to find it simpler. I find it unneeded
complication.
> I was trying to explain why m4 files deserve a different approach than
> the all mighty missing. All mighty missing can exist, Automake or
> Autoconf can centralize its ``modules''.
We're already seeing signs that it can't. People keep asking for
additional `missing' features, and we shouldn't impose them upon every
developer that uses automake.
> But m4 files do not fit this picture: there are way too many.
> So they have to remain independent entities so that you can look for
> them, change them, include them etc.
Same difference.
> | > Because I really don't think we need two answers to a single need.
> |
> | It's not a single need. What you're failing to see is that there are
> | different kinds of autoconf users. There are those that maintain
> | their own set of m4 extensions, who *want* their macros to be in
> | separate files, and those that just use them, who care about the
> | macros, and would rather abstract the very existence of files away.
> But why then did you refuse the `only one of the two pure approaches'
> proposal?
Precisely because I don't believe one size fits all in this case. I
want to help users evolve, not force them into quantum leaps. Nobody
is either a Joe D. Velloper or a Mike X. Pert. People are in
between. Why shouldn't autoconf go along with them, allowing them to
adopt the macro files they wish to make changes to, while still
letting them not care about those they don't want to care about yet?
> I'm precisely referring to its all-mightism. If it had not this
> double nature of m4_include and inlined sections, I agree it would be
> simple too.
The all-mighty only approach is certainly the wrong way to go. We
*must* support m4_include, hand-written or auto-generated, to allow
people to separate macro files. What I want is a no-mistake default
for beginners and the choice for masters.
> PS/ Well, if we don't consider the patches, I think we're exchanging
> the longest messages ever between us :)
Most definitely :-)
--
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 *Please* write to mailing lists, not to me
| > Personally I don't think it is so likely, but it is, definitely, but I
| > really can't imagine something big happen because of this. I don't
| > see much difference with `forgetting' to distribute the Bison sources,
| > or acconfig.h etc.
|
| Nobody forgets acconfig.h because it's only used in the presence of
| automake, and automake takes care of it.
Well, what is the difference here?
If I understand correctly your argument you're saying that only
Automake puts the proper rules for config.h regeneration via
autoheader. Then I'd answer without Automake there are as little
risks to see autoconf run.
| In the case of m4 macro
| files, one may easily forget about it because they aren't needed to
| build the package, just to hack on it. So most people won't even
| notice they're missing.
Very same with acconfig.h and even configure.in actually, and with
higher-order sources such as gperf, Bison, Flex, IDL etc.
| > What I want to avoid is extra options to handle the different cases
| > where I think a single behavior is enough.
|
| That's where we disagree. There are two kinds of wanted behaviors:
| that of a newbie autoconf user and that of an expert user. I'm fine
| with arranging for this tool to support only the newbie by default, as
| long as it doesn't prevent the expert from having his macro files
| separated. I'm not fine with forcing a newbie to care about that.
I understand you are against forcing, and I'm certainly always of
pushing things onto the user like this, but in the case we are
debating about, I fail to see what makes it so harder. It seems very
straight to me, and I'm saying this thinking about Joe, not Mike.
| > In the long run, even Joe will be tired to pass options to acimport
| > (we need a name, but that's for later :), not to mention Mike :)
|
| How about aclocal?
|
| I intend to built it upon GNU art (ARchiver of Text), which I'm
| designing.
|
| GNU art (which would probably be part of autoconf) would be a tool to
| add/remove/extract sections from text files. Autoconf would use it to
| manage not only aclocal.m4, but also missing. It will have to have
| lots of options, to allow for this and other kinds of uses, but we'd
| provide aclocal and acmissing as front-ends to art. Even if we choose
| to support only the m4_include solution in aclocal.m4, we'd probably
| still use some form of `art' :-) to add the m4_include statements.
This is getting even bigger! That's precisely what I wish to avoid.
Let me make it clear, GNU art is certainly a good idea, and I do think
of a couple of places where I would use it. Also, it is clear that if
GNU art exists, that's the natural base layer for what you want to do.
But I still don't think we need such an artillery for that very issue.
| > My view on backward compatibility here is simple: either you obey the
| > old scheme, in which case autoreconf does nothing, or aclocal
| > (recognized via its comment) in which case autoreconf runs, or
| > finally, using m4_includes, also recognized by some signature.
|
| And you claim this to be simpler than allowing for guarded
| m4_include/whole files in aclocal.m4? Where's the single-choice
| decision?
There is a single promoted approach, all the rest is here for backward
compatibility only. I would even -W obsolete other uses.
| The solution I propose is fully backward-compatible, while
| still supporting the advanced uses Mike X. Pert wants.
To the expense of additional complexity. I really mean that! You
seem to say that I'm lacking of abstraction here, and I hear your
point, but I disagree that relying on the file system is lacking
abstraction.
In fact there is nothing more important than reusing known scheme.
Putting a new wonderful interface extremely powerful will never be
justified if there was an existing means to reach the same goals.
For instance, GNU art would make a major mistake, IMHO, if it was not
using the same options as GNU tar. And in fact, I wonder whether it
would not be better to try to teach tar or cpio or whatever, a
different streaming method.
Here there is an *abstract* interface well known by each of our users:
the file system. I see no reason to reject it.
There is an example I like: the Eiffel programming language. They
have very simple rules: a class is one file, and vice versa, a module
is one directory, and vice versa.
That's *perfect*! It's clear, gives a natural trend to structure the
projects in similar manners etc.
In addition, it allows them to simplify the code, and suddenly gives
an extraordinary power to the users via all the classical commands!
The file system is itself is a wonderful interface. It is so natural
that there are even things like /proc now! See proc/? Something
extraordinary with it is that all the good old tools we are used to
can be used here.
I do think using the file system does provide some abstract, and a
well understood one.
| > We can easily have tons of guards to protect the innocents from
| > override their hand written code.
|
| My point is that we just shouldn't overwrite aclocal.m4. We should
| append to it, or update guarded sections of it, never generate it from
| scratch.
My point is that since we can release Mike and Joe from maintaining
it, there is no reason to have to!
| > | > The maintainer has nothing to do at all to ensure the completeness
| > | > of the local copies/symlinks of the extensions files
| > |
| > | He has to run autoreconf or the new aclocal, just like in the ``All
| > | Might Aclocal'' approach. This can't be used as an argument in favor
| > | of your proposal.
|
| > In the AMA you have to pass options to specify what's the behavior you
| > want, that's what I meant.
|
| You don't have to pass any options. You *may* pass them, to change
| the default. Same difference.
Sorry, I fail to see how, for instance, when you suddenly depend upon
another m4 file, you may not have to specify via an option whether it
should be inlined, or included.
| > By manually I meant `has to pass options'. I was referring to a brand
| > stupid `autoreconf' with no flags.
|
| You're assuming (i) autoreconf is the tool that manages aclocal.m4 and
autoreconf or whatever. The point is that the tool must know what to
do, and must not expect input from us.
But we agree that anyway here, we can have an envvar for instance
which tells the tool once for all to use one or the other scheme.
But then when you import an existing project which used a different
strategy, things can go bad.
| (ii) the default is not the one you want. (i) is certainly not the
| way to go, and I think we can agree on that in advance.
Agreed :)
| (ii) means
| you feel the battle is already lost. Come on, man, fight! :-) :-)
No :) It means that given your motivation (helping Joe), it is
obvious that you want the default to be Babyconf.
| > I agree with the prologue, but not with the conclusions. We all made
| > mistakes, we all shipped some oldish config.guess, or forgot some
| > file.
|
| My point is: why should we make yet another mistake easier for one to
| make? And bear in mind that it's not just about packaging
| distributions. It's also about maintaining CVS trees. I've had
| enough trouble with other maintainers of Kaffe failing to understand
| how the pieces fall together that I'd rather have some very simple
| default that hopefully would get them satisfied.
As you have said, but it was more like a joke, we *can* imagine a tool
that checks the conformance between the CVS archive, and the local
copy.
Really, why not? Automake knows a great deal about the package: it
can check that the higher order sources are included, it can check
configure is in the tree (or not depending the policy used in the CVS
archive wrt generated files) etc. It can even just check you didn't
forget to cvs add your new foo.c.
Nothing new with the extension files.
| > It's, IMHO, equally simple to teach acimport and nothing more.
|
| Yup. The nothing more is precisely what I've been arguing for. No
| need to look at what files acimport has installed and go fix
| Makefile.in to get them distributed, and cvs add them.
The differences between you and me can basically be summarized by the
fact you seem to pay great attention to what I'd call the transitory
state.
Yes, it is possible for someone to forget to update Makefile.in (are
there really many people who use Autoconf but not Automake? I really
don't know, on gnu.org I know no non Automake package, but there are
probably others).
But I can't see this as a sufficient reason to compromise the stable
state.
| No. Just the small collection of files needed by libtool, and all
| those Makefile.am files whose syntax they don't understand (even
| though it's just a Makefile!), plus the dependencies between
| acinclude.m4, configure.in, aclocal.m4, configure, Makefile.ins,
| acconfig.h, config.h.in, config.h, etc.
Yes, I know this ugly stuff :( This is also why I'm struggling with
autoreconf.
| > My concerns goes also to the people who are used to walk in the
| > packages, those free lancers you never heard of who sometimes send a
| > patch against your package. I'm concerned by the homogeneity of all
| > the packages because of all these people. We have to keep it uniform
| > so that there is no wondering on how the package configuration works.
|
| What could be more uniform than a single aclocal.m4 per package?
One point, but that was stabbing my back :)
Yes, of course. Again I was talking about the possibility that there
are several methods, and you answer on the other side. You know we
cannot continue with aclocal.m4 as it is, we need an m4_include
approach. I'm saying it should be the only one, you're saying, no, we
need several.
| That's where anybody would look at first. Granted, if it m4_includes
| other macro files, ok, anybody can figure what m4_include means. But
| Mr. Rand M. Hacker will certainly look at aclocal.m4 first. And he'll
| probably be glad to be able to type C-s and find the macro he's
| looking for in there, instead of having to figure out in which file
| the macro is defined.
I disagree. He'll be much happier to find a file dedicated to this
issue, see what are the local macro that relate together, and send a
patch against this only. He'll be much happier to be able to use his
old knowledge of Unix tools than to have to juggle either with Emacs,
or with ac-mini-tar.
| > We all are this kind of users. Several times (not many, agreed), I
| > ran a couple of diffs upon some m4 files to check whether they were up
| > to date, to check whether I could trust their gettext.m4 for
| > instance. You can't do that with AMA. Or you need `acimport --diff'
| > something?
|
| You'd `aclocal --extract foo.m4' then run plain diff.
Grosssssssssss!
*That*'s what I'm talking about!!!
What is the semantics of your `aclocal --extract foo.m4'? It extracts
foo.m4 but leaves in there too, or replaces the foo.m4 inside with an
include of foo.m4?
More questions, more wondering, more asking oneself what the tool is
going to do, while you know so well what diff, cp etc. mean!
| > There are just way too many tools you no longer can use. Again, think
| > of libtoolize! You'd have to acimport afterwards, or have libtoolize
| > acimport?
|
| libtoolize would aclocal in the macro.
This is not sane! 1. it means waiting for all the maintainers tools
to catch up, 2. it considerably increases the coupling between the
packages!
And what when you want to update libtool.m4 and the maintainers knows
you must not? Instead of just cp in any case and let the rights do
their job, you'll have to provide some complex option which will
specify under what conditions you should update, that if it was an
include, keep it as an include, if it was inlined, keep it inlined,
but if it was not present then what: inline or include? Yet another
option to libtoolize. In addition to the option which says that if it
is an include which is wanting, is it an include of a link, or of a
copied libtool.m4?
Anyway, I think it's the converse that must happen: libtoolize is the
low level tool, and it's autoreconf --install that must take care of
completing the installation.
| > All I can see is additional complications just to have Joe learn his
| > first HelloWorld, while as soon as he'll want to do HelloWorld 0.2,
| > he'll be using something more open to extensions.
|
| The point is precisely to keep Joe willing to use autoconf.
Frankly, I just don't care. I'm not here to sell Autoconf.
I'm doing my best to have Autoconf make its job the best possible, and
the hard part is in the long run, not in the first steps. Yes, I
agree the first steps are not easy, and actually we should promote
tutorials that explain Autoconf and Automake together.
But Autoconf is not a tutorial. There shall be no autoconf
--i-m-a-novice.
You know, we can also imagine that aclocal will check *by default*
that the names of the files it includes are in the local Makefile.
That would very address your issue!
We can provide plenty of new --warnings to assists beginners. That's
the sane approach, that's what compilers do! But they don't provide
Babyfeatures! They look over your shoulder if you're doing it right,
but they are not trying to present a different interface for novices.
I see no reason for autoconf to be innovative on this issue.
| If we
| keep it simple for the starter, he'll remain with us and eventually
| know enough to want to manage separate m4 files. Then, he'll add
| AC_MACRO_DIR(m4) to the beginning of aclocal.m4 and the new aclocal
| will start to get m4 extensions installed in m4 for him. Until then,
| he'd be able to use autoconf without worrying about it.
How do you handle the transition between the two states? The next run
of aclocal will `explode' aclocal.m4? And then, what will you do of
the foo.m4 that might already be there?
And where's the transitional state where you can have handwritten,
inlined and included macros? You must not use AC_MACRO_DIR?
More rules to learn, more matrices with crosses that explain how
things inter-operate.
| > Well, you're definitely right. My point was ``extendable packages
| > will be different uselessly''.
|
| What's an extendable package?
Something which presents its source form, not its configuration form.
You know, after all we could tar configure.in, aclocal.m4, cccp.y
etc. together in the package we ship. That's a means to deliver
something clean from all the stuff which is useless for regular
installers.
I'm referring to exactly this.
We do not want to tar configure.in and the Makefile.am together.
We do not want to tar the extension files together.
| > The fact is nobody likes this.
|
| Ask beginners. Unfortunately, the autoconf mailing list is full of
| Mike X. Perts that want, with all their forces, to keep their ability
| to split their macros across multiple files, that don't consider it a
| big deal that some newbies may make a couple of additional mistakes as
| they start using autoconf. I'm *very* worried about introducing yet
| another element of complexity in autoconf, because of my unfortunate
| with Kaffe. I agree it's not a major complexity, and it's something
| every user would eventually figure out, but I'd rather avoid the
| mistake at first, and let the user learn.
I think I'm sensitive to your argument, but somewhere I rank the level
of the users and of the ``difficulty'' differently. I'm doing lots of
efforts to Joeize myself, and I still fail to see why your scheme is
easier for me.
1. Well, yes, there is that `make dist' concerns. OK, I
missed my tarball the first time, but now I understand and did
something great. Where is my slashdot?
2. Well, yes, I use Automake, and it rocks! (Well, it works,
since it seems `it rocks' isn't proper English :)
3. Well, I was about to shoot myself in the foot, but thanks
to -W novice, aclocal warned me. I love these tools.
| m4 files are sources only for people who maintain them. For plain
| users (I mean, the developers that want to use the macros in their
| configure.ins), those need not be faced as sources. They probably
| wouldn't care if we shipped a frozen m4 file.
As an aside, running autoconf on the fileutils's configure with or
without a frozen aclocal.m4 makes no difference: it's about as long!
I was surprised.
| > Sometime, somehow, Joe will regret his decision, the very decision
| > we left over him, and maybe will complain we didn't guide him on the
| > maintainability-extandability road.
|
| You may be right. Then I'll ask him whether he'd have liked to have
| to care about all those files in the beginning. He may even say he
| would, but I won't believe him, because, by then, he'll already be an
| X. Pert, and will are more about his convenience than about
| difficulties that other new users may have to face.
:) :) :)
| > No, I don't think I'm missing this. Joe, who wants to know nothing,
| > will just run acimport as he used to run aclocal.
|
| He'll have to adjust the Makefiles and cvs add the files. This may
| become *very* annoying.
Just as for the rest of the source files, such as Makefile.am. Too
bad Automake does not have `make cvs-check with an AUTOMAKE_OPTION
stating if all-the-package-in-the-archive,
only-sources-into-the-archive, or shut-the-heck-:-)-up-let-me-do.
| > I'm trying to make Autoconf easier. I really do.
|
| So am I.
Yep. That's terrible: I think we want the same things, but we have
different views on the means. It would have been so simpler to
completely disagree on the goals, and simply despise each other :)
| What complications? Why do you think having an m4_include statement
| in aclocal.m4 and a separate .m4 file any simpler than a single
| aclocal.m4? I fail to find it simpler. I find it unneeded
| complication.
The static is simpler, the dynamic is much more complex.
| > I'm precisely referring to its all-mightism. If it had not this
| > double nature of m4_include and inlined sections, I agree it would be
| > simple too.
|
| The all-mighty only approach is certainly the wrong way to go. We
| *must* support m4_include, hand-written or auto-generated, to allow
| people to separate macro files. What I want is a no-mistake default
| for beginners and the choice for masters.
The whole complexity of your proposal lies in this in between. That's
what I am still against. The two extremes is something that keeps
both simplicities. That stuff in the middle of it if what I think is
unreasonable.
| > PS/ Well, if we don't consider the patches, I think we're exchanging
| > the longest messages ever between us :)
|
| Most definitely :-)
And it is still not over :)
Alexandre, I think our debate is interesting enough to be make
public. Would you mind if we send all this thread to autoconf@?
I fear lengthy threads, which would be a bad thing, but if we expose
our points of view, maybe we could try to see a consensus emerge.
But then ``autoconf is full of Mikes :)''.
On Aug 1, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> | Nobody forgets acconfig.h because it's only used in the presence of
> | automake, and automake takes care of it.
> Well, what is the difference here?
For some reason, I was thinking acconfig.h only existed when automake
was in use. This is obviously wrong, since autoheader uses it
regardless of automake.
> Very same with acconfig.h and even configure.in actually, and with
> higher-order sources such as gperf, Bison, Flex, IDL etc.
Agreed.
> Let me make it clear, GNU art is certainly a good idea, and I do think
> of a couple of places where I would use it. Also, it is clear that if
> GNU art exists, that's the natural base layer for what you want to do.
> But I still don't think we need such an artillery for that very issue.
Hadn't we agreed this was the way to go for `missing'. So we need the
tool, why not use it for something else too?
> | The solution I propose is fully backward-compatible, while
> | still supporting the advanced uses Mike X. Pert wants.
> To the expense of additional complexity. I really mean that!
I worry more about additional complexity for the user than for us.
> You seem to say that I'm lacking of abstraction here, and I hear
> your point, but I disagree that relying on the file system is
> lacking abstraction.
What if the next Akim decides that files are not the right level of
abstraction for splitting m4 macros, and pushes for a macro-per-file
solution? Anyone relying upon files would lose. That's why I say
using files is just an implementation detail, that the user shouldn't
have to care about.
> In fact there is nothing more important than reusing known scheme.
> Putting a new wonderful interface extremely powerful will never be
> justified if there was an existing means to reach the same goals.
Agreed. Let's use a single aclocal.m4 :-) :-) :-)
> For instance, GNU art would make a major mistake, IMHO, if it was not
> using the same options as GNU tar
It needs options to specify separators, headers and trailers. The
rest can be kept pretty much like tar.
> In addition, it allows them to simplify the code, and suddenly gives
> an extraordinary power to the users via all the classical commands!
Except that, if someone ever decides to change the internal
representation, all their extraordinary power becomes a source of
trouble.
> The file system is itself is a wonderful interface. It is so natural
> that there are even things like /proc now! See proc/?
Do you really think it's wonderful that the kernel code must have code
to convert data structures from an internal format to a text
representation and vice-versa, and to deal with errors when dealing
with input? I find the FreeBSD approach far saner: it's an external,
user-level tool that maps the kernel memory and does the encoding and
decoding of information.
> I do think using the file system does provide some abstract, and a
> well understood one.
I agree it does provide some amount of abstraction, but it's not the
abstraction our users care about. Our Joe users care about *macros*,
not m4 files developed by someone else! That's the abstraction we
should provide him with. We shouldn't push any further abstractions
upon him if we can help it.
> Sorry, I fail to see how, for instance, when you suddenly depend upon
> another m4 file, you may not have to specify via an option whether it
> should be inlined, or included.
Whatever the default we choose, you won't have to pass an option to
enable that default, because it will be the default. Only if you want
to change the default will you have to give an option.
> But we agree that anyway here, we can have an envvar for instance
> which tells the tool once for all to use one or the other scheme.
Not an env var. We'd have aclocal.m4. That's the file we'd look at
to see which option the user wants, which files he already
m4_includes, etc.
> As you have said, but it was more like a joke, we *can* imagine a tool
> that checks the conformance between the CVS archive, and the local
> copy.
The newbie would still have to learn about this tool to be able to use
it. And since it would be part of autoconf, it would know very little
about Makefile structure or even about the distribution mechanism
chosen by the user.
> Yes, it is possible for someone to forget to update Makefile.in (are
> there really many people who use Autoconf but not Automake?
Yes, lots of them.
> I really don't know, on gnu.org I know no non Automake package, but
> there are probably others).
How about GCC, for a start?
> Yes, of course. Again I was talking about the possibility that there
> are several methods, and you answer on the other side. You know we
> cannot continue with aclocal.m4 as it is, we need an m4_include
> approach.
I know we need it for advanced users, who maintain their own sets of
macros. I wouldn't ever recommend it for newbies. Never! :-)
> What is the semantics of your `aclocal --extract foo.m4'? It
> extracts foo.m4 but leaves in there too, or replaces the foo.m4
> inside with an include of foo.m4?
Whatever we decide it to be. It's clear to me that we should have
both possibilities.
> | > There are just way too many tools you no longer can use. Again, think
> | > of libtoolize! You'd have to acimport afterwards, or have libtoolize
> | > acimport?
> | libtoolize would aclocal in the macro.
> This is not sane! 1. it means waiting for all the maintainers tools
> to catch up, 2. it considerably increases the coupling between the
> packages!
I don't understand. That's precisely what aclocal does now. What's
there to catch up? What coupling are you talking about?
> And what when you want to update libtool.m4 and the maintainers knows
> you must not?
aclocal --force aclocal.m4 [/path/to/libtool.m4]
You wouldn't have to know whether libtool.m4 was inlined or not at
first, it would keep the inline/include status of each file unchanged.
> but if it was not present then what: inline or include?
The default, that may have been changed in aclocal.m4 itself.
> Anyway, I think it's the converse that must happen: libtoolize is the
> low level tool, and it's autoreconf --install that must take care of
> completing the installation.
Whatever. Both would use aclocal to install libtool.m4 in the
package's tree, either inline or m4_included in aclocal.m4
> | The point is precisely to keep Joe willing to use autoconf.
> Frankly, I just don't care. I'm not here to sell Autoconf.
Great. We don't need users. Who cares about users? What's the point
of having users, if all the fun is in writing the software?
> You know, we can also imagine that aclocal will check *by default*
> that the names of the files it includes are in the local Makefile.
What local Makefile? There's no such thing as a local Makefile, from
the point of view of autoconf. autoconf just AC_SUBST data in generic
files. It knows nothing about Makefiles in particular. There's
nothing it can (or should) do.
> We can provide plenty of new --warnings to assists beginners. That's
> the sane approach, that's what compilers do! But they don't provide
> Babyfeatures! They look over your shoulder if you're doing it right,
> but they are not trying to present a different interface for novices.
Sure they do. Think of `-g'. Real programmers don't use `-g' :-) :-)
> How do you handle the transition between the two states?
He'll ask aclocal to extract some of the included m4 files into a
separate file, so that he could manage it separately.
> And where's the transitional state where you can have handwritten,
> inlined and included macros? You must not use AC_MACRO_DIR?
AC_MACRO_DIR would apply to newly imported m4 files. You'd have to
export the ones that were already inline.
> More rules to learn, more matrices with crosses that explain how
> things inter-operate.
???
> | You may be right. Then I'll ask him whether he'd have liked to have
> | to care about all those files in the beginning. He may even say he
> | would, but I won't believe him, because, by then, he'll already be an
> | X. Pert, and will are more about his convenience than about
> | difficulties that other new users may have to face.
> :) :) :)
I'm not kidding. I'm very serious about this.
> | He'll have to adjust the Makefiles and cvs add the files. This may
> | become *very* annoying.
> Just as for the rest of the source files, such as Makefile.am.
Which *is* annoying already. Why add more annoyance?
> | > I'm trying to make Autoconf easier. I really do.
> |
> | So am I.
> Yep. That's terrible: I think we want the same things, but we have
> different views on the means. It would have been so simpler to
> completely disagree on the goals, and simply despise each other :)
:-)
> | What complications? Why do you think having an m4_include statement
> | in aclocal.m4 and a separate .m4 file any simpler than a single
> | aclocal.m4? I fail to find it simpler. I find it unneeded
> | complication.
> The static is simpler, the dynamic is much more complex.
Who cares about the dynamic? The user cares about the static, that's
what he sees.
> The whole complexity of your proposal lies in this in between. That's
> what I am still against. The two extremes is something that keeps
> both simplicities. That stuff in the middle of it if what I think is
> unreasonable.
It's a little bit of complexity for us, maintainers, but it's a great
deal of flexibility for our users. I'm pretty sure they'll appreciate
it.
> Alexandre, I think our debate is interesting enough to be make
> public. Would you mind if we send all this thread to autoconf@?
Absolutely. (no, I wouldn't :-)
Except for the minor issue that it starts with a message that presents
the two proposals with a clear favoring of yours. But I can live with
that.
> I fear lengthy threads, which would be a bad thing, but if we expose
> our points of view, maybe we could try to see a consensus emerge.
> But then ``autoconf is full of Mikes :)''.
That's been a problem :-(
I wish we had a list of autoconf newbies to poll...
--
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 *Please* write to mailing lists, not to me
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
>> Let me make it clear, GNU art is certainly a good idea, and I do
>> think of a couple of places where I would use it. Also, it is
>> clear that if GNU art exists, that's the natural base layer for
>> what you want to do.
>> But I still don't think we need such an artillery for that very
>> issue.
Alexandre> Hadn't we agreed this was the way to go for `missing'.
Yep, certainly we agree `missing' should be built. But I'm not sure
something like GNU art would give us all the power we need. It might,
I just have no idea, but we might need to put glue between the section
of subtools, and maybe GNU art will not ne enough. Or we will have to
write a template for it to work on, and in this case, maybe the
templater will be able to do what we were expecting GNU art to.
In addition, I think we should study shtool first, before deciding we
don't want to use it.
There are a few things I don't like in shtool, but maybe his author
would agree to include some changes from us, which would save a lot of
time for everybody.
Alexandre1> The solution I propose is fully backward-compatible, while
Alexandre1> still supporting the advanced uses Mike X. Pert wants.
Akim> To the expense of additional complexity. I really mean that!
Alexandre> I worry more about additional complexity for the user than
Alexandre> for us.
:) You know I mean additional complexity for everybody :) This
includes, Joe, Mike, and Otto M. Tainner.
Akim> You seem to say that I'm lacking of abstraction here, and I hear
Akim> your point, but I disagree that relying on the file system is
Akim> lacking abstraction.
Alexandre> What if the next Akim decides that files are not the right
Alexandre> level of abstraction for splitting m4 macros, and pushes
Alexandre> for a macro-per-file solution? Anyone relying upon files
Alexandre> would lose. That's why I say using files is just an
Alexandre> implementation detail, that the user shouldn't have to care
Alexandre> about.
But this Akim is *wrong*. A tool must never decide to split macros
apart, just as you can just pull a function out of a file.
Files are our modules. You can automatically deal with modules. You
cannot get into them and play arbitrary games.
These modules have properties the macro don't have: they can
AC_PREREQ, they can AC_PROVIDE_IFELSE etc.
The right abstraction is definitely at the level of modules, not of
macros.
(And, BTW, I don't see well what differentiates your approach from
mine here: you were thinking about --add foo.m4, not --add MY_AC_FOO,
weren't you?).
>> In fact there is nothing more important than reusing known scheme.
>> Putting a new wonderful interface extremely powerful will never be
>> justified if there was an existing means to reach the same goals.
Alexandre> Agreed. Let's use a single aclocal.m4 :-) :-) :-)
:) :)
>> In addition, it allows them to simplify the code, and suddenly
>> gives an extraordinary power to the users via all the classical
>> commands!
Alexandre> Except that, if someone ever decides to change the internal
Alexandre> representation, all their extraordinary power becomes a
Alexandre> source of trouble.
I agree with this. But that's our contract with the users to maintain
all the needed backward compatibility they need, maybe indeed, as a
transition step to another solution.
But really, I see no reason for the scheme I promote to be more likely
to be limited than yours. Both may someday be proved complete
inadequate to address this or that issue.
Nevertheless, I trust the two solutions to be generic enough to
address all the issues we might face for a least a few years.
>> The file system is itself is a wonderful interface. It is so
>> natural that there are even things like /proc now! See proc/?
Alexandre> Do you really think it's wonderful that the kernel code
Alexandre> must have code to convert data structures from an internal
Alexandre> format to a text representation and vice-versa, and to deal
Alexandre> with errors when dealing with input? I find the FreeBSD
Alexandre> approach far saner: it's an external, user-level tool that
Alexandre> maps the kernel memory and does the encoding and decoding
Alexandre> of information.
I don't have a clue on how this is done, this is implementation
details :P
I'm just referring to the extraordinary power this gives to the user,
while remaining incredibly simple to use.
>> I do think using the file system does provide some abstract, and a
>> well understood one.
Alexandre> I agree it does provide some amount of abstraction, but
Alexandre> it's not the abstraction our users care about. Our Joe
Alexandre> users care about *macros*, not m4 files developed by
Alexandre> someone else! That's the abstraction we should provide him
Alexandre> with. We shouldn't push any further abstractions upon him
Alexandre> if we can help it.
Hey, again I don't see your point here. Both your and my approach are
basically importing m4 modules. They cannot be finer grained.
And this is still irrelevant anyway, since we can have a tool that
automatically adjusts the modules required by a configure.in. Joe and
Mike have nothing to know about AC_PROG_LIBTOOL, they just need to
know that when autoconf complains, then it probably means they
suddenly depend upon a module they have not imported yet.
They actually don't need to know that modules blah blah, just that
something's missing, and your or my tool will provide it.
>> I really don't know, on gnu.org I know no non Automake package, but
>> there are probably others).
Alexandre> How about GCC, for a start?
Good catch :)
Hm, they ship a single aclocal.m4 with plenty of stuff in there. Hm,
gross. They really need m4_include :)
>> What is the semantics of your `aclocal --extract foo.m4'? It
>> extracts foo.m4 but leaves in there too, or replaces the foo.m4
>> inside with an include of foo.m4?
Alexandre> Whatever we decide it to be. It's clear to me that we
Alexandre> should have both possibilities.
That's the complications I am continuously referring to: there are
zillions of possibilities, which means zillions of if/fi, zillions of
--options, and zillions of lines of documentation.
I agree that with zillions I might be exaggerating. Let's make it
billions :)
>> | > There are just way too many tools you no longer can use.
>> Again, think | > of libtoolize! You'd have to acimport afterwards,
>> or have libtoolize | > acimport?
>> | libtoolize would aclocal in the macro.
>> This is not sane! 1. it means waiting for all the maintainers
>> tools to catch up, 2. it considerably increases the coupling
>> between the packages!
Alexandre> I don't understand. That's precisely what aclocal does
Alexandre> now. What's there to catch up? What coupling are you
Alexandre> talking about?
I'm afraid to see circular dependencies between tools like libtoolize,
and autoreconf for instance. I think updating the package is a work
for autoreconf, not libtoolize.
But I think I don't understand what you mean here. I understood your
sentence as ``libtoolize runs aclocal'', which it doesn't appear to
do:
/tmp % libtoolize nostromo 14:33
Remember to add `AM_PROG_LIBTOOL' to `configure.in'.
You should add the contents of `/usr/share/aclocal/libtool.m4' to `aclocal.m4'.
This seems the good thing to me. I understand `fooize' as `import
everything needed to use foo', not `import and setup my package to use
foo'.
Anyway: these are just fears. Maybe it's a sane approach, I can't
tell, I have not thought enough about it. It's just a feeling: fooize
tools should not try to be too smart.
>> And what when you want to update libtool.m4 and the maintainers
>> knows you must not?
Alexandre> aclocal --force aclocal.m4 [/path/to/libtool.m4]
Alexandre> You wouldn't have to know whether libtool.m4 was inlined or
Alexandre> not at first, it would keep the inline/include status of
Alexandre> each file unchanged.
If you don't know, it's even worse wrt shipping included modules.
That's another useless trap. Better know for sure the behavior than
wondering.
>> Anyway, I think it's the converse that must happen: libtoolize is
>> the low level tool, and it's autoreconf --install that must take
>> care of completing the installation.
Alexandre> Whatever. Both would use aclocal to install libtool.m4 in
Alexandre> the package's tree, either inline or m4_included in
Alexandre> aclocal.m4
This, I'm not sure libtoolize should. The coupling I'm referring too
is precisely having Libtool depend heavily on the interface of
aclocal. It means that libtoolize will need to have the glue code for
Automake's aclocal, then Autoconf's etc.
IMHO, it should address a simple task, installing files in the src
tree, and no more (but displaying further instructions as 1.3.5 does).
But I'm not sure yet, again, this is just a feeling.
>> | The point is precisely to keep Joe willing to use autoconf.
>> Frankly, I just don't care. I'm not here to sell Autoconf.
Alexandre> Great. We don't need users. Who cares about users?
Alexandre> What's the point of having users, if all the fun is in
Alexandre> writing the software?
My sentence is probably too strong and distorts my thoughts. I mean,
I am willing to write a good, an excellent, tool that addresses its
mission. I don't think babizing the tool to catch a wider audience is
its mission.
It is in that sense that I don't care: I'm not here to sell Autoconf
thanks to better colors on the cover, I'm here to have people enjoy a
tool perfectly suited for their problems.
(Yeah, I know your answer, your proposal is even better suited :)
>> You know, we can also imagine that aclocal will check *by default*
>> that the names of the files it includes are in the local Makefile.
Alexandre> What local Makefile? There's no such thing as a local
Alexandre> Makefile, from the point of view of autoconf. autoconf
Alexandre> just AC_SUBST data in generic files. It knows nothing
Alexandre> about Makefiles in particular. There's nothing it can (or
Alexandre> should) do.
I have mixed feelings about this. Please, note I'm only referring to
*checking*, not performing anything.
I agree theoretically with your point. But from a more practical
point of view, our goal is to watch our users, and I doubt there is
more than 1% of configure.in which are not meant to be `make dist'ed.
Hence, it might be good to optimize the warnings for the common cases.
Some kind of aclint.
>> We can provide plenty of new --warnings to assists beginners.
>> That's the sane approach, that's what compilers do! But they don't
>> provide Babyfeatures! They look over your shoulder if you're doing
>> it right, but they are not trying to present a different interface
>> for novices.
Alexandre> Sure they do. Think of `-g'. Real programmers don't use
Alexandre> `-g' :-) :-)
Tss, don't laugh about this: my students are *really* believing in
this. And they -O4... And of course, when I try their project, it
dumps core :(
>> More rules to learn, more matrices with crosses that explain how
>> things inter-operate.
Alexandre> ???
I'm referring to 1. replace unconditionally, 2. don't, a. inline,
b. include, etc. Actually much of the questions I asked, and to which
you gave an answer (sometimes answering: ``Whatever we decide it to
be. It's clear to me that we should have both possibilities.'').
>> | You may be right. Then I'll ask him whether he'd have liked to
>> have | to care about all those files in the beginning. He may even
>> say he | would, but I won't believe him, because, by then, he'll
>> already be an | X. Pert, and will are more about his convenience
>> than about | difficulties that other new users may have to face.
>> :) :) :)
Alexandre> I'm not kidding. I'm very serious about this.
I understand. I mean I *understand*, and do feel this too. But I
was smileying because that's a killer argument which means that *if*
we ask autoconf@ and they are in favor of my scheme, then their answer
is related to their X Pertization. But *if* they favor yours, then
that's even a clearer sign you're dead right, and I'm dead dead.
In other words, the only answer that you leave me here is :) :) :)
>> | He'll have to adjust the Makefiles and cvs add the files. This
>> may | become *very* annoying.
>> Just as for the rest of the source files, such as Makefile.am.
Alexandre> Which *is* annoying already. Why add more annoyance?
Alexandre, again I agree we can have a --baby-option to just have
aclocal.m4. Granted. But I'm against the middle state, because I
think the cure is worse than the disease.
>> | What complications? Why do you think having an m4_include
>> statement | in aclocal.m4 and a separate .m4 file any simpler than
>> a single | aclocal.m4? I fail to find it simpler. I find it
>> unneeded | complication.
>> The static is simpler, the dynamic is much more complex.
Alexandre> Who cares about the dynamic? The user cares about the
Alexandre> static, that's what he sees.
I don't totally agree, just as I don't need a dictionary with just one
page with the words I recently looked for (it's more convenient
though, a perfect babyctionary :). We need them because of the
potential they provide. Just like most of the time shipping
Makefile.am is useless. But it's there because of the non
impossibility we might need it.
>> The whole complexity of your proposal lies in this in between.
>> That's what I am still against. The two extremes is something that
>> keeps both simplicities. That stuff in the middle of it if what I
>> think is unreasonable.
Alexandre> It's a little bit of complexity for us, maintainers, but
Alexandre> it's a great deal of flexibility for our users. I'm pretty
Alexandre> sure they'll appreciate it.
I really don't think they need this additional flexibility.
Really, I'm convinced there are places where you don't want choices,
which are questions, you just need answers.
<<-
>> Alexandre, I think our debate is interesting enough to be make
>> public. Would you mind if we send all this thread to autoconf@?
Alexandre> Absolutely. (no, I wouldn't :-)
OK, I'm sending the digest this message being included.
Alexandre> Except for the minor issue that it starts with a message
Alexandre> that presents the two proposals with a clear favoring of
Alexandre> yours. But I can live with that.
I'll send the digest with the <<-lines->> included as a prologue.
->>
Alexandre> I wish we had a list of autoconf newbies to poll...
[EMAIL PROTECTED] :)
