| 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
| 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
ChangeLog 4 Nov 2002 08:47:39 - 1.2092
**
2002-11-04 Akim Demaille <[EMAIL PROTECTED]>
Version 2.54c.
* Makefile.maint (update, cvs-update, po-update, do-po-update):
New.
> "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 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 Gettex
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 release
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
| 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
| 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
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,
| > 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.
| >
| > Hi Aharon,
| >
| > I
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
> 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
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
Why wouldn't nodist_ stuff be automatically included into CLEANFILES?
I often find myself repeating things because of this.
> 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
~/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:23: EOF in string
autom
> 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?
>>>
>&
>> 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
| 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
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
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
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
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
> 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
*****
2003-08-22 Akim Demaille <[EMAIL PROTECTED]>
Version 2.57b.
* Makefile.cfg (local-checks-to-skip): New.
* Makefile.maint (local-check): Rename as...
(local-checks-available): this.
(local-check): New.
* Makefile.am (EXTRA_D
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
> %% "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.
> 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,
>> 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
> 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
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
NEWS
* Major changes in Autoconf 2.57d
* Major changes in Autoconf 2.57b
Released 2003-08-24, by Akim Demaille.
** Autotest and local.at
The optional file local.at is always included in Autotest test suites.
** Warnings
The warnings are always issued, including with cached runs.
This be
Released 2003-10-01, by Akim Demaille.
* Major changes in Autoconf 2.57e
Released 2003-09-29, by Akim Demaille.
** AC_CONFIG_COMMANDS
The directory for its first argument is automatically created. For
instance, with
AC_CONFIG_COMMANDS([src/modules.hh], [...])
$top_builddir/src
> 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
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
>>> "Chuck" == Charles Wilson <[EMAIL PROTECTED]> writes:
Chuck> What is this "Autoconf 2.59" of which you speak? I saw this
Chuck> http://mail.gnu.org/archive/html/autoconf-patches/2003-11/msg00010.html
Chuck> But there does not yet appear to be a tarball available.
> I'm using the AUTOCONF-
> 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
> 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
> 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,
> 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
> 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
>> >
> (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
> 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
> 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
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.
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
[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.
maintain.texi
/home/akim/lectures/maintain/maintain.html/index.html: Permission denied
make: *** [maintain.html] Erreur 1
so I suggest the following change:
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
* lib/am/texibuild.am (.texi.html): Touch the output to update its
Hi!
What is the recommended way to install split HTML documentation from
Texinfo? It would be nice if Automake had the bit of magic to copy
directories, instead of simple files, in this precise. In addition,
there is a small catch when the user does it by herself: I had the
following in my Mak
>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
> makeinfo does not update timestamps of directories:
Is there a problem with this patch?
>>> "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!
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
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
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,
>>> "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 funs.h
> infokey_SOURCES = infokey.c infokey.h key.c
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:
> 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
>>> "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
>>> "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
>>> "Paul" == Paul Smith <[EMAIL PROTECTED]> writes:
> %% Akim Demaille <[EMAIL PROTECTED]> writes:
>>>>> "Andreas" == Andreas Schwab <[EMAIL PROTECTED]> writes:
>>> Untested code ahead.
>>> m4_syscmd([test
I'd like that!
>>> "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
Why isn't it enabled when using tar-v7?
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
>>> "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
>>> "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:
>>> "Karl" == Karl Berry <[EMAIL PROTECTED]> writes:
>>> So the new work is merely to add *.t2d in .cvsignore (or whatever), and
>>> CLEANFILES = *.t2d in Makefile.am, until Automake is updated?
> Can we work on an interface that wi
>>> "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.
Of course you're right. Thanks for keeping me a
> "Johan" == Johan Rydberg <[EMAIL PROTECTED]> writes:
Johan> ... It says that I should run autoupdate (which I have done) to
Johan> corrent this, but nothing happens. autoupdate doesn't update
Johan> the specified line.
What is the exact message? Though this line may have triggered the
mes
> "Merijn" == Merijn de Jonge <[EMAIL PROTECTED]> writes:
Merijn> This line is too long for configure to instantiate and the
Merijn> result is a truncated line of dependencies.
What happens? Do you know where this limitation comes from?
Akim
> "Assar" == Assar Westerlund <[EMAIL PROTECTED]> writes:
Assar> "Gabor Z. Papp" <[EMAIL PROTECTED]> writes:
>> can I use/define somehow additional aclocal directory, where I can
>> put additional m4 files?
Assar> Yes, use `aclocal -I dir' where dir is the directory of your
Assar> additional
| On Mar 13, 2000, "Gary V. Vaughan" <[EMAIL PROTECTED]> wrote:
| > I would still like to see {auto{conf,make},libtool} use Ralf
| > Engelschall's shtool (or a variant of it) to encapsulate the
| > portability issues of things like mkdir -p and mkdir -m 700 into a
| > single script rather than sc
>>>>> "Assar" == Assar Westerlund <[EMAIL PROTECTED]> writes:
Assar> Akim Demaille <[EMAIL PROTECTED]> writes:
>> ACLOCAL_AMFLAGS = -I dir
>>
>> which is slighly better, since I don't think autoreconf will
>> recogni
>>>>> "Earnie" == Earnie Boyd <[EMAIL PROTECTED]> writes:
Earnie> --- Akim Demaille <[EMAIL PROTECTED]> wrote: -8<-
>> As for mkdir -m, it seems to me that
>>
>> (umask 700 && mkdir /tmp/foo)
Grmph, 077.
>>
>>
> "Earnie" == Earnie Boyd <[EMAIL PROTECTED]> writes:
>> Let it be for speed issues, I'm in favor of /tmp via TMPDIR. This
Earnie> You missed the point; /tmp isn't portable, it doesn't always
Earnie> exist (E.G.: MSDOS or WINDOWS). At least with TMPDIR I can
Earnie> set it to be whatever I
| On Feb 2, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
| >>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
| Alexandre> Only CVS autoconf accepts implicitly quotes backticks in
| Alexandre> MSGs. But it complains if backtick is
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On Mar 13, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>> And again, I shall emphasize that this little comfort is a myth:
>> you *need* to update Automake if you
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> I'd really prefer to have a stable release of automake with
Alexandre> the many the new features introduced since release 1.4,
Alexandre> particularly user-side dependency tracking, before starting
Alexandre> to rely on C
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> Grant Akim write access and we'll quickly get all of
Alexandre> automake revamped :-)
:)
Alexandre> Akim, no offense intended :-)
None taken :)
Akim
> "Sascha" == Sascha Ziemann <[EMAIL PROTECTED]> writes:
Sascha> One needs -lfl and the other not.
Just don't use -lfl at all. It contains a dummy main, which you
certainly already have available somewhere else, and a dummy yywrap,
which you can write: return 1. Alternatively, use %option
> "Sascha" == Sascha Ziemann <[EMAIL PROTECTED]> writes:
Sascha> - How can I check for flex and bison instead of lex and yacc?
Sascha> I use some flex/bison specific features, which would not work
Sascha> with lex/yacc.
Here's what I do:
# I want flex, and only flex
AM_PROG_LEX
if test "$LE
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
Tom> So, I'm planning to change the rule to always choose top_srcdir
Tom> as the default location (i.e., in the final step). Comments?
If you mean for *all* the files, I'm all for it. Amongst the various
choices, the best one is most probab
I'm on something comparable in Autoconf. Don't know if it's the same,
but I'll keep you informed.
Akim
Ralf Corsepius sent me this morning a detailed PR with about the same
behavior. I'm highly tempted to consider this a bash bug, unless
someone can demonstrate the usefulness of the following feature...
/tmp/build % cat /tmp/foo.sh nostromo 19:22
#! /bin/sh
ca
| Alexandre Oliva wrote:
| > On Mar 27, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
| >
| > > I'm highly tempted to consider this a bash bug
| >
| > So am I. Which `bash' is that? I've just tested 2.04, and it *does*
| > present the bug :-(
|
| # b
> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes:
Ralf> What about this fragment from acgeneral.m4 (~line 4407):
Ralf> [[/\\$]]* | ?:[[/\\]]*) INSTALL="$ac_given_INSTALL" ;;
Ralf> There, [[/\\$]]* is used instead of [[/\\]]*.
For variables which can contain ${prefix} and such.
>>>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> CVS Autoconf sticks to Automake 1.4: that's why you find all
Akim> those problems. Use 1.4 instead, that's the easier way out.
Oops, now I remember you *should* use 1.4, otherwise,
> "Erez" == Erez Zadok <[EMAIL PROTECTED]> writes:
>> > Update: I managed to solve that problem by rerunning automake on
>> the .am > files in the autoconf CVS repository.
>>
>> You must re-run aclocal before automake.
Erez> Thanks.
Erez> I still, however, seem to have a problem with make
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> On Apr 2, 2000, Erez Zadok <[EMAIL PROTECTED]> wrote:
>> Have you tried to make dist in a a build dir that's not srcdir?
Alexandre> A long time ago, I installed a patch in autoconf to make it
Alexandre> work. I don't kn
This patch is still lacking in the current Automake.
Akim
This patch seems to work for me to solve the problem of splitting the
original AC_OUTPUT(...) into AC_CONFIG_FILES(...) and AC_OUTPUT.
It applies just as easily to automake.in .
--- /usr/local/gnu/bin/automake Mon Dec 20 00:
This simple patch just changes
- if (/A([CM])_CONFIG_HEADER\s*\((.*)\)/
+ if (/A([CM])_CONFIG_HEADERS?\s*\((.*)\)/
but there are some trailing spaces which were killed too by
whitespace.el.
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
* autom
I've already sent this patch, but it has not been applied yet. Here
is an updated version.
Akim
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
* m4/init.m4 (AC_PROVIDE_IFELSE): If it is not defined, do it.
(AM_INIT_AUTOMAKE): Update
Already sent.
Akim
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
* compile: Simplify the use of double quotes in assignments.
Index: compile
===
RCS file: /cvs/automake/au
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
foo.yy should generate foo.cc and foo.hh, not foo.h.
* automake.in (output_yacc_build_rule): Don't pretend to use a
third argument.
Transform the generated header's suff
Maybe this patch could be rejected/discussed/applied?
| Index: m4/init.m4
| ===
| RCS file: /cvs/automake/automake/m4/init.m4,v
| retrieving revision 1.17
| diff -u -r1.17 init.m4
| --- init.m4 1999/11/23 05:08:42 1.17
| +++ i
Sorry, I sent this mail by accident before I had commented it.
Automake has some support for Lex and Yacc files intended for C++,
based on .yy, .y++ or even yxx. It generates the corresponding .cc,
.c++ and .cxx, but does not apply the same transformation to headers.
There is also a couple of
Hm, in fact I did the previous patch because Automake 1.4 created
dependencies for .yy.hh, not for .yy.h, so it was wrong somewhere.
Since I use .hh when I use .cc, it seemed logical to me that it was
the .h which was wrong.
But I sent the patch for CVS Automake, and I just discovered that it
th
x27;s useful?
Akim
Index: ChangeLog
===
RCS file: /cvs/automake/automake/ChangeLog,v
retrieving revision 1.864
diff -u -r1.864 ChangeLog
--- ChangeLog 2000/04/15 09:13:49 1.864
+++ ChangeLog 2000/04/21 08:28:50
@@ -1,3 +1,10 @@
+2000-04-21 Akim Demaille <[EMAIL PROTECTED
In response to Didier in another thread, I don't think this patch was
applied.
Akim
| Akim Demaille <[EMAIL PROTECTED]> writes:
| | This patch is still lacking in the current Automake.
| |
| | Akim
|
| Thanks.
| I'll commit this instead:
|
| --- automake.in.
1 - 100 of 929 matches
Mail list logo
