[Top][All Lists]

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

Re: [bug-gettext] autopoint and m4_ifndef

From: Pavel Raiskup
Subject: Re: [bug-gettext] autopoint and m4_ifndef
Date: Tue, 23 Jul 2013 08:51:03 +0200
User-agent: KMail/4.10.4 (Linux/3.9.9-301.fc19.x86_64; KDE/4.10.4; x86_64; ; )

> > After this commit we've started using:
> >
> >   autom4te --language=Autoconf-without-aclocal-m4 --trace
> >
> > to capture AC_CONFIG_MACRO_DIR* calls more reliably.  Unfortunately, in
> > practical cases (like above), it may cause errors in M4 level.  I plan
> > to revert it not to use autom4te (patch attached),
> Perhaps we could make the autom4te trace robuster by loading some M4
> files in advance, like the attached patch.  I could successfully
> bootstrap util-linux with it, but maybe there are some corner-cases.
> Comments would be appreciated.

Hm, I see now.  That ^^^ is how it is done (but (imo) too complicated way
to reimplement it once again in gettext) in aclocal.  What about a little
bit different way..

Is there a reason why autopoint/gettextize is run before aclocal?  Because
if there is no important reason, we would be able to run aclocal first and
then use the autom4te like:

  autom4te -I m4 --language Autoconf --trace=*** configure.ac
  // ...................... ^^ not Autoconf-without-aclocal-m4

The problem is that nothing changes in a case the aclocal wasn't run yet.

If there was possible to run aclocal before autopoint, we still need to
wait for 'autoreconf' is ready for this (seem to call autopoint before
aclocal atm).  _So the revert is probably what we want for now, :(_

(Other, quite long-term solution would be to hack aclocal to be able to
give us its *hardly built* list of include files, or used macros, e.g. by
some special option - ehm, but it may even more complicate the aclocal

But that was just my thoughts — somebody more experienced could have
better idea, CC'ing automake list.


reply via email to

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