Hi,
I've just been trying to submit this as a PR at sources.redhat.com, but
I can't get that system to work (get a "Submitter-Id is 'unknown'" error).
So:
Synopsis: Optional subdirectories cause make distcheck to fail
Release: cvs automake (Aug 30 2000)
Environment:
Debian GNU/Linux 2.2
au
e is bad)...
--
Richard
#! /bin/sh
# Regression test for multiple rules being generated for each target when
# conditionals are present.
# From Richard Boulton
. $srcdir/defs || exit 1
cat >> configure.in << 'END'
AC_PROG_CC
AM_CONDITIONAL(BAR, true)
END
cat >
In current automake, if a variable is defined in terms of N conditionally
defined variables, an array of possible combinations of conditional values
is generated. This array is, of course, of size 2^N, which implies that
only small numbers of conditionals can effectively be used together.
The gs
Resubmitting this patch, since there was no reply.
This problem is causing significant difficulty for the gstreamer project:
we're being asked several times a day why automake goes to in excess of
150Mb when building the makefile.ins for our project.
I also attach a patch against automake versio
On Sat, May 05, 2001 at 03:18:56PM -0600, Tom Tromey wrote:
> How do you define SUBDIRS?
By condtionally defining a set of variables, and then defining SUBDIRS in
terms of each of these conditional variables. I attach the Makefile.am in
question, for reference.
> Please send a ChangeLog entry wi
Using a recent CVS automake (checked out at Thu May 31 14:41:26 BST 2001),
and autoconf 2.50, I find that I now need to define ASFLAGS and AS in my
configure.{in,ac} in order to compile assembly sources. This seems
entirely reasonable; I just have two questions:
i) Is there any documentation of
On Thu, May 31, 2001 at 02:29:37PM -0400, Eric Siegerman wrote:
> Wouldn't one lose the ability to remake just a single module, as
> opposed to the entire project?
No: one could easily put (very small) stub makefiles in each directory,
which simply call the top-level makefile to build just the ta
On Fri, Jun 01, 2001 at 11:16:45AM +0200, Alexandre Duret-Lutz wrote:
> There is something nice about having one Makefile.am in each
> subdirectory, it's that it helps to make selfcontained and
> reusable modules.
What is being advocated is that we keep having Makefile.am's in each
separate direc
spect of such a macro being created in the near future.
I would supply a patch, but I have no idea how to define AS appropriately:
the definition I've used seems an inappropriate hack.
On Fri, Jun 01, 2001 at 01:03:26PM +0200, Ralf Corsepius wrote:
> Tom Tromey wrote:
> >
> >
hangeLog,v
retrieving revision 1.1414
diff -u -r1.1414 ChangeLog
--- ChangeLog 2001/06/04 15:53:02 1.1414
+++ ChangeLog 2001/06/06 01:13:38
@@ -1,3 +1,10 @@
+2001-06-06 Richard Boulton <[EMAIL PROTECTED]>
+
+ * (variable_conditions_reduce): Remove pure TRUE conditions unless
+
.
--
Richard
On Wed, Jun 06, 2001 at 02:33:16AM +0100, Richard Boulton wrote:
> I came across this problem a few days ago: just narrowed it down to a
> sensible test case.
>
> With CVS automake, if LDADD is set from both a conditional variable
> and an AC_SUBST() variable, th
On Wed, Jun 13, 2001 at 11:44:52AM +0300, Kalle Olavi Niemitalo wrote:
> This bug is also causing the @TRUE@ conditions reported by
> Richard Boulton in "Bug with conditionals. [PATCH]".
You're right, this does seem to be the main cause of the problem I
reported.
I tried f
On Thu, Jun 14, 2001 at 03:17:38PM -0500, Raja R Harinath wrote:
> Isn't it cleaner to use
>
> sub conditions_true_when(\@@)
> {
> my ($condsref, @whens) = @_;
>
[snip]
>
> >- if ! conditionals_true_when ((@parent_conds), ($vcond));
> >+ if ! conditionals_true_when ([@parent_
All tests behaved as expected with this
patch.
--
Richard
Index: ChangeLog
===
RCS file: /cvs/automake/automake/ChangeLog,v
retrieving revision 1.1419
diff -u -r1.1419 ChangeLog
--- ChangeLog 2001/06/12 14:37:44 1.1419
+++ ChangeLog 2001/0
On Sat, 2001-09-22 at 00:07, Ben Smith wrote:
> I didn't have this problem until I introduced the conditionals in the Makefile.am.
I can't say why this problem is happening since I've not got 1.4p4
installed, and havn't time to try it out. However, having worked on
fixing it for 1.5, I can say t
On Wed, 2001-12-05 at 13:18, Ali Akcaagac wrote:
> hello,
>
> question: now that 1.0 was officially out, i wanted to point you guys to
> an problem that i have. i am able to solve this problem within 2 seconds
> but it would be needfull to fix this anyways.
>
> i use automake1.5, autoconf2.50. g
On Thu, 2001-12-06 at 22:02, Francis Michel wrote:
> Hi all,
> I am trying to use the AM_CONDITIONAL macro in order to use that Macro in
> the makefile.am as follow in the configure.in
> AC_MSG_CHECKING(Dummy file selection)
> AC_ARG_ENABLE(dummyfile,
> [ --enable-dummyfile Use debug file],
> [c
0
+++ ChangeLog 2002/03/10 15:52:11
@@ -1,3 +1,9 @@
+2002-03-10 Richard Boulton <[EMAIL PROTECTED]>
+
+ * automake.in (check_typos): Allow variables with reserved
+ suffices (such as _LDFLAGS) and prefixes which aren't recognised
+ if the variable is defined in configure.ac.
+
2002-03-0
On Wed, 2002-04-10 at 18:26, Tom Tromey wrote:
> Also wildcards wouldn't interact well with some automake features.
> That's because we need to do certain things statically to work around
> problems and missing features in vendor makes.
>
> As an example suppose you want to use per-executable CFL
On Wed, 2002-04-10 at 16:57, Skip Montanaro wrote:
> I just installed autoconf 2.53 and as a result wound up installing the
> Release-1-6 snapshot from the automake CVS tree. Automake now complains:
>
> automake: src/Makefile.am: object `alf.lo' created both with libtool and without
The sam
On Fri, 2002-04-12 at 17:47, Philipp Thomas wrote:
> I have a package that does in configure.in
>
>GNOME_GEN_H_FILES=`cd $srcdir/src ; ls *.gen_h | xargs echo`
>AC_SUBST(GNOME_GEN_H_FILES)
>
> and then a subdir Makefile.am has
>
> gnomemmc = wrap.cc $(GNOME_GEN_H_FILES:.gen_h=.cc) gno
On Tue, 2002-04-23 at 11:04, Joerg Anders wrote:
> Unfortunately I'm not a autoconf/automake guru.
> But I think I can state: automake > 1.4 does not work.
Of course they work. There are many people using such releases.
However, as with all software, there are some bugs (both known and
unknown),
Executive summary: this is a KDE problem, not an automake problem.
The problem is with the am_edit script: it doesn't understand the
backslash-end-of-line line continuations.
Specifically, in noteedit/icons/Makefile.am, data_ICON is defined
as a set of lines joined by \-newlines. These is passe
On Thu, 2002-05-02 at 23:19, Harlan Stenn wrote:
> So what options exist for making a single top-level monolithic Makefile.am?
>
> I can't imagine keeping this file up-to-date by hand, especially on a large
> project where changes must be frequently made by multiple developers.
>
> Ideas?
I spl
On Mon, 2002-05-27 at 12:40, Thomas Vander Stichele wrote:
> Now that Red Hat 7.3 has an automake-1.5 binary and a regular automake
> binary, I provided options to autogen.sh to specify a different automake
> binary. It does this perfectly, uses it for autogenning, and also
> automatically pic
On Sun, 2002-06-02 at 09:01, Michael Still wrote:
> My Makefile.am looks something like:
>
> noinst_PROGRAMS = sample ui
> sample_SOURCES = sample.c
> ui_SOURCES = ui.c other.c sample.c
>
> I would like to be able to define a value such as WITHWX (i.e.
> -DWITHWX=1) for the ui target only. I am
On Sun, 2002-06-02 at 17:46, Glenn Maynard wrote:
> 12:40pm [EMAIL PROTECTED]/8 [~/l/lftp] automake
> aclocal.m4:6923: invalid unused variable name: `SSL_LDFLAGS'
> configure.in:199: invalid unused variable name: `LFTP_SSL_LDFLAGS'
>
> It's complaining about a couple variable names used by lftp t
On Thu, 2002-08-15 at 10:59, Zdenek Kabelac wrote:
> I've proposed several times few things which would certainly
> drasticaly improve the speed - though they are for different
> parts of auto* tools project - there were some reactions - but
> so far non of them were realized and there is not vis
On Wed, 2002-08-21 at 16:28, Bruce Korb wrote:
> > >> Why don't you simply use DIST_SUBDIRS?
>
> > Bruce> 2. Even now that I've read it, using it would mean taking over
> > Bruce> an automatable chore from automake.
> >
> > I don't get this. Which chore should be automated?
>
> Maintaining
On Wed, 2002-08-21 at 19:40, Bruce Korb wrote:
> Now it is clear to me. I did not understand the extra magic.
> Thank you. I was relying on this:
>
> >It is possible to override the `SUBDIRS' variable if,
> > like in the case of GNU `Inetutils', you want to only build
> > a subset of the en
30 matches
Mail list logo
