Akim Demaille wrote:
"Derek R. Price" [EMAIL PROTECTED] writes:
All these comments are related to the same idea: Automake must know as
less as possible about macros. It means that if needed, we have to
~/src/ace % echo "AC_INIT AC_CANONICAL_SYSTEM" | ace -t AC_CANONICAL_SYSTEM -t
Akim Demaille wrote:
FYI, I applied this to Autoconf:
2001-02-03 Akim Demaille [EMAIL PROTECTED]
* acfunctions.m4 (AC_FUNC_ERROR_AT_LINE, AC_FUNC_ONSTACK): Use
AC_LIBSOURCES.
2001-02-03 Akim Demaille [EMAIL PROTECTED]
* acgeneral.m4 (AC_LIBOBJ_DECL): Remove.
This message introduces makesort.pl which is quite handy when you
change to much the layout of Makefiles, just like my previous patch
does: it becomes nearly impossible to just diff.
--
#! /usr/bin/perl -w
# -*- perl -*-
# @configure_input@
eval
Index: ChangeLog
from Akim Demaille [EMAIL PROTECTED]
* automake.in (do_one_clean_target): Don't hard code knowledge
about libtool, and maintainer-clean.
* clean.am, libtool.am: Handle these.
Index: automake.in
--- automake.in Sun, 04 Feb 2001 00:49:46
I'm sorry about the size of the patch, I couldn't do any smaller, I
attacked something which was really one big piece.
I have left below the diff of the Makefile.ins, but frankly it's way
too unreadble. I wrote a helper tool to diff Makefiles, and I will
make a second message to give this tool,
Hello,
to begin with, I'm an awful beginner when it comes to automake's
internals... I beg your pardon if the attached patch should break
something or is too much off the line.
I have used autoconf/automake a lot to configure programs and libraries
written in Fortran 77 and Fortran 90,
This was responsible for the difference presented in Automake's
tests/Makefile.in. Now makesort says:
~/src/am % ./makesort.pl -d /tmp/am/tests/Makefile.in tests/Makefile.in
259c259
distclean-am: distclean-generic clean-am distclean-local
---
distclean-am: clean-am distclean-generic
Index: ChangeLog
from Akim Demaille [EMAIL PROTECTED]
* m4/regex.m4: Use AC_LIBSOURCES.
* automake.in (scan_autoconf_traces): Trace AC_LIBSOURCE, not
_AC_LIBOBJ_DECL.
Index: m4/regex.m4
--- m4/regex.m4 Sat, 13 Jan 2001 18:11:09 +0100 akim
If you compare the .PHONY, we won one target: maintainer-clean-aminfo.
It seems that it's right, and was missing before.
There is something which sounds wrong in this patch: I have not
introduced the empty target clean-aminfo and distclean-aminfo, but
it's knowing what the forthcoming 24 does.
Index: ChangeLog
from Akim Demaille [EMAIL PROTECTED]
* automake.in (do_one_clean_target): Don't hard code knowledge
about libtool, and maintainer-clean.
* clean.am, libtool.am: Handle these.
Index: automake.in
--- automake.in Sun, 04 Feb 2001 00:49:46
I'm sorry about the size of the patch, I couldn't do any smaller, I
attacked something which was really one big piece.
I have left below the diff of the Makefile.ins, but frankly it's way
too unreadble. I wrote a helper tool to diff Makefiles, and I will
make a second message to give this tool,
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim * m4/regex.m4: Use AC_LIBSOURCES.
Akim * automake.in (scan_autoconf_traces): Trace AC_LIBSOURCE, not
Akim _AC_LIBOBJ_DECL.
Ok.
My reading is that the change to regex.m4 doesn't require the new
autoconf but will use it if present.
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim * Makefile.am (perl4-check): Remove, we now require Perl 5.
Akim (maintainer-check): Don't be silent when you find a problem, and
Akim actually, even specify the locations.
Akim Also check that @_ is assigned to arrays.
Ok.
Akim
Tom Tromey [EMAIL PROTECTED] writes:
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim * m4/regex.m4: Use AC_LIBSOURCES.
Akim * automake.in (scan_autoconf_traces): Trace AC_LIBSOURCE, not
Akim _AC_LIBOBJ_DECL.
Ok.
My reading is that the change to
Tom Tromey [EMAIL PROTECTED] writes:
Akim --- tests/Makefile.in Wed, 31 Jan 2001 22:34:58 +0100 akim (am/h/14_Makefile.i
1.3 644)
Akim -DIST_COMMON = ChangeLog Makefile.am Makefile.in
Akim +DIST_COMMON = Makefile.in ChangeLog Makefile.am
This change seems to indicate a regression.
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim * automake.in (do_one_clean_target): Don't hard code knowledge
Akim about libtool, and maintainer-clean.
Akim * clean.am, libtool.am: Handle these.
The libtool part of this patch is fine.
The other part I don't know. I'd like to
Pavel Roskin [EMAIL PROTECTED] writes:
Hello, Akim!
Another problem. Test pr87.test fails. It fails in a makefile that
contains the following fragment:
distdir = $(top_builddir)/$(PACKAGE)-$(VERSION)/$(subdir)
@for file in $(DISTFILES); do \
distdir: $(DISTFILES)
Tom Tromey [EMAIL PROTECTED] writes:
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim * automake.in (do_one_clean_target): Don't hard code knowledge
Akim about libtool, and maintainer-clean.
Akim * clean.am, libtool.am: Handle these.
The libtool part of
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim so naturally the question is: do we really want to keep this
Akim zillions of pseudo targets? The current automake, indeed, does
Akim this instead:
Akim --
Akim clean-am: clean-this-am
Akim clean-this-am:
Akim do this
Akim
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim * automake.in (handle_texinfo): No longer hard code the clean
Akim targets.
Akim (texinfos.am): Include them.
Ok.
Tom
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim This message introduces makesort.pl which is quite handy when you
Akim change to much the layout of Makefiles, just like my previous patch
Akim does: it becomes nearly impossible to just diff.
Ok.
This needs a ChangeLog entry. And
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim * automake.in (handle_clean): `-local' targets are bound to `-am'
Akim targets, not top targets.
Thanks, ok.
Tom
"" == marq [EMAIL PROTECTED] writes:
The last point is annoying, since it prohibits the use of any .F90
or even .f95 files in any project that is maintained with automake:
it simply doesn't generate the proper dependencies for a library or
program - a .F90, .f95 or .F95 is never compiled,
"Kevin" == Kevin Ryde [EMAIL PROTECTED] writes:
Kevin * automake.in (handle_configure): Call config.status with empty
Kevin CONFIG_LINKS and CONFIG_COMMANDS when regenerating a file.
Thanks, I'm checking this in.
Kevin I guess the same effect would be obtained from something
Hello!
The first line of the "distdir" rule was not removed from
handle_dist_worker() but appeared in distdir.am. This resulted in failures
in pr87.test and texinfo8.test
Also the preceeding comment was copied to distdir.am but wasn't deleted in
automake.in.
The following patch has been
"Pavel" == Pavel Roskin [EMAIL PROTECTED] writes:
Pavel The following patch has been applied:
Pavel +* automake.in (handle_dist_worker): Remove a line that is now
Pavel +in distdir.am.
Thanks.
Tom
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.
This new code does rely on `MAKE' being set at configure time to the
make that the user plans
27 matches
Mail list logo
