| On Feb 2, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
| >>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
| Alexandre> Only CVS autoconf accepts implicitly quotes backticks in
| Alexandre> MSGs. But it complains if backtick is already quoted.
| Alexandre> Relying upon the autoconf-CVS behavior is a mistake, IMO,
| Alexandre> and the fact that autoconf complains (warns) about quoted
| Alexandre> backticks is also a mistake, IMO. I'd rather revert to the
| Alexandre> explicitly quoted backtick in automake, and arrange that
| Alexandre> autoconf doesn't complain about the quoted backtick. Akim?
| Alexandre> Tom?
OK with that, but in the future, it should be reactivated.
| > My opinion is that we implicitly supported the idea that using CVS
| > Automake *is* using CVS Autoconf and conversely.
|
| Not if it can be helped. CVS autoconf requires a whole lot of changes
| in `configure.in's to keep it quiet, and automake is still usable
| without any of these features. I'm totally against coupling releases
| of software unless it can't be helped. Which means that I'd really
| like if automake CVS could still be used without autoconf CVS, even
| after it is improved to make use of --trace and such. Yes, this means
| keeping backward-compatibility code. Which, IMO, is a good thing.
The whole point of --trace is to remove the internal knowledge
Automake has of Autoconf. I consider this as a flaw serious enough so
that we require a simultaneous update here.
We are not breaking compatibility. Yes, there are warnings, but
warnings still belong to the same world, the code needs no change.
Have a look at the current Autoconf: it uses AC_PROG_GNU_M4 which
Automake doesn't know, so Automake does not give the template for
@M4@, we have to give it by hand.
This is bad, very bad. Because of the former design, Automake had to
do this. It should no longer do that. If you want to maintain
compatibility, then I see no point in moving to --trace.
Actually, you still require that the users update their Automake when
moving to Autoconf 2.15, precisely because there are many constructs
that are not supported by 1.4.
As I already detailed in many threads, I really think we should
release Automake 1.5 and Autoconf 2.15 so that we no longer have to do
that. I might be over optimistic, but to me autoconf --trace is
revolutionizing the relationship between the two. We must make the
big jump, because for the design point of view, we considerably ease
our task, *and* the users are provided with a much more robust
framework.
| I have enough trouble convincing other developers of other projects,
| such as Kaffe, to use libtool and automake from CVS, because they
| offer features we really need. I'd rather not force them to install
| and use autoconf CVS too.
People walking on the wild CVS tracks should be ready to move to the
three amigos at the same time. I know this is not good, I know this
perfectly well, but IMHO we face a major revamping of the whole
system, and we ought to make it right, not polluted because of comfort
for this or that particular person.
The separation between Autoconf's and Automake's responsibilities is a
major improvement over the previous scheme. There should not remain
any molten cheese threads between the Automake pizza part, and the
Autoconf pizza part. Let's cut frankly, and end with the Automake's
nightmare which tries to palliate the Autoconf flows.
We're doing free software. There is no warranty whatsoever that the
maintainers will complicate their tasks and compromising their future
just for a little additional comfort.
And again, I shall emphasize that this little comfort is a myth: you
*need* to update Automake if you update Autoconf, let it be because
Automake still doesn't support AC_CONFIG_FILES, AC_CONFIG_HEADERS and
the like, new AC_SUBST variables etc.
| > So, though I'm not frankly against having this silent, I'm not in
| > favor of it.
|
| This problem has just cost me a whole hour of investigation, trying to
| figure out what the heck was wrong with AC_PROG_LN_S, which was where
| bash reported the error to be (after the matching backtick). I even
| suspected someone had hacked into the lab and replaced bash with some
| non-working shell!
I don't understand what you mean. This issue has be commented several
times, and in addition the guilty message is given explicitly in the
warning. I agree though that the location of the warnings are usually
not very pertinent.
Akim
