I just released Automake 1.4d, the latest prerelease leading up to
1.5. Find it here:
ftp://sources.redhat.com/pub/automake/automake-1.4d.tar.gz
This release is mostly bug fixes. There are some minor known bugs and
some uncommitted patches required for 1.5 that are pending paperwork.
Never
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> ifdef([m4_pattern_allow],[m4_pattern_allow([AM_CFLAGS])])
Thanks.
Tom
On Feb 13, 2001, Tom Tromey <[EMAIL PROTECTED]> wrote:
> I don't want to remove anything from autoconf's blacklist. Doing that
> means we have to update autoconf whenever we change automake.
Nope. CVS Autoconf has a macro to remove strings from the blacklist.
ifdef([m4_pattern_allow],[m4_patt
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
>> My understanding is that autoconf prevents us from putting these
>> names (AM_*) into configure.in.
Alexandre> We can remove specific items from autoconf's blacklist.
Alexandre> Anyway, the variables you mentioned are Makefile v
On Feb 13, 2001, Steve Robbins <[EMAIL PROTECTED]> wrote:
> My recollection of that discussion was just the opposite: the user
> gets to set CFLAGS, LDFLAGS, and the like, while the software author
> gets to set AM_-versions of them.
I stand corrected. I have always got these reversed :-(
I su
On Tue, Feb 13, 2001 at 01:14:31AM -0200, Alexandre Oliva wrote:
> On Feb 12, 2001, Steve Robbins <[EMAIL PROTECTED]> wrote:
>
> > And I thought that it was a simple bug: the aclocal regexp was not
> > taking into account the possibility of assigning to a variable name
> > starting with "AM_".
>
On Feb 12, 2001, Steve Robbins <[EMAIL PROTECTED]> wrote:
> And I thought that it was a simple bug: the aclocal regexp was not
> taking into account the possibility of assigning to a variable name
> starting with "AM_".
You shouldn't assign to these variables. These are for *users* to
override,
On Feb 12, 2001, Tom Tromey <[EMAIL PROTECTED]> wrote:
> My understanding is that autoconf prevents us from putting these names
> (AM_*) into configure.in.
We can remove specific items from autoconf's blacklist. Anyway, the
variables you mentioned are Makefile variables, not generally listed
in
> "Lars" == Lars Hecking <[EMAIL PROTECTED]> writes:
>> Could somebody with access to the BSD make please try the current cvs
>> automake and report back?
Lars> What exactly do you want us to try apart from make check?
I believe that should suffice.
Lars> - pr19.test: fails somewhere in
> "Mike" == Mike Whitson <[EMAIL PROTECTED]> writes:
Mike> So, either I'm missing something here, or the depend2.am
Mike> distributed with automake 1.4 depends on having a GNU C
Mike> preprocessor to generate dependency information:
It does.
The automatic dependency tracking in 1.4 relies o
So, either I'm missing something here, or the depend2.am distributed
with automake 1.4 depends on having a GNU C preprocessor to generate
dependency information:
> ## There are various ways to get dependency output from gcc. Here's
> ## why we pick this rather obscure method:
> ## - Don't want t
Tom Tromey wrote:
> > "Tim" == Tim Van Holder <[EMAIL PROTECTED]> writes:
>
> Tim> 2001-02-10 Tim Van Holder <[EMAIL PROTECTED]>
>
> Tim>* remake-hdr.am (@STAMP@): Use .T as suffix for the
> Tim>temporary file.
>
> I don't think this is sufficient. I think you also have to change
>
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
>> In the recent namespace conversation we didn't mention macros like
>> `AM_CFLAGS'. This is an automake-specific macro which the user is
>> allowed to set.
>> How should we rename these?
Alexandre> Why should we rename these?
> "Tim" == Tim Van Holder <[EMAIL PROTECTED]> writes:
Tim> 2001-02-10 Tim Van Holder <[EMAIL PROTECTED]>
Tim>* remake-hdr.am (@STAMP@): Use .T as suffix for the
Tim>temporary file.
I don't think this is sufficient. I think you also have to change
AM_CONFIG_HEADER as well. See m4
> "Tim" == Tim Van Holder <[EMAIL PROTECTED]> writes:
Tim> a) how likely is it that tcount becomes 10 or more?
Very unlikely.
Tim> b) what impact does using a different name (e.g. st-h-$stamp.in)
Tim> have?
Probably none. Unless of course somebody is relying on the names and
we don't k
> "John" == John Poltorak <[EMAIL PROTECTED]> writes:
John> Not being an expert on AUTOMAKE, I was wondering how I could get
John> SED repackaged using the newer AUTOMAKE...
Probably. Talk to the sed maintainer.
John> I would run it myself, but I'm not sure how to go about it.
It might be
Tim Van Holder wrote:
> >> >* remake-hdr.am (@STAMP@): Use .T as suffix for the
> >> >temporary file.
> >>
> >> You should probably patch autoconf's autoreconf too.
> >
> > > What part would need patching?
> >
> > The one that choose stamp file names like those created by automake.
>
> Ri
I have just discovered that I can build the latest GNU GREP v2.4.2 on
OS/2 without the need to amend any makefiles - although I do use an OS/2
specific version of AUTOCONF. When trying to build something like SED,
the final binary is not created as an EXE file. The differences between
the two ap
Tom Tromey writes:
> Could somebody with access to the BSD make please try the current cvs
> automake and report back?
>
> I've tried to implement support for `.include'. I think it works, but
> of course I'm not copmletely sure.
What exactly do you want us to try apart from make check?
I t
Hi:
I write a simple program and using
autoconf,automake,but
have following automake
problem.
my Makefile.am is
bin_PROGRAMS = test
test_SOURCES = main.c
help.c help.h
but encounter a error->
Makefile.am:2 invalid unused
variable name:test_SOURCES
20 matches
Mail list logo
