bug-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: YYSTYPE_IS_TRIVIAL


From: Akim Demaille
Subject: Re: YYSTYPE_IS_TRIVIAL
Date: 24 Apr 2002 12:53:18 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp)

>>>>> "Paul" == Paul Eggert <address@hidden> writes:

>> From: Akim Demaille <address@hidden> Date: 23 Apr 2002 11:07:06
>> +0200
>> 
>> Actually, the problem is that I'm not sure what is right.  What
>> happens is that autoreconf sees that aclocal will produce the same
>> aclocal.m4, so it decides not to update it, it just leaves the old
>> one.  But then, the Makefile see that aclocal.m4 is `obsolete' as
>> compared to one of its sources.

Paul> Which source changed?

Autoreconf does (now) the following:

1. aclocal to make tracing faithful
2. autoconf --trace 
   to see if libtool, automake, autoheader and gettext are used.
3. gettextize
4. libtoolize
5. aclocal (3 & 4 may have installed new local m4 files)
6. autoconf
7. autoheader
8. automake

The problem is that at point 1., we already have the right aclocal.m4:
the gettext macros are found in /usr/*/share/alocal/ by aclocal, which
pastes them into aclocal.m4.

Then, and point 5, autoreconf sees it is creating the same aclocal.m4
again, so it keeps the old one, to avoid relaunching autoconf etc.

But then, when automake is run, the Makefiles have dependencies for
aclocal.m4 which point to the *local* copies of the gettext macros,
now installed in m4/.

So the whole process is started again :(


>> What I would like is being able to see if aclocal.m4 is up to date
>> as compared to its sources, unfortunately, aclocal.m4 does not
>> reveal its sources, so I can't.

Paul> But you know what the sources are in this particular case,
Paul> right?  So even if you can't solve the problem in general, you
Paul> can solve it for Bison.  And once you do that, perhaps you can
Paul> generalize the solution.

This is what I'm aiming at, but right now, I still don't see a
pleasant solution.

Actually, maybe (ahem, I won't dare pointing this out to Bruno) the
real problem is the lack of consistency of Gettext: it should decide
once for all if

- the macros *must* be copied locally
  in which case, they must not be visible to aclocal

- the macros must not be copied locally
  in which case, gettextize should not install them

- the user can choose
  in which case something similar to --intl is needed.

-- 
Ashamed.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]