Le 1 févr. 2013 à 10:35, Stefano Lattarini a
écrit :
> So, is anyone using or playing with Automake-NG, or at least
> contemplating the idea to do so in the short term? Or should
> we just let the project die?
I subscribe to all the good opinions about NG that have been
made here. I would de
On Sat, Jan 12, 2013 at 8:18 PM, Stefano Lattarini
wrote:
> tags 11419 wontfix
> close 11419
> thanks
>
> Reference:
> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11419>
>
> The improvements to the ylwrap script contributed by Akim in the 1.12.x
> and 1.13 relea
Hi all,
Currently Automake accepts happily such a variable name, but it does not use it
(the files are not dist'ed). I agree EXTRA_DIST is fine, but I'm used to being
able to use dist_noinst_* as a kind of over-specification.
Cheers,
Akim
Hi all,
I might have missed the information, but I believe there are no
instruction about handling the dependencies bw libraries are install
time (they all live in the same Makefile.am, and I do not want to
break it). I have libfoo that depends on libbar, and both are
installed in differ
Le 19 mars 09 à 14:53, Ralf Corsepius a écrit :
Akim Demaille wrote:
Hi autofriends!
nobase_ is really a nice feature to cope with a structured
hierarchy of files. But it does not work well with packages that
avoid recursive Makefiles. In my case for instance, my package has
a
Hi autofriends!
nobase_ is really a nice feature to cope with a structured hierarchy
of files. But it does not work well with packages that avoid
recursive Makefiles. In my case for instance, my package has a
hierarchy of files in $(top_srcdir)/include, but it has no include/
Makefile.am
Le 9 déc. 08 à 23:57, Clint Adams a écrit :
[For the automake guys, the question is whether it's possible to have
a computed name for a (libtool) library.]
On Tue, Dec 09, 2008 at 10:44:44PM +0100, Akim Demaille wrote:
I have written this because that's how it appears in
Le 23 sept. 08 à 23:08, Ralf Wildenhues a écrit :
Hi Akim,
Hi Ralf!
* Akim Demaille wrote on Tue, Sep 23, 2008 at 04:35:50PM CEST:
I'm slowly getting rid of my recursive Makefiles. Instead I have one
local.mk per directory, and a few Makefile.ams that include them. Of
course I ha
Hi friends!
I have a suggestion.
I'm slowly getting rid of my recursive Makefiles. Instead I have one
local.mk per directory, and a few Makefile.ams that include them. Of
course I have to prefix all my file names with the name of the
directory, and I find that this explicit name is actua
>>> "RW" == Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> Hello Akim,
Hi Ralf,
>> So I would like to be able to write something like
>>
>> TEST_SUITES = foo bar
>> foo_TESTS = foo1.chk foo2.test foo3
>> bar_TESTS = bar1.test bar2
>>> "RW" == Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> Hello Benoit,
Hi Ralf,
Sorry for answering so late...
> Can you rid it of nonportable constructs, and more importantly, can it
> be included in Automake (copyright transfered to the FSF etc.)?
Sure, no problems.
> Hmm, let's see.
Le 19 oct. 07 à 19:16, Ralf Wildenhues a écrit :
Hello Benoit,
* Benoit SIGOURE wrote on Fri, Oct 19, 2007 at 06:48:25PM CEST:
# Add boost libraries.
AM_CXXFLAGS += $(BOOST_CPPFLAGS)
AM_LDFLAGS += $(BOOST_LDFLAGS) $(BOOST_THREAD_LIB)
Don't put libs (-l...) in LDFLAGS, it messes up the ord
>>> "RW" == Ralf Wildenhues <[EMAIL PROTECTED]> writes:
>> Hi Ralk, I missed your answer :)
> Hehe, interesting typo. Ralph is a more common one. ;-)
How bizarre... I don't how I managed to get this one kucked up. The
feys are not even close!
> Sure. I think the addition of AM_LIBADD/t
>>> "RW" == Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> Hello Akim,
Hi Ralk, I missed your answer :)
> * Akim Demaille wrote on Fri, Nov 03, 2006 at 05:56:16PM CET:
>>
>> For the records, I could use AM_LIBADD as a default value of
>>
It would be nice if it were possible to run tests in parallel using
automake. Waiting for tests to complete on a 4-way box while they
are run
on a single CPU is annoying. As most 'make' implementations already
support running in parallel (-j), automake could just utilize this
functionality to
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
For the records, I could use AM_LIBADD as a default value of
libfoo_la_LIBADD. Currently it is not recognized.
>>> "Ralf" == Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> Hello Akim,
> * Akim Demaille wrote on Sun, Oct 22, 2006 at 01:10:02PM CEST:
>> >What would be the cleanest means to handle this exception?
>>
>> Here is what I did:
> I t
While we're one that topic, I don't understand why cleaning the tags
is hooked to distclean instead of clean.
Sorry if this is a faq, but I have found nothing convincing, excepted
this unanswered message:
http://sourceware.org/ml/bug-automake/2001/msg00391.html
and
http://sources.redhat.com/ml/bug-automake/2003/msg00311.html
where adl seems to agree it should be cleaned.
I don't understand
What would be the cleanest means to handle this exception?
Here is what I did:
- Force automake to generate an object specific rule by
using some foo_CXXFLAGS
- Open Makefile.in, get the specific rules.
- Use LTCOMPILECXX to factor the common part
- Append $(MY_NOPTION_CXXFLAGS) to it
- rename
I have this cross-compiler at hand that cannot compile some of my
big files (a Bison parser) with -O2. Stacking -O0 on top of -O2
does the trick. But I don't know the recommended way to do that.
Since I'd like to the keep the good old -g -O2 for the rest of
the compilation, since I don't want t
ISTR that there was a means, via a macro traced by Automake, that
there was a means to ask it to automatically ship some files.
Something similar to AC_LIBSOURCES, but more general.
I can't find anything like this. Did I dream about it?
It would probably make sense to have a warning in case a Makefile.am
has install-*-local rules but no uninstall-local. BTW, I must say I
don't really understand why, at least to keep symmetry, all the
install-*-local targets are mapped to a single uninstall-local one.
That there is one is nice, b
>>> "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
>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
Akim> is there really any point?
> It's simple to implement and it's cleaner to use. It also shows a
> good example of an interface we would both like to see in many
> other tools.
g an operation mode where texi2dvi cleans itself the
> auxiliary files that it would otherwise create sounds right to
> me. In other words, I'd like `make mostlyclean' to call
> `texi2dvi --mostlyclean input.texi' for all `input.texi',
> instead of having to know how te
>>> "Karl" == Karl Berry <[EMAIL PROTECTED]> writes:
[The thread starts in
http://lists.gnu.org/archive/html/bug-texinfo/2005-05/msg00019.html]
> finding the xref files is much easier,
> That's a good point. Finding all those aux files has always been a drag.
> Still wanna keep the
>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
> Whether using libtcswigpy_la_LDFLAGS in addition to AM_LDFLAGS is
> an error I don't know.
It is not nice: (i) it is a different semantics than the other
variables, and (ii) the more common semantics is more flexible.
> OTOH, the
It is my understanding (after having re-read the doc ;) that these
flags are exclusive: either one of the two is used. So I have in a
Makefile.am of mine:
| AM_LDFLAGS = -avoid-version -module -shared
| ...
| # Override AM_LDFLAGS: this guy must not be a module.
| libtcswigpy_la_LDFLAGS =
and M
Why isn't it enabled when using tar-v7?
>>> "Paul" == Paul Smith <[EMAIL PROTECTED]> writes:
> %% Akim Demaille <[EMAIL PROTECTED]> writes:
>>> I need a way to have a file marked as a config file, but not have
>>> configure (or automake) fail if the .in input file doesn't
I'd like that!
>>> "Paul" == Paul Smith <[EMAIL PROTECTED]> writes:
> %% Akim Demaille <[EMAIL PROTECTED]> writes:
>>>>> "Andreas" == Andreas Schwab <[EMAIL PROTECTED]> writes:
>>> Untested code ahead.
>>> m4_syscmd([test
>>> "Andreas" == Andreas Schwab <[EMAIL PROTECTED]> writes:
> Untested code ahead.
> m4_syscmd([test -f build.sh.in])dnl
> m4_if(m4_sysval, 0, [AC_CONFIG_FILES(build.sh)])
Bad idea: side effects are incompatible with the (autom4te) cache. If
the environment changes but not the sources of con
>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
> [...]
Akim> I don't know how to do that without using .SECONDARY,
Akim> which doesn't appear to be univ
>>> "Stepan" == Stepan Kasal <[EMAIL PROTECTED]> writes:
> I guess the following should fix it:
> $(generated_sources): $(makedoc_SOURCES) $(cmd_sources)
> make $(AM_MAKEFLAGS) makedoc$(EXEEXT)
$(MAKE)
> rm -f $(generated_sources)
> ./makedoc $(cmd_sources)
> This way the
Hm, reading more carefully, I see no connection between the
generated_sources and what they are used to. I would say your
Makefile is missing dependencies, that's why it 'works'. But an
update of one of the cmd_sourcs will probably not update the whole
set, as it should.
>>> "Stepan" == Stepan Kasal <[EMAIL PROTECTED]> writes:
> Hello Akim,
Hi!
> --
> noinst_PROGRAMS = makedoc
> bin_PROGRAMS = ginfo infokey
> makedoc_SOURCES = makedoc.c
> ginfo_SOURCES = echo-area.c echo-area.h ... \
> doc.c f
Suppose you have a file generated-output that's built from feeding
generator with input. generator itself is built from
generator.sources.
I would like to ship generated-output (hence it's in srcdir), to spare
the user the need to build it. I don't know how to do that without
using .SECONDARY,
How is one expected to request to ship some Texinfo files, but not the
info files, as these are to be built?
I found nothing in the documentation, and a naive
nodist_info_TEXINFOS = assignments.texi tiger.texi
does not ship the texi files (of course...). And this, naive also,
approach
Le 23 août 04, à 18:58, Paul D. Smith a écrit :
%% Akim Demaille <[EMAIL PROTECTED]> writes:
ad> I met a problem on Mac OSX, and diagnosed it as follows. I
would not
ad> call this a problem in Automake. Probably GNU Make 3.79 is the
most
ad> likely culprit, but at le
>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
>> makeinfo does not update timestamps of directories:
> Is there a problem with this patch?
Ping!
>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
> makeinfo does not update timestamps of directories:
Is there a problem with this patch?
Makefile.am:
install-data-local:
cp -r $(HTMLS) $(DESTDIR)$(htmldir)
And unfortunately this -local target is triggered before Automake's
code, which results in:
~/lectures/maintain % sudo -u doc make install nostromo 14:46
make[1]: entrant dans le répertoire « /home
makeinfo does not update timestamps of directories:
% ls -dltr maintain.{texi,html} nostromo 15:12
drwxr-xr-x2 akim lrde 4096 2004-05-25 14:38 maintain.html/
-rw-r--r--1 akim lrde16132 2004-05-25 15:01 maintain.texi
% LC_ALL=C /bin/sh /home/akim
[Sorry for the delays, I have suffered sysadmin issues.]
1BGDpl-0001aY-Fa-D
Are there any plans of texi->text support? The recent very welcome
addition of pdf and html targets seem to call for other outputs: plain
text, XML and so forth.
The fact that Automake infers some source file names from
check_PROGRAMS = test-foo
is really nice. Nevertheless, it is nice to people who program in C,
and less to other languages. Couldn't we look for test-foo.EXT with
EXT ranging a well defined series instead of the hard coded `c'?
I k
Hi!
I'm looking for the recommended way to handle Python executables.
I've read the current documentation, but it refers only to Python
libraries (unless I'm mistaken).
Looking for some inspiration, I found this old piece of code from
François Pinard, but it's problem completely outdated.
> Personally, I positively *like* "witness" - it describes what it is
> in a colourful way.
For the records, this is the official English word for the same
concept in logic. A witness of an existential quantifier \exists
x. P(x) is precisely a t such that P(t). So I believe witness is
perfect
> I'm considering dropping support for Perl 5.005 in the future
> Automake 1.9, and require at least Perl 5.6. Perl 5.6 will be 4
> years old next month, so it does not sound like asking for the
> moon.
Actually, why not jumping to something really more recent. Some
people will have to upgr
> (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
> Hi,
> Akim Demaille wrote:
>> > It is possible to do the internationalization in such a way, that
>> > automake would still run without libintl-perl being installed.
>> > License problems should not be an issue, libintl-perl is distributed
>> >
> Hi,
> beginning with version 0.13, GNU gettext has full support for Perl
> scripts, with libintl-perl (http://search.cpan.org/dist/libintl-perl/)
> there is a stable runtime environment for gettext like message
> translation in Perl, and with yours truly there is somebody available
> that
> When having several dozens of configure.ac's in source tree and even
> more custom aclocal macros, causing 100's of warnings, you may relate
> why I don't share your opinion.
perl -pi.bak -e 's/(AC_DEFUN\()(\w+\),/$1[$2],g' **/*.{ac,m4}
should make it!
> Hi,
> With the release of automake-1.8 ahead, a request for enhancement:
> automake-1.8 probably will be incompatible to automake-1.7
> Up to now I have encountered 2 incompatiblities:
> * The generating info files in $srcdir issue.
> * aclocal complaining about underquoting in custom m
> 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
arball available.
> I'm using the AUTOCONF-2_59 tag from CVS. I didn't know it
> hasn't been announced yet. All I can say is that Akim is away
> today and tomorrow, so you'll have to wait if you want an
> official tarball.
I have a problem on my machin
y, I meant "it should be autoreconf".
> /if it's used/
I'm installing the following. Thanks.
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
* lib/autom4te.in (Autoreconf-preselections): Trace AC_CONFIG_AUX_DIR.
* bin/autoreconf.in (autoreconf_cur
> Hello, GNU autotools contributors!
> Im just ajust my package for realy good building. And I would like to
> thank you for realy powerful and useful tool :)
This is probably the wrong list: you are probably not referring to the
Autotools: Autoconf, Automake, and Libtool.
Or else, you're one
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
<#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
Several projects used config/ without any hand written file in it,
thanks to Automake's wonderful ability to ship the files all by
itself. But then, often, such projects, when just checked out, or
de-tar'ed by hand, don't have a config/. Et soudain, c'est
l'accident :
~/src/vampire % autoreconf
> 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
> I have a number of files that need variable substitution, so I do this in
> a Makefile.am:
> foo: foo.in
> @rm -f foo
> @sed \
> -e 's,@@perlmoduledir@@,$(libexecdir)/perl,' \
> -e 's,@@swishbindir@@,$(bindir),' \
> -e 's,
> %% "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.
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
t; So I think texi2dvi should be changed to clean texput.log
> afterwards (or run tex --help in a temporary directory).
I suggest this patch, which includes another one pending for Texinfo.
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
Workaround a TeX bug: --file-lin
> On Tue, 2003-07-15 at 08:57, Ralf Corsepius wrote:
>> On Tue, 2003-07-15 at 08:25, Alexandre Duret-Lutz wrote:
>> I'll try to contact the original reporter, but currently would assume
>> this to be a local bug in the package or a miss-understanding by the
>> original reporter.
> This pro
bution: "; \
>> for i in $(DIST_ARCHIVES); do echo $$i; done) | \
>> sed -e '1{h;s/./=/g;p;x}' -e '$${p;x}'
> This seems to make my NetBSD sed unhappy... Thoughts?
I'm installing the following.
Index: ChangeLog
from Akim Demaille <[EMAIL PRO
posed
>> to work with?
> 7.0
Err, maybe my message went unnoticed, but you might find additional
information here too.
From: Akim Demaille <[EMAIL PROTECTED]>
Subject: Re: Icc 7.0, distcc, Automake
To: [EMAIL PROTECTED]
cc: Automake List <[EMAIL PROTECTED]>
Date: Thu, 26 J
For the records, I'm using the following script. It results in a
correct compilation with Automake, Icc, and Distcc.
#! /bin/sh
icc=/home/lrde/lrde/usr/bin/icc
# ICC needs to be taught that *.ii is C++.
# The wonderful news is that:
#
# % /home/lrde/lrde/usr/bin/icc I-dont-exist
# ld: cannot o
I make some progress understanding why I find it hard to use Icc with
distcc. I face several problems, some of them might be already known.
Currently, I use the following wrapper to make sure Icc understands
what .ii is about:
/tmp % cat =icc nos
| But when I used distcc, all is lost with the -MD flags
|
| | /tmp % distcc /home/lrde/lrde/usr/bin/icc -Kc++ error.cc -c nostromo 18:58
| | error.cc(2): error: function "foo" has already been defined
| | int foo () { return 1;}
| | ^
| |
| | compilation aborted for /tmp/distcc_106
>> But how about making automake even smarter?
>> 1. AC_CONFIG_FILES etc. are to be DISTCLEANED (aren't they already?)
>> 2. nodist_ and target of a rule => CLEAN
> What if the file is in both? I have package-config file which is
> generated by configure (AC_CONFIG_FILES) and then installed
> Earnie Boyd wrote:
>> Akim Demaille wrote:
>>
>>> > On Tue, Jun 24, 2003 at 02:02:25PM +0200, Akim Demaille wrote:
>>> >> >> Why wouldn't nodist_ stuff be automatically included into
>>> CLEANFILES?
>>>
>&
~/src/tc % make nostromo Err 2
cd . && /bin/sh /home/akim/src/tc/config/missing --run aclocal-1.7a -I config
cd . && /bin/sh /home/akim/src/tc/config/missing --run automake-1.7a --foreign
/usr/local/bin/m4: config/warning.m4:2
> On Tue, Jun 24, 2003 at 02:02:25PM +0200, Akim Demaille wrote:
>>
>> Why wouldn't nodist_ stuff be automatically included into CLEANFILES?
> I think it would make sense.
> http://www.cygwin.com/ml/bug-automake/2002/msg01693.html
I would love this. The only
Why wouldn't nodist_ stuff be automatically included into CLEANFILES?
I often find myself repeating things because of this.
> On Mon, Jun 02, 2003 at 09:09:23AM +0200, Akim Demaille wrote:
>>
>> I discovered a nice property of AC_CONFIG_AUX_DIR and (CVS) Automake:
>> you can use the Autoconf macro, and not provide a Makefile.am for this
>> directory. The content is properly shi
I discovered a nice property of AC_CONFIG_AUX_DIR and (CVS) Automake:
you can use the Autoconf macro, and not provide a Makefile.am for this
directory. The content is properly shipped, everything works fine,
and you saved one AC_CONFIG_FILES, one Makefile.am, one SUBDIRS.
I don't know if this is
Harlan> Thanks - my goal is to produce some number of checksum files
Harlan> (md5, "sum", pgp, gpg, whatever) at the time I produce the
Harlan> distribution *balls.
Harlan> I'd then "publish" the *balls and checksum files.
Harlan> I'm not sure I care about validating this on the user's side
| > Aharon> Thanks Tom. I'll wait for Akim to reply and/or forward to Andre.
| > Aharon> Akim, this happens pretty consistently for me with automake 1.7.3,
| > Aharon> autoconf 2.57 and current gawk; just touch configure.in in that dist
| > Aharon> and type make.
Richard> But won't that break the automake rules? They expect the lex
Richard> output file to be called $LEX_OUTPUT_ROOT. $LEX_OUTPUT_ROOT
Richard> is different on Linux than DJGPP (lex.yy vs. lexyy). If I
Richard> use %option outfile and %option prefix, it will work on one
Richard> platform,
| Hello.
Hi!
| I recently converted one of my projects to autoconf 2.57 & automake
| 1.7.3. I'm not bothered about portability to systems other than
| DJGPP or Linux. In particular I've been using switches that are
| particular to flex and bison: those to set the prefix of the lexer
| and parser
| Hi,
| I'm using flex as the lexer, and I'm using flex's
| support for prefixes. So when I put a
|
| %option prefix="dfg_"
Use prefix and outfile to please Automake.
src/bison/src % fgrep %option scan-gram.l nostromo 9:59
%option debug nodefault noyywrap never-interact
Olaf> Hello automake team,
Olaf> I'm using
Olaf> AM_INIT_AUTOMAKE([foreign 1.5 no-define dist-bzip2])
Olaf> which will create a tar.gz and tar.bz2 dist. How can I prevend
Olaf> automake from building the tar.gz dist, since there isn't a
Olaf> target like no-gzip-dist.
By submitting a patc
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
> "Bob" == Bob Proulx <[EMAIL PROTECTED]> writes:
Bob> If you want to change this you can set CXXFLAGS at configure
Bob> time.
Bob> CFLAGS=-O CXXFLAGS=-O ./configure
./configure CFLAGS=-O CXXFLAGS=-O
is better.
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
| Since upgrading from autoconf 2.54 to 2.54b, automake 1.7.1 gives me tons
| of warnings:
|
| configure.ac:27: warning: back quotes and double quotes must not be escaped in:
|$as_me:$LINENO: WARNING: \`$CC' requires \`$lt_cv_prog_cc_shlib' to build shared
|libraries
| configure.ac:27: warnin
| This also works for things like
|
| foo = mumble
| foo = blurgle
|
| which would be interpreted as
|
| foo = blurgle
| if FALSE
| foo = mumble
| endif
I've always thought this is wrong. I still think we should not
support such ``feature'', which is a form of laxism to me, comp
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.53 and 2.54
The Autoconf team is happy to annonce the first beta of forthcoming
Autoconf 2.55. Download, compile, install, torture, and enjoy!
Akim, Alexandre, Jim, Paul, and Tom
ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.54a.tar.gz (1.1 MB)
ftp://alpha.gnu.org/gnu/autoconf/autoconf
| hi akim,
| first, thank you for responding!
|
| i finally did find out what was wrong: autoconf 2.5x and 2.13 debian
| packages were both installed on my system. the *packages* don't
| conflict but the programs do. inadvertantly, some of what i did used
| the 2.5 tools and some used the
1 - 100 of 965 matches
Mail list logo
