(wow, _that_ is quite a list of CCs. Hi mum!)
Hi Eric,
Le 26 juin 2012 à 18:18, Eric Blake a écrit :
> Eek - that just shows that I'm really behind on reading my email.
Thou shalt be punished. Beware of my wrath.
> Just from reading this summary, the idea of improving AC_PROG_LEX and
> AC_PR
Hi Ben,
Le 5 oct. 2011 à 18:40, Ben Pfaff a écrit :
> Akim Demaille writes:
>
>> The JVM is quite happy with that. Unless you make the name
>> "invalid" by setting LC_ALL to C for instance, which Autoconf
>> does.
>
> Glib supports a G_FILENAME_ENCOD
Hi Paul!
Le 4 oct. 2011 à 08:42, Paul Eggert a écrit :
> On 10/03/11 07:39, Akim Demaille wrote:
>> The JVM is quite happy with that. Unless you make the name "invalid"
>> by setting LC_ALL to C for instance, which Autoconf does.
>
> Eeuuuw! (I think that'
Hi!
I just spent an unfair amount of time on a problem due to configure setting
LC_ALL to C. The failure was the JVM being unable to load a class file right
in front of it (in .) under configure, but by hand it worked fine.
It turns out that the person who had the problem used French character
Le 6 nov. 07 à 15:33, Benoit Sigoure a écrit :
On Nov 6, 2007, at 3:25 PM, Ralf Wildenhues wrote:
* Benoit Sigoure wrote on Tue, Nov 06, 2007 at 03:13:07PM CET:
Anyone aware of any portability issue with shell parameter
expansions?
Solaris 10 /bin/sh knows neither
${foo#bar}
${foo%bar}
Le 25 déc. 06 à 11:46, Thomas Schwinge a écrit :
[I added the patch's author, Akim Demaille, to the cc list, as it
was not
sure if he's still reading the list.]
You're right, I'm not.
Hello!
Hi, and merry Chrismas.
On Sun, Dec 24, 2006 at 04:21:50PM -0800, Paul E
Years ago, it was suggested to simplify the handling of cross-compilation,
and in particular to no longer require --build: --host alone is the sign that
we're cross compiling.
In Autoconf 2.60, there still remains FIXME about this in general.m4.
How about getting rid of all this now?
Also, the
>>> "Stepan" == Stepan Kasal <[EMAIL PROTECTED]> writes:
> Hello,
>> * Akim Demaille wrote on Wed, May 31, 2006 at 04:26:17PM CEST:
>> > I suggest that Automake provide the same feature for AM_CONDITIONAL:
> well, you already implemented it
>>> "Ralf" == Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> Hi Akim,
> * Akim Demaille wrote on Wed, May 31, 2006 at 04:26:17PM CEST:
>> >>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
>>
>> Some time ag
Le 31 mai 06 à 18:38, Stepan Kasal a écrit :
Hello,
* Akim Demaille wrote on Wed, May 31, 2006 at 04:26:17PM CEST:
I suggest that Automake provide the same feature for AM_CONDITIONAL:
well, you already implemented it, granting Alexandre one point for
his hint:
http://lists.gnu.org
>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Hi!
Some time ago I sent this message for which I had no answer.
> I have this package at hand, say FooBar, which installs a prefixed
> form of config.h. Its own macros are, of course, named FB_*, which i
I have this package at hand, say FooBar, which installs a prefixed
form of config.h. Its own macros are, of course, named FB_*, which is
m4_pattern_forbidden. But then I have to explicitly m4_pattern_allow
all my FB_PACKAGE_VERSION etc.
I suggest that the AC_DEFINE family explicitly allow its $
>>> "Andreas" == Andreas Schwab <[EMAIL PROTECTED]> writes:
> Akim Demaille <[EMAIL PROTECTED]> writes:
>> if (local foo) >/dev/null 2>&1; then :; else
>> local () { true; }
>> fi
> Note that local is only valid in funct
>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
> "local" isn't in POSIX so I'd avoid it in portable scripts.
Doh. Thanks.
> For what it's worth, I briefly searched for this issue and found these
> bug reports dated this year where someone used "local" in a shell
> script and someone
Now that there are no doubts about the portability of shell functions
(in the sense that there's always a shell on the machine that supports
function ---and maybe the documentation should reflect this), I'm
curious about the support of "return" and "local". Is there anything
known about them? IS
>>> "Stepan" == Stepan Kasal <[EMAIL PROTECTED]> writes:
> The option 3) is much safer, and we should rather spend our effort there.
> One question remains, what is "autoconf with functions".
> Autoconf-3 will be probably able to assume shell functions.
> But I don't think we have to wait or
>>> "Ralf" == Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> Might be nice to have the information reusable as well
> (--config comes to mind). See below.
The idea is nice, but the way to use --config should be documented: in
particular how to split properly the output when some arguments
inclu
>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
> This is long enough to be copyrightable. Currently this text is
> redistributable only under the terms of the GNU FDL, which doesn't
> allow you to cut-n-paste it into your program. I'm trying to say
> that it's OK to cut-n-paste this i
>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
> Bruce Korb <[EMAIL PROTECTED]> writes:
>> What if you simply stated:
>>
>> Any programming examples incorporated into this document are
>> hereby released to the public domain and are free for anybody to
>> use any way they like.
> Th
>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
> [...]
Paul> * doc/autoconf.texi (@copying): Allow programs in this
Paul> manual to be copied under the GPL.
> [...]
> Sounds sensible to me. The last sentence of fdl.texi is
>>> "Noah" == Noah Misch <[EMAIL PROTECTED]> writes:
> I hope I have missed a general solution. Ideas?
Fix m4. It has fundamental flaws from its inception:
- text processing builtins (regexp etc.) should return quoted strings,
they do not.
- eval should do what it does it almost all the ot
Le 2 déc. 04, à 21:45, Paul Eggert a écrit :
That's why I'm glad to see this macro (and related changes) moving
ahead, so I can feel free to start using C99 features without worry
(other than users may be forced to upgrade their systems to support
C99 if they have old compilers, but at least they'l
>>> "Patrice" == Patrice Dumas <[EMAIL PROTECTED]> writes:
> the native size of integers (although AC_CHECK_SIZEOF
> may be the solution, it seems C oriented).
It should not: the architecture is made for these tests to be
implementable independently of the language.
Dive into fortran.m4 and c
>>> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> Hi,
> Would you mind if I ship an implementation of m4sugar.m4 with the
> next release of GNU m4, with an eye to replacing parts of it with
> C at some point?
There are some issues
>>> "Nicholas" == Nicholas R Markham <[EMAIL PROTECTED]> writes:
> I recently decided to try to apply the suggestion mentioned in section 17.5 of
> the autoconf manual - namely, to hardcode only the relative path from prefix to
> datadir (or maybe from bindir to datadir) and try to determine pr
>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
> You have to start from scratch (distcheck).
I meant distclean.
___
Autoconf mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/autoconf
>>> "Peter" == Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Donnerstag, 26. August 2004 17:17 schrieb H. J. Lu:
>> [EMAIL PROTECTED] libunwind-0.98]$ ./config.status --recheck --enable-debug
>> config.status: error: unrecognized option: --enable-debug
>> Try `./config.status --help' for m
> On Wed, 2003-12-17 at 10:05, Akim Demaille wrote:
>> > But beware, autoreconf can be dangerous and doesn't always work.
>>
>> Why?
> To make a long story short, some examples:
> 1. autoreconf doesn't work if a package has not been prepared for
> But beware, autoreconf can be dangerous and doesn't always work.
Why?
>> How about cp FILE.in FILE and then perform the transformation from
>> FILE.in's contents to (>) FILE?
> Good idea, but it will fail if FILE.in is read-only.
chmod +w :)
> Hi,
> On Wed, 10 Dec 2003 17:55:04 +0100, Eric Sunshine wrote:
> ...
>> At the very least, it would be a good idea to
>> only use "ls -ld" after checking that such usage is valid (i.e. ensure
>> that "ls -ld" actually works, and works as intended on the target platform).
> As the possi
> On Wed, Nov 26, 2003 at 06:14:01PM +0100, Akim Demaille wrote:
>>
>> >> Does somebody have an autoconf macro to handle adding -R/path/
>> >> stuff when libraries are found?
>>
>> > You find it in the autoconf-lib-link directory of the GN
>> Does somebody have an autoconf macro to handle adding -R/path/ stuff when
>> libraries are found?
> You find it in the autoconf-lib-link directory of the GNU gettext
> distribution.
How about moving these macros into Autoconf now?
> Anyway, back to Dalibor's question:
> 2.57 is the last version announced to [EMAIL PROTECTED]
> 2.58 is the last version available on ftp.gnu.org
> 2.59 is the last version (pre-)announced to [EMAIL PROTECTED]
> Which one is to be considered the last official release? I
> understa
> (Answering only for Automake, because I've also been confused by
> Akim's last statements about announcements that shouldn't be
> considered official.)
Sorry about this. I was trying to make a difference bw pre-released
on my web site, and really released on GNU site. Maybe that was wrong
> Akim Demaille wrote:
>> Nope, indeed, that's why it's too late to change the others. But, IMHO,
>> this interface is merely the unfortunate result of history, where
>> Autoconf was not designed from scratch to support several languages.
>> That'
> Akim Demaille wrote:
>> Yes, but again, some dummies ---such as me---, will really believe FC
>> is polymorphic wrt the Fortran flavor.
> Akim, it's not that you're "dumb," but your use of the macros in the
> test program is *extremely atypic
> ps. I've already sent this to [EMAIL PROTECTED]
Thanks. It's discussed there.
> On Sat, 15 Nov 2003, Akim Demaille wrote:
>> Nope, indeed, that's why it's too late to change the others. But,
>> IMHO, this interface is merely the unfortunate result of history,
>> where Autoconf was not designed from scratch to support several
>> la
Steven G. Johnson a dit:
> On Fri, 14 Nov 2003, Akim Demaille wrote:
>> Steven, you don't seem to read my messages in another thread,
>> precisely related to this:
>>
>> http://mail.gnu.org/archive/html/autoconf-patches/2003-10/msg00116.html
>
> Akim, the onl
> In a discussion about the AC_FC_FREEFORM macro (which figures out how
> to enable freeform-source support for Fortran, if possible), Akim
> wrote:
[...]
Steven, you don't seem to read my messages in another thread,
precisely related to this:
http://mail.gnu.org/archive
> Akim Demaille <[EMAIL PROTECTED]> writes:
>> 2.58 was not announced because it has a problem that affects Automake.
>> I never announced it, and I am somewhat unhappy that Debian has
>> already shipped it. All this mess results from the now asynchronous
&g
> On 2003-11-12T16:12+0100, Akim Demaille wrote:
> ) The Autoconf team is happy to announce its release 2.59. For the time
> ) being it is only available from my web site, but hopefully it should
> ) be on maintstream servers soon. I'll send the release notification
> Akim Demaille <[EMAIL PROTECTED]> writes:
>> > What I see is that half of traffic is spam and that neither Autoconf 2.58
>> > nor Autoconf 2.59 have been announced there. However, the Autoconf 2.58
>> > announcement is in the autoconf-maintainers archi
> What I see is that half of traffic is spam and that neither Autoconf 2.58
> nor Autoconf 2.59 have been announced there. However, the Autoconf 2.58
> announcement is in the autoconf-maintainers archives.
2.58 was not announced because it has a problem that affects Automake.
I never announce
> Hello!
> I've seen an announcement in [EMAIL PROTECTED] that Automake
> 1.7.9 has been released with Autoconf 2.59. I thought it was a typo
> because Autoconf 2.59 has never been announced in the same list.
> Indeed, I checked NEW in CVS Autoconf, it mentions the 2.59 release on the
> sa
> In the Fine Manual:
> @node Coding Style
> @section Coding Style
> In order to highlight the recommended coding style, here is a macro
> written the old way:
> @example
> dnl Check for EMX on OS/2.
> dnl _AC_EMXOS2
> AC_DEFUN(_AC_EMXOS2,
> ...
> and the new way:
> @example
> # _A
> 2. When running autoheader, I got:
> Use of uninitialized value in split at /usr/local/bin/autom4te at line
> 1008.
> Use of uninitialized value in concatentation (.) or string at
> /usr/local/bin/autom4te at line 1007.
> unknown channel For example, try the following from the top-lev
> I encountered the following problems on autoconf 2.57g on HP-UX 11.00:
> 1. On "make install", config/install-sh did not have execute
> permission. I added it then install went ok.
Thanks, I installed the following.
Index: ChangeLog
from Akim Demaille
it thoroughly.
Akim, Alexandre, Jim, Paul, and Tom.
Here are the compressed sources:
http://www.lrde.epita.fr/~akim/download/autoconf-2.57g.tar.gz (1.2MB)
http://www.lrde.epita.fr/~akim/download/autoconf-2.57g.tar.bz2 (907KB)
And here are xdelta-style diffs:
http
> That should read [emacs xemacs], rather than [macs xemacs]. :-)
Blush... Well, it's still better than an accidental [vi xemacs] :)
Thanks :)
> Hi,
> I have a few files with custom Autoconf macros. I can merge these
> files into the file "acinclude.m4", but I would like to keep them
> separate. Therefore I want the aclocal tool to know where to search
> for the files. I do not want to to use "aclocal -I ./config", because
> now
to fail. Here is a patch for Autoconf's configure.ac which adds a
> check for a sufficiently recent version of Emacs.
Thanks, I installed the following.
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
* configure.ac: Quotation and formatting changes.
(EMAC
This is our candidate release for Autoconf 2.58. We plan to release
it soon, so that Automake 1.8 can be released, hence Libtool 1.6, so
that GNU M4 2.0 can be shipped, enabling Autoconf 2.60 ;)
Please, test it thoroughly.
Akim, Alexandre, Jim, Paul, and Tom.
Here are the compressed
> OK, I installed this patch. I can't test it easily, though.
> (For one thing, CVS autoconf doesn't build itself on my host,
> since it depends on an alpha version of autoconf)
Does it? Where?
> 2003-09-30 Paul Eggert <[EMAIL PROTECTED]>
> * lib/Autom4te/XFile.pm: Use Errno.
>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
Paul> Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
>>> When people change configure.ac and run `make -j', that can
>>> trigger simultaneous runs of autoconf, automake, and autoheader.
Paul> If that's the main problem, then we can use a
Eric Sunshine a dit:
> On Sun, 28 Sep 2003 11:58:54 +0200 (CEST), Akim Demaille wrote:
>> Could you make the test case smaller? Are you sure all the tests were
>> run with the modified m4?
>
> I was able to narrow down the "failed with exit status: 139" err
Eric Sunshine a dit:
> On Sun, 28 Sep 2003 11:58:54 +0200 (CEST), Akim Demaille wrote:
>> Could you make the test case smaller? Are you sure all the tests were
>> run with the modified m4?
>
> Okay, I narrowed down the "excess arguments to m4_pushdef" to the
>
>> How very strange. Your successes prompted me to expand my testing to
>> additional platforms. In addition to my earlier trials, I used the
>> SourceForge CompileFarm machines, a MacOS/X machine to which I have
>> shell
>> access, and asked one of the other Crystal Space developers to test with
Eric Sunshine a dit:
> Hello,
>
> On Sat, 27 Sep 2003 19:06:55 +0200 (CEST), Akim Demaille wrote:
>> I just grabbed the tarball, and it works fine here
>> I tried with a more recent CVS m4, and with Debian's with success in
>> both
>> cases. Both M4 did pr
Eric Sunshine a dit:
> On Sat, 27 Sep 2003 10:40:22 +0200 (CEST), Akim Demaille wrote:
>> So finally, some _real_ fun to find in Autoconf... Thanks...
>> I have not looked at your traces yet, but may I ask you to try
>> the following m4 1.4? It is _not_ the regular 1.
as 1.4.1, or
1.5 whatever, and have Autoconf display a warning.
Pay attention that once this m4 installed, it is the one that Autoconf
ought to use: either install it from scratch, or setenv M4 to the new
binary.
http://www.lrde.epita.fr/~akim/download/m4-1.4.tar.gz
> On Fri, 26 Sep 2003 15:26:47 +0200, Akim Demaille wrote:
>> > This is my proposal. Does it work properly for you?
>> 8-)=) I forgot to save the file before asking cvs diff...
>> ac_dir=`AS_DIRNAME(["$ac_dest"])`
>> + AS_MKDIR_P(["$ac_dir
> This is my proposal. Does it work properly for you?
8-)=) I forgot to save the file before asking cvs diff...
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
* lib/autoconf/status.m4 (_AC_OUTPUT_COMMANDS): Make sure the
directory for AC_CONFIG_COMMAN
> Hello,
> I sent this bug report almost a year ago but never received a
> response, nor has the problem been addressed, so I thought I would
> try again.
Thanks for insisting :)
> In Autoconf 2.57 (all releases) and in the CVS version, there is a
> problem with AC_CONFIG_COMMANDS when it
This is my proposal. Does it work properly for you?
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
* lib/autoconf/status.m4 (_AC_OUTPUT_COMMANDS): Make sure the
directory for AC_CONFIG_COMMANDS' first argument exists.
This makes valid the in
It appears to be a wild use of Autoconf. It is certainly part of a
bigger system, and looking only at this file is of no use. Ask the
author how this is supposed to work.
> hi,
> I am novice in using autoconf tools..
> Could you tell me why I am getting these errors..
> autoheader-2.53
> configure.in:8: warning: do not use m4_patsubst: use
> patsubst or m4_bpatsubst
> configure.in:17: warning: AC_PROG_LEX invoked multiple
> times
> configure.in:67: warnin
> Hello,
> I have been trying to compile the mpich 1.2.5 sources.
> In the sources for ch_p4 device ie, in mpich/mpid/ch_p4/p4 when I try
> doing a autoconf to recreate the configuration file I get the following
> error :
> configure.in:280: error: m4_defn: undefined macro: _m4_divert_div
<#secure method=pgpmime mode=sign>
This is our candidate release for Autoconf 2.58. We plan to release
it soon, so that Automake 1.8 can be released, hence Libtool 1.6, so
that GNU M4 2.0 can be shipped, enabling Autoconf 2.60 ;)
Please, test it thoroughly.
Akim, Alexandre, Jim
> [bug-autoconf@ has a stupid filter that doesn't let me through, so I'm
> posting here instead.]
It should be fixed by now. Could you find out why you were blocked?
> On some systems (eg. Linux) flock(2) does not work over network, but Perl
> prefers that over fcntl(2) if it exists. So au
> "Joseph D. Wagner" <[EMAIL PROTECTED]> writes:
>> If it's still in alpha, could you please update the alpha package?
> Even doing that takes some work, I'm afraid.
I'm willing to release 2.58 asap though.
> On Wed, Sep 24, 2003 at 02:19:06PM +0200, Akim Demaille wrote:
>> At the origin I was considering that AC_CONFIG_M4_DIR was
>> automatically passed to m4 as a -I, so instead of
>> m4_include([config/init.m4]) etc. you'd have m4_include([init.m4]).
> Isn&#x
>> The autoconf part of this feature is trivial (I can provide a patch if
>> that's useful), but I suspect I'd need to be able to write perl to
>> implement the aclocal end :-)
> Fortunately, if we consider relative directories as local, we don't
> need to look at AC_CONFIG_M4_DIR. Adding t
> %% "Dr. David Kirkby" <[EMAIL PROTECTED]> writes:
dk> make[1]: Entering directory `/export/home/davek/atlc/src'
dk> cd .. && \
dk> --gnu src/Makefile
dk> /bin/bash: --gnu: command not found
This mean AUTOMAKE is empty.
> On Mon, 2003-08-25 at 08:47, Akim Demaille wrote:
>> > Hi,
>> > Is there any means to run a script at the very end of running
>> > "configure"?
>>
>> > AC_CONFIG_COMMANDS_POST(script) seems to run "script" at the
> I finally was able to get rid of the last package that needed Autoconf 1
> only a year or so ago.
Gee!
> Hi,
> Is there any means to run a script at the very end of running
> "configure"?
> AC_CONFIG_COMMANDS_POST(script) seems to run "script" at the end of
> config.status, before recursing into CONFIG_SUBDIRS.
> Directly invoking a script from inside of the configure-script invokes
> it b
at I should
do with (such as the four first lines). Ignore them...
- My Fencepost account is not reactivated yet, so you might have to
download from
http://www.lrde.epita.fr/~akim/download/autoconf-2.57b.tar.gz (1.1MB)
http://www.lrde.epita.fr/~akim/download/autoconf-2.57b.tar.bz2
>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
adl> [...]
Akim> We could do another release in the near future, let it be just to
Akim> redirect the headers issues onto the package maintainers instead of
Akim> the Autoconf lists.
adl> BT
Peter> Akim Demaille writes:
>> In the long term, I think that a complete rewrite of this macro would
>> be most useful (i.e., actually checking the features we want, instead
>> of this hardwired list of names).
Peter> Why bother? Since everyone is required t
| Okay, this is still eluding me after spending several hours reading
| through the source and I thought I'd double check that I have it
| right. For some reason, shell snippets I include in the testsuite.at
| file do no appear in the final output and I still can't figure out
| why, much less how
Derek> Any talk of when the next release of Autoconf will be? I'm reluctant
Derek> to have CVS depend on an unreleased Autoconf but I really want to use
Derek> the Autotest changes I've been making. Is the Autoconf release
Derek> process documented anywhere?
Not really, partly in the Makefi
Derek> Is there a good reason, other than nobody getting around to it yet,
Derek> that the only Autoshell macros that've been documented are AS_DIRNAME
Derek> & AS_MKDIR_P?
Lack of time to make sure they have an interface we really want to
make definitive, and lack of time to write the documen
>> It occurs to me that this could also be solved by generating a small
>> standalone script using the tmpdir mechanism, to replace the shell
>> function. Would that solution be preferable?
Number one problem is that most of the time, we want the same
environment as configure, so exec'ing a f
I don't think this is the right approach to the problem. We should
first design the interface that config.status needs (mostly
s/@foo@/val/), and implement a tool that does this with existing
tools.
You would give the list of substitution to perform, and then the tool
would make them.
This woul
John> On Fri, Feb 28, 2003 at 10:56:14AM +0100, Akim Demaille wrote:
>> See Autoconf's documentation. Amusingly someone spent some time
>> making an FAQ.
John> There's no reason to take that attitude. I checked the info
John> documentation for the installed
| Is there some relatively sane way of making stuff like $bindir path
| available to C programs (via config.h preferably) ? I'm entirely sure
| I'm not the only one who's had to solve this problem a number of times.
|
| Currently we have (hold your bags nearby) :
|
| if test "$prefix" = "NONE";
>> Actually there are several mistakes. They are fixed in the current
>> version of the annoucement ;)
Thomas> lots of small grammatical errors, for instance.
Thomas> (each time I read it, I see a different one).
Please, point them to me! I'd like to avoid repeating the same
mistakes :(
Pavel> Hello, Akim!
>> The Autoconf team -- Akim, Alexandre, Jim, Paul, and Tom -- is happy
>> to annonce the birth of Autoconf 2.56, aka 2.55 with a packaging
>> problem fixed.
Pavel> Congratulations!
Thanks :)
>> We know that upgrading from 2.13 to 2.5x i
mcmahill> I tried something like this in my configure.ac file:
mcmahill> MYDIR=${datadir}/foo
mcmahill> AC_DEFINE_UNQUOTED(MYDIR,"$MYDIR",[default search directory for foo]
Please, read the documentation, in particular the end of the following
section.
Installation Directory Variables
--
uot;Autoconf"
args: --no-cache
end-language: "Autoconf"
/tmp/bill % echo "AC_INIT" > configure.acnostromo 11:05
/tmp/bill % autoconf nostromo 11:05
/tmp/bill % ls -ltr
The Autoconf team -- Akim, Alexandre, Jim, Paul, and Tom -- is happy
to annonce the birth of Autoconf 2.56, aka 2.55 with a packaging
problem fixed.
- Why should I upgrade from 2.54?
A few bug fixes, improved portability, no known incompatibility with
2.54 and 2.55, forthcoming Gettext
The Autoconf team -- Akim, Alexandre, Jim, Paul, and Tom -- is happy
to annonce the birth of Autoconf 2.55. Download, compile, install,
torture, and enjoy!
- Why should I upgrade from 2.54?
A few bug fixes, improved portability, no known incompatibility with
2.54 and 2.55, forthcoming
| Also sprach Akim Demaille:
| }
| } People, if you want to have something changed in Autoconf 2.55, submit
| } _now_. For instance, autoreconf -R, meaning recurse, as opposed to
| } not recursing by default, would be accepted :)
| }
| I want an option to turn off the creation of
People, if you want to have something changed in Autoconf 2.55, submit
_now_. For instance, autoreconf -R, meaning recurse, as opposed to
not recursing by default, would be accepted :)
Thanks, I'm installing this:
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
* lib/autoconf/c.m4 (AC_LANG_FUNC_LINK_TRY): Wrap the `f'
declaration in extern "C" too.
Reported by Rober
| On 4 Nov 2002, Akim Demaille wrote:
| >- Why should I upgrade from 2.13?
|
| more topical:
|
| why should one upgrade from 2.50-2.53?
|
| those versions are no longer maintained; they are incompatible
| with this week's latest design creep.
:) :) :)
You know who yo
| Akim,
|
| Now that you seem to be at revamping autoreconf's options, just a
| feature request:
Yep, I think there is still much room in autoreconf. I'd like to add
it a --update (=> autoupdate and maybe gettextize for a more recent
gettext), and --check (=> autoscan).
| Woul
The Autoconf team -- Akim, Alexandre, Jim, Paul, and Tom -- is happy
to annonce the second beta of forthcoming Autoconf 2.55. Download,
compile, install, torture, and enjoy!
- Why should I upgrade from 2.54?
A few bug fixes, improved portability, no known incompatibility with
2.54 and 2.55
1 - 100 of 2022 matches
Mail list logo
