libtool
[Top][All Lists]
Advanced

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

Re: Libtool 1.4.3


From: Akim Demaille
Subject: Re: Libtool 1.4.3
Date: 10 Oct 2002 11:27:02 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter)

| > You want autoconf -f then.
|     -f, --force              consider all files obsolete
| 
|     We do a ./cvsclean right now for autoconf +2.50 which purges
|     all generated data.  I guess that is basically the same.
| 
| > You know, you are typically the kind of people who has valid grieves
| > against Autoconf, but using things that were never documented.
| 
|     You have lost me.  Why should autoconf document any valid m4
|     command?

Because Autoconf is not M4!  Because such a large framework must make
provisions precisely so that the whole architecture work.  Ans esyscmd
is teh best example of what cannot be kept.

| > esyscmd is definitely excluded from our framework.
| 
|     Then you need to document that.  Neither 2.13's nor 2.54's
|     autoconf.info says anything to that effect.

OK.  I agree that

| Programming in M4
| *****************
| 
|    Autoconf is written on top of two layers: "M4sugar", which provides
| convenient macros for pure M4 programming, and "M4sh", which provides
| macros dedicated to shell script generation.
| 
|    As of this version of Autoconf, these two layers are still
| experimental, and their interface might change in the future.  As a
| matter of fact, _anything that is not documented must not be used_.

is not clear enough, it seems to refer to M4sugar and M4sh only.  And

| Changed Macro Writing
| ---------------------
| 
[...]
|    If you were doing tricky things with undocumented Autoconf internals
| (macros, variables, diversions), check whether you need to change
| anything to account for changes that have been made.  Perhaps you can
| even use an officially supported technique in version 2 instead of
| kludging.  Or perhaps not.

is hidden.


| > But you kept developping your Autoconf instead of coming and
| > deciding for a solution.
| 
|     I cannot parse that sentence.

Sorry :)  I mean, when you clear hit a limitation of a tool,
contacting the developper of the tools will certainly provide a better
solution that doing something on your side.




reply via email to

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