Bug + patch
Somebody checked in a bad quote recently. It breaks at least the
stamph/header targets. Patch attached.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
82. Hold a hard drive to your ear -- listen to the C.
? automake-1.4c.tar.gz
? automake-1.4c.acconfig_h.diff
Index: ChangeLog
===
RCS file: /cvs/automake/ChangeLog,v
retrieving revision 1.992
diff -u -r1.992 ChangeLog
--- ChangeLog 2001/02/05 09:11:10 1.992
+++ ChangeLog 2001/02/06 04:19:20
@@ -1,3 +1,7 @@
+2001-02-05 Derek Price <[EMAIL PROTECTED]>
+
+ * automake.in (handle_configure): fix syntax error
+
2001-02-05 Akim Demaille <[EMAIL PROTECTED]>
* automake.in (handle_texinfo): No longer hard code the clean
Index: automake.in
===
RCS file: /cvs/automake/automake.in,v
retrieving revision 1.859
diff -u -r1.859 automake.in
--- automake.in 2001/02/05 09:11:10 1.859
+++ automake.in 2001/02/06 04:19:24
@@ -3387,7 +3387,7 @@
{
# Strange quoting because this gets fed through
# Perl.
- push (@files, '\$(top_srcdir)/acconfig.h');
+ push (@files, '$(top_srcdir)/acconfig.h');
}
}
Re: AM_INCLUDE is a bad name.
Hello, Tom! > Pavel> How about renaming AM_INCLUDE to AMINCLUDE everywhere? The > Pavel> patch is attached. It fixes all tests. My approach was too formal. AM_INCLUDE is a variable, but the names of variables shouldn't contain any capital letters. My fault. > What if instead we decide on a permanent naming scheme for automake > internal variables? Then we can start moving towards that over time, > starting here. > > What if instead we use `_AM_'? Or `_am_'? I believe that names beginning with am_ are private. I.e. AM_INCLUDE should become am_include. I believe that user code should not do anything with the names beginning with ac_ and am_. Public names don't have any specific prefix: cross_compiling, SHELL, program_suffix, x_libraries, M4, MISSING etc. It's too late to introduce one. Regards, Pavel Roskin
Re: 26-makesort.patch
> "Hari" == Raja R Harinath <[EMAIL PROTECTED]> writes: Hari> That seems counter to current 'automake' behaviour. IIRC, if Hari> automake sees a "special" target in Makefile.am, it won't Hari> generate code for that target. E.g., if the Makefile.am has a Hari> 'check:' target, the builtin test harness will not be generated. That's right. And this is a feature. I'm still skeptical about merging the two readers. One thing that would be useful would be a generic way to add pre-/post- hooks to various targets. I've seen several requests for a pre-uninstall hook. Tom
Re: AM_INCLUDE is a bad name.
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes: Pavel> I see that you are not using the latest and greatest Autoconf. Nope. Pavel> Names beginning with AM_ are reserved for Pavel> macros. Autoconf-2.49c will not allow such names in configure. Hmm. Pavel> That's why many tests are failing again - AM_INCLUDE is not a Pavel> good name for a variable. That plus another bug I fixed last night. Running depcomp tests in a subdir caused regressions, and against my own advice I didn't run `make check'. Sigh. Pavel> How about renaming AM_INCLUDE to AMINCLUDE everywhere? The Pavel> patch is attached. It fixes all tests. What if instead we decide on a permanent naming scheme for automake internal variables? Then we can start moving towards that over time, starting here. What if instead we use `_AM_'? Or `_am_'? I'd like to also work out a naming scheme for internally generated targets. That way eventually it will be clear what people can rely on and what they cannot. Suggestions here are welcome. Tom
Re: 24-clean-do-clean.patch
Akim> I can't proceed without a full approval of this patch, it is Akim> required for the next ones. I thought I gave this, with a couple minor changes requested. Tom
Re: 26-makesort.patch
Akim Demaille <[EMAIL PROTECTED]> writes: [snip] > For instance, I find it quite annoying to have to know that Automake > knows the -local targets: the code of 25 makes it possible for users > to have just there own `clean:' target which will be appended to the > existing code. That seems counter to current 'automake' behaviour. IIRC, if automake sees a "special" target in Makefile.am, it won't generate code for that target. E.g., if the Makefile.am has a 'check:' target, the builtin test harness will not be generated. - Hari -- Raja R Harinath -- [EMAIL PROTECTED] "When all else fails, read the instructions." -- Cahn's Axiom "Our policy is, when in doubt, do the right thing." -- Roy L Ash
Re: AM_INCLUDE is a bad name.
> Tom, you should also know you can have a special exception, and tell > autoconf AM_INCLUDE is OK. But I agree with Pavel it looks way too > much like a macro name, in itself it is confusing. As far as I know, it cannot be done without breaking compatibility with Autoconf 2.13. Too bad Autoconf doesn't provide (offically at least) any means for writing macros conditionally for particular versions of Autoconf. This feature may be useful for Automake and other tools working together with Autoconf, as well as for any packages installing m4 files (gettext, GTK+, gnome-libs). I mean something like AC_VERSION_CASE( [<=2.13], [test "$FOO" = yes && tmp=foo; AC_CONFIG_SUBDIRS([$tmp])], [default], [test "$FOO" = yes && AC_CONFIG_SUBDIRS([foo])]) We may do our best, but we cannot guarantee 100% backward compatibility. Regards, Pavel Roskin
Re: [patch 1/2] support AC_SUBST'able automake rules
On Mon, Feb 05, 2001 at 05:40:58PM +0100, Akim Demaille wrote: : "Lars J. Aas" <[EMAIL PROTECTED]> writes: : : > First a simple organize/cleanup patch. : : Err, I must confess I'd like better &canonicalize or so... Agreed. The point is to gather the character range in one place, and with a sub you can use the more optimized tr command... Lars J -- Innovation is one percent inspiration and ninetynine percent perspiration, and in my case; twice that... -- Norville Barnes, `The Hudsucker Proxy'
Re: AM_INCLUDE is a bad name.
Pavel Roskin <[EMAIL PROTECTED]> writes: > Hello, Tom! > > I see that you are not using the latest and greatest Autoconf. > Names beginning with AM_ are reserved for macros. Autoconf-2.49c will not > allow such names in configure. > > That's why many tests are failing again - AM_INCLUDE is not a good name > for a variable. > > How about renaming AM_INCLUDE to AMINCLUDE everywhere? The patch is > attached. It fixes all tests. Tom, you should also know you can have a special exception, and tell autoconf AM_INCLUDE is OK. But I agree with Pavel it looks way too much like a macro name, in itself it is confusing.
Re: [patch 1/2] support AC_SUBST'able automake rules
"Lars J. Aas" <[EMAIL PROTECTED]> writes: > First a simple organize/cleanup patch. Err, I must confess I'd like better &canonicalize or so...
Need help to compile
Hi, How can I compile a program which is not C or C++, Fortran... I have got this rule for a Makefile, but I do not know how to put this in a Auto system. .SUFFIXES: .cmi .cmo .cmx .c %.cmi: %.mli $(COMPILE) $< %.cmo: %.ml $(OCAMLC) $(BYTECOMPFLAGS) $< %.cmx: %.ml $(OCAMLOPT) $(OPTCOMPFLAGS) $< %.ml: %.p4 $(P4) $< > $@ I have written a macro to test where $(OCAMLC) is. -- Florent DEVIN, 33 (0)3 20 43 47 30, Fax (33) (0)3 20 43 65 66 (Fax LIFL) LIFL, Laboratoire d'Informatique Fondamentale de LILLE USTL, Bureau 326, Batiment M3, 59655 Villeneuve d'Ascq Cedex
AM_INCLUDE is a bad name.
Hello, Tom!
I see that you are not using the latest and greatest Autoconf.
Names beginning with AM_ are reserved for macros. Autoconf-2.49c will not
allow such names in configure.
That's why many tests are failing again - AM_INCLUDE is not a good name
for a variable.
How about renaming AM_INCLUDE to AMINCLUDE everywhere? The patch is
attached. It fixes all tests.
Regards,
Pavel Roskin
___
--- ChangeLog
+++ ChangeLog
@@ -1,3 +1,10 @@
+2001-02-05 Pavel Roskin <[EMAIL PROTECTED]>
+
+ * automake.in (handle_dependencies): Rename AM_INCLUDE to
+ AMINCLUDE.
+ * m4/make.m4 (AM_MAKE_INCLUDE): Likewise.
+ * tests/exsource.test: Likewise.
+
2001-02-05 Akim Demaille <[EMAIL PROTECTED]>
* automake.in (handle_texinfo): No longer hard code the clean
--- automake.in
+++ automake.in
@@ -3037,7 +3037,7 @@
$output_rules .= "\n";
foreach $iter (@deplist)
{
- $output_rules .= "\@AMDEP\@\@AM_INCLUDE\@ " . $iter . "\n";
+ $output_rules .= "\@AMDEP\@\@AMINCLUDE\@ " . $iter . "\n";
}
$output_rules .= &file_contents ('depend');
--- m4/make.m4
+++ m4/make.m4
@@ -10,15 +10,15 @@
END
# If we don't find an include directive, just comment out the code.
AC_MSG_CHECKING([for style of include used by $am_make])
-AM_INCLUDE='#'
+AMINCLUDE='#'
for am_inc in include .include; do
echo "$am_inc confinc" > confmf
if test "`$am_make -f confmf 2> /dev/null`" = "done"; then
- AM_INCLUDE=$am_inc
+ AMINCLUDE=$am_inc
break
fi
done
-AC_SUBST(AM_INCLUDE)
-AC_MSG_RESULT($AM_INCLUDE)
+AC_SUBST(AMINCLUDE)
+AC_MSG_RESULT($AMINCLUDE)
rm -f confinc confmf
])
--- tests/exsource.test
+++ tests/exsource.test
@@ -29,4 +29,4 @@
$AUTOMAKE || exit 1
-grep '@AM_INCLUDE@ .*/xtra\.P' Makefile.in
+grep '@AMINCLUDE@ .*/xtra\.P' Makefile.in
___
Re: config.status and CONFIG_LINKS
Tom Tromey <[EMAIL PROTECTED]> writes: > At some point I'd like to fix the "adding a directory" problem. Right > now if you add a new directory (edit AC_OUTPUT and SUBDIRS), automake > won't notice correctly and a simple "make" won't rebuild the way you'd > like. > > Likewise automake isn't very savvy about re-creating links after > configure.in is changed. What I would like to do for next Autoconves is to have a set of traces requests, and have autoconf always save them when it creates configure. This will let autoheader and automake look at the traces without having to re-run autoconf, which is really costly for duplicate work.
Re: [revised patch 1/1] support AC_SUBST'able automake rules
"Lars J. Aas" <[EMAIL PROTECTED]> writes: > Anyways, are the people that count looking into this patch? I will, when I have time :( Sorry for the delays...
Re: Improved Fortran support
Hi again!
On 4 Feb, Tom Tromey wrote:
>> ">" == 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, even if the
>>> Makefile.am contains handwritten rules for their generation.
>
> Hmm... that sounds wrong. Did you try adding the suffixes to the
> SUFFIXES macro?
Of course. The problem is that with
bin_PROGRAMS = prog
prog_SOURCES = some.f90 foo.f90 bar.F90
in Makefile.am, bar.o does not appear in the automatically generated
dependency list for prog. And is therefore not compiled. One could add
this dependency manually to Makefile.am, of course; but what is automake
good for, then?
>>> - Files ending with .f90 are also handled this way; i.e. Fortran 77 (!)
>>>targets are created for them - not really fine... :-(
>
> I thought we were just following what the autoconf Fortran guys
> suggested.
I think I understand the rationale behind it: Even without Fortran 90
support in the autotools, you can force configure using the Fortran 90
compiler by something like
F77=f90 ./configure
But really, IMHO this is just a simple hack to work around a missing
feature. Plus, .F90 should be added to the ppf77 part in order to be
consistent (my view).
>>> F90, F90FLAGS, F90LINK and F95, F95FLAGS, F95LINK,
>>> respectively. These somehow have to be generated by configure.in.
>
> This part is a bit of a problem. Ideally we would have a handy
> autoconf macro that users could just drop in. Or at the very least we
Based on Martin's earlier scripts, I would try to provide some over the
next few days that work with the curent cvs version of autoconf.
> would warn if these are not defined (maybe we already do, with your
> patch? I don't know).
I've added a .f95 to one of my projects without having any apprpriate
autoconf macro, and got this from the patched version:
automake: Makefile.am: Fortran 95 source seen but `F95' not defined in
`configure.in'
>>> +sub lang_f90_finish
>>> +{
>
> Since the body of this, lang_f95_finish, and lang_f7_finish are nearly
> identical, how about making a new subroutine which all three call with
> the appropriate arguments? That would seem to make maintenance
> easier.
Hmm. As Martin pointed out a long while ago, F90 has a complex structure
when it comes to dependencies due to the existence of module files. In a
very basic support mode, the targets to be generated are indeed very
similar to the ones required by f77. But over time, if someone finds
ways to represent module appropriately in Makefiles, these routines
might differ substantially. I don't know what's the best way to start
this - what's your advice?
> One question I have about the Fortran support: is it really the case
> that there are projects with a mix of F77, F90, and F95 code? What if
Well, yes. There are a lot of old, but very well tested (usually
numerical) libraries out there... look at http://www.netlib.org. One
thing I often do (this is where I need autoconf/automake, for, actually)
is to provide a comfortable f90 interface to some of these, create a
library and use it in other f90 projects.
> we just assume the "F77" compiler is a poorly-named macro holding a
> generic "Fortran" compiler, and then let it handle the new prefixes as
> well? Would that work? I really don't know.
Theoretically, it should, as f77 (the standard) is a subset of f90. But
in reality, vendors for f77 compilers have added many extensions to the
standard - often uniquely over the industry. What if the f90 compiler
does not support some of these? One example I can immediately think of
(on Suns) is the BYTE data type, which is supported by Sun's f77 (and
even g77), but not by it's f90 counterpart.
> I'll need paperwork from you before I can check in this patch (or any
> variant of it). I've been putting off figuring out how to do that,
> but I'll see if I can motivate this week.
Please let me know what I have to do.
> Tom
Regards,
Chris.
--
Christian Marquardt
GFZ Potsdam, Div. 1 | Tel.: (+49) 331-288-1168
Am Telegrafenberg | Fax: (+49) 331-288-1169
D-14473 Potsdam | Email: [EMAIL PROTECTED]
Re: 31-ac-libsources.patch & Re: amtraces
"Derek R. Price" <[EMAIL PROTECTED]> writes: > AC_REPLACE_FUNCS is still trying to call AC_LIBOBJ_DECL. :( Pfff, there was no test for AC_REPLACE_FUNCS at all! Thanks! Index: ChangeLog from Akim Demaille <[EMAIL PROTECTED]> acfunctions.m4 was still using the old AC_LIBOBJ_DECL. Reported by Derek R. Price. * tests/semantics.at (AC_REPLACE_FUNCS): New test. * acfunctions.m4 (AC_REPLACE_FUNCS, _AC_LIBOBJ_ALLOCA): Use AC_LIBSOURCES. Index: THANKS === RCS file: /cvs/autoconf/THANKS,v retrieving revision 1.53 diff -u -u -r1.53 THANKS --- THANKS 2001/01/30 19:29:39 1.53 +++ THANKS 2001/02/05 10:15:58 @@ -32,6 +32,7 @@ Dave Adams [EMAIL PROTECTED] Dave Love [EMAIL PROTECTED] David Morgan [EMAIL PROTECTED] +Derek R. Price [EMAIL PROTECTED] Didier Desseaux[EMAIL PROTECTED] Didier Verna [EMAIL PROTECTED] Dietmar P. Schindler [EMAIL PROTECTED] Index: acfunctions.m4 === RCS file: /cvs/autoconf/acfunctions.m4,v retrieving revision 1.29 diff -u -u -r1.29 acfunctions.m4 --- acfunctions.m4 2001/02/03 13:22:26 1.29 +++ acfunctions.m4 2001/02/05 10:16:00 @@ -92,7 +92,7 @@ # AC_REPLACE_FUNCS(FUNCTION...) # - AC_DEFUN([AC_REPLACE_FUNCS], -[AC_FOREACH([AC_Func], [$1], [AC_LIBOBJ_DECL(AC_Func)])dnl +[AC_FOREACH([AC_Func], [$1], [AC_LIBSOURCE(AC_Func.c)])dnl AC_CHECK_FUNCS([$1], , [_AC_LIBOBJ($ac_func)]) ]) @@ -129,13 +129,13 @@ # - # Set up the LIBOBJ replacement of `alloca'. Well, not exactly # AC_LIBOBJ since we actually set the output variable `ALLOCA'. -# Nevertheless, for Automake, AC_LIBOBJ_DECL it. +# Nevertheless, for Automake, AC_LIBSOURCES it. m4_define([_AC_LIBOBJ_ALLOCA], [# The SVR3 libPW and SVR4 libucb both contain incompatible functions # that cause trouble. Some versions do not even contain alloca or # contain a buggy version. If you still want to use their alloca, # use ar to extract alloca.o from them instead of compiling alloca.c. -AC_LIBOBJ_DECL(alloca) +AC_LIBSOURCES(alloca.c) AC_SUBST(ALLOCA, alloca.$ac_objext)dnl AC_DEFINE(C_ALLOCA, 1, [Define if using `alloca.c'.]) Index: tests/aclocal.m4 === RCS file: /cvs/autoconf/tests/aclocal.m4,v retrieving revision 1.13 diff -u -u -r1.13 aclocal.m4 --- tests/aclocal.m4 2001/01/24 13:19:11 1.13 +++ tests/aclocal.m4 2001/02/05 10:16:00 @@ -53,5 +53,5 @@ grep '^m4_defn([m4_re_word])=' >state-env.$1 test $? = 0 || rm -f state-env.$1 -ls -1 | egrep -v '^(state.*|config\.)' | sort >state-ls.$1 +ls -1 | egrep -v '^(at-|state-|config\.)' | sort >state-ls.$1 ])# AC_STATE_SAVE Index: tests/semantics.at === RCS file: /cvs/autoconf/tests/semantics.at,v retrieving revision 1.19 diff -u -u -r1.19 semantics.at --- tests/semantics.at 2001/01/22 09:03:38 1.19 +++ tests/semantics.at 2001/02/05 10:16:00 @@ -47,6 +47,37 @@ ])]) +# AC_REPLACE_FUNCS +# +# Check that it performs the correct actions: autoconf_ftnirp.c must +# be compiled, and must define HAVE_PRINTF, but not HAVE_AUTOCONF_FTNIRP +# FIXME: Maybe check the traces? +AT_SETUP([AC_REPLACE_FUNCS]) + +AT_DATA([config.in], +[@LIBOBJS@ +]) + +AT_CONFIGURE_AC( +[AC_CONFIG_FILES(config.libobjs:config.in) +AC_REPLACE_FUNCS(printf autoconf_ftnirp)]) + +AT_CHECK_AUTOCONF([-W obsolete]) +AT_CHECK_AUTOHEADER +AT_CHECK_CONFIGURE +AT_CHECK_ENV +AT_CHECK_DEFINES( +[/* #undef HAVE_AUTOCONF_FTNIRP */ +#define HAVE_PRINTF 1 +]) + +AT_CHECK([sed 's/ */ /g;s/^ //;s/ $//' config.libobjs], [], + [autoconf_ftnirp.o +]) + +AT_CLEANUP([config.libobjs]) + + # AC_CHECK_HEADERS # # Check that it performs the correct actions:
Re: 26-makesort.patch
Tom Tromey <[EMAIL PROTECTED]> writes: > > "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. Err, actually I didn't mean to name this `.patch', but if you want to include it in Automake, then fine with me. > This needs a ChangeLog entry. And makesort.pl needs to be added to > Makefile.am so it ends up in the distribution. I just meant to send it if people want to improve it or use it to check their own changes :) > I notice this duplicates code in automake.in. Someday we have to > split it up into pieces. makesort.pl was an excellent test bed for Makefile parsing, and it's actually the converse: Automake has inherited code from makesort.pl (which name is atrocious btw). My ultimate goal is to have a single routine to load a .am file. I can't think of any valid reason to differentiate users' Makefile.am and Automake's *.am files. For instance, I find it quite annoying to have to know that Automake knows the -local targets: the code of 25 makes it possible for users to have just there own `clean:' target which will be appended to the existing code.
Re: 24-clean-do-clean.patch
Akim Demaille <[EMAIL PROTECTED]> writes: > 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 this patch is fine. > > > > The other part I don't know. I'd like to eventually fix the FIXME > > comment by having maintainer-clean look like: > > > > maintainer-clean: > > @echo ... > > $(MAKE) whatever > > > > The echoes are a lame (imho) requirement on RMS's part. For one thing > > we're left with the question of whether we should repeat them in every > > subdir. > > > > Anyway I think this patch makes it harder to fix this problem. > > Agreed, and indeed I moved this because it was making my life much > harder. I had to first distribute, factor etc. so that I finally > could reach patch 25 (or 26 I don't recall: the monster). > > But the monster makes it possible to move the echo to maintainer-clean > extremely easily. Well, I think :) I can't proceed without a full approval of this patch, it is required for the next ones.
Re: 22-maintainer-check.patch
Akim Demaille <[EMAIL PROTECTED]> writes: > 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. Ordinarily lists like > > these end up sorted by automake. Sorting is critical for Makefile.in > > stability. Can you find out what caused this? > > > Arg :( Will do, but I can't tell when, got a busy week forthcoming, > and then I go on winter vacations... I don't observe this, I still have the old order, ChangeLog being first.
