1.8 and mkdir_p
This change: - Makefiles will prefer `mkdir -p' over mkinstalldirs if it is available. This selection is achieved through the Makefile variable $(mkdir_p) that is set by AM_INIT_AUTOMAKE to either `mkdir -m 0755 -p --', `$(mkinstalldirs) -m 0755', or `$(install_sh) -m 0755 -d'. sucks flaming red bugs. How can one change the '-m 0755'? I haven't found anything about this in the docs. I have a case where we want SGID and group-write. In the "old days" this was easy - the previous case simply did whatever it did and we got SGID by default (because the parent directory was SGID) and our umask setting got us group-write. H
Re: automake -vs- huge projects
> "Paul" == Paul D Smith <[EMAIL PROTECTED]> writes: Paul> If you're willing to require GNU make then I'm quite confidant Paul> you could write automake as nothing more than a suite of GNU Paul> make macros and functions. Yeah. One idea for the post-auto* world is "let's beef up GNU make and use it as the basis for the next-generation system". This approach has the benefits that most build scripts are already written for make and that GNU make already does a lot of what is needed. The competing idea (which seems to have more mindshare -- not necessarily making it more viable) is to write something brand new, typically in your-favorite-scripting-language, thus avoiding the less pleasant aspects of make (syntax, primarily, but also the flat namespace). From time to time I work on a tool following this approach, but there are several of these out there. We did consider just writing our own Makefile.in for libgcj using GNU make features. It seemed easier to try to fix the size problem though. Tom
Re: Principles of a developing from a dist or install?
> "John" == jling <[EMAIL PROTECTED]> writes: John> Is there any sense in me having the user install the package (i.e. do John> a 'make install') and then have them develop off of the code in the John> install directory? ... assuming I have the source code and headers John> copied over during the install process. I can't say whether or not it makes sense. It isn't the standard thing, though, that's for sure. The typical approach is that "make install" simply installs the output of the build process, the idea being that the user can save some space by then deleting the source and build trees, if he so desires. Users who wish to hack on the package usually use the unpacked tree, both because it is already built (and therefore a simple change might involve less recompilation) and because it means these users and the maintainers will have a similar build structure and directory layout (so patches will apply more easily). John> Nevertheless what is the best way or ideal way to proceed? The general idea is to have one single structure used by everybody. This means less testing, less trouble applying patches, etc. People can generally navigate any sensible source layout, no matter how deep; I wouldn't normally consider that a big hurdle. Tom
Re: automake -vs- huge projects
> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes: >> $(CC) -c -o $@ `$(CYGPATH_W) $<` Bob> An simple (but ugly) approach would be to define $(CYGPATH_W) to Bob> 'echo' when not compiling under Cygwin. We already have much worse hacks. But ideally we'd be reducing the amount of weird code we generate, trying to streamline compilations as much as possible (hence the fast-dep stuff). Bob> It seems to me that perhaps 'CYGPATH_W' is misnamed or the use is Bob> outdated. It's entirely possible. This use probably dates to the original Cygwin port of automake and most likely has been carried forward without examination or modification since then. Tom
Re: .cpp to .c
> "Bob" == Bob Lockie <[EMAIL PROTECTED]> writes: Bob> I have: Bob> arson_SOURCES = arson.cpp Bob> in Makefile.am Bob> and this is changed in Makefile.in Bob> arson_SOURCES = arson.c Bob> Any idea why my .cpp is changed to .c? No, that shouldn't happen. Do you have a small test case? Tom
[Q] Absent directories and automake
Hi all! I have little 'strange' (from automake's point of view :) configuration: in my CVS there is 2 modules present: mylib and mylib-tests -- 2nd is interested for developers (of mylib) only, while mylib is available for public (usual users) by `cvs co mylib` command. Developers of mylib may checkout mylib and tests at once by `cvs co mylib-devel` where is mylib-devel is a special CVS module to checkout both modules: mylib module into 'mylib' directory and mylib-tests into 'mylib/tests' directory. So directory $(top_srcdir)/tests present only in "developer's checkouts"... In my configure script I have the following: #... snip ... AM_MAINTAINER_MODE #... if test "x$USE_MAINTAINER_MODE" = "xyes"; then AC_CONFIG_FILES([\ tests/Makefile \ ... ]) fi and in top level Makefile.am: if MAINTAINER_MODE SUBDIRS += tests endif + and some other tricks dependend on USE_MAINTAINER_MODE and MAINTAINER_MODE condition in Makefiles.am... BUT the problem is: for usual checkouts (when no tests/ directory appear after checkout) my bootstrap script fails on automake execution with following: Makefile.am:7: required directory ./tests does not exist Is there is any way to avoid this behaviour of automake? If no, maybe it is reasonable to allow user to control what files maybe absent and prevent (by some automake option) to issue an error? I found that such configuration is quite suitable for my project but currently I can't implement it :((( Any objections why it can't be implemented (suppressed)?? Regards. Alexander
Re: New snprintfv on CVS
"Gary V. Vaughan" wrote: > Hi Paolo, > > (Hi Bruce, how's it going?) Hi, again, Gary - another autogen is pending -- i18n & getopt_long stuff > Paolo Bonzini wrote: > | I've finally managed to put on CVS the last 1.1 prerelease, Hi Paolo, I can't get it. I keep getting "invalid data from server" tho I'm using 1.11.11. It's been months since savannah has been usable. I'd like to get ag current with snv, but I'd also like to get the changes relesed. Can you send me a patch of your fixes? I still have an snv-1.1-pre source tree around. 'course, I've gone and tried to use the latest auto* tools again... > Yay! Sorry I got bogged down in libtool and didn't do it myself. > > | which I'll release as soon as Automake 1.8 is out > > Yay! Automake 1.8 rocks :-) > Makefile.am: installing `./INSTALL' > Makefile.am: installing `./COPYING' > agen5/Makefile.am: installing `config/compile' > agen5/Makefile.am: installing `config/depcomp' > /usr/local/share/automake-1.8/am/texibuild.am: INFO_DEPS was set with `=' and is now > set with `+=' > doc/Makefile.am:24: installing `config/texinfo.tex' > /usr/local/share/automake-1.8/am/texibuild.am: INFO_DEPS was set with `=' and is now > set with `+=' > + exit 1 > + exit 1 > error: bootstrap failed This is another of those error messages: ``I know what you wanted, but I want you do specify it differently, so I'm quitting until you get it right'' *sigh*. Even worse, when I followed directions and used "+=": > doc/Makefile.am:18: INFO_DEPS must be set with `=' before using `+=' > doc/Makefile.am:24: installing `config/texinfo.tex' > doc/Makefile.am:18: INFO_DEPS must be set with `=' before using `+=' They are both wrong. No way out.
Re: automake -vs- huge projects (1st patch)
> "Tom" == Thomas Fitzsimmons <[EMAIL PROTECTED]> writes: [ suggestions ] Tom> Anyway, this patch brings us closer to using automake-1.8 for libgcj. Tom> Thanks! I think all the patches are in now. Could you try CVS automake and see how big the resulting Makefile.in is? Tom
Re: fortran FC patch
>>> "Michael" == Michael R Nolta <[EMAIL PROTECTED]> writes: Michael> Hi, Hi Michael, Happy new year, and sorry for the delay. Michael> Here's a small patch to automake-1.8 to support the new "FC" fortran Michael> interface in autoconf (AC_PROG_FC,FC,FCFLAGS). Essentially I just Michael> copied the F77 parts and replaced F77->FC, adding a new language with Michael> name "fc". Michael> The patch is simple enough that it's probably ok, and Michael> it seems to work. This looks correct to me, but the only way to ensure it will remain so is to add a test case. Could you write one? See tests/README for guidance. Also we can't install such a new feature without a proper update of the manual. Finally, you should also submit a ChangeLog entry along with your patch. I think that's all :) (All this is summarized on http://sources.redhat.com/automake/contribute.html) Michael> The one bit which I'm not sure about regards file Michael> extensions. I split them between "f77" and "fc", Michael> allocating ".f" and ".for" to the former, ".f90" and Michael> ".f95" to the latter. This probably breaks stuff which Michael> assumed ".f90" was handled by f77. I'm not a fortran user, but I've always wondered why .f90 was listed as an extension for F77. Moving it away sounds sensible to me. -- Alexandre Duret-Lutz
using --tag=XXX in automake-generated rules (Was: Re: 'ccache gcc' as compiler with libtool)
>>> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes: [...about Automake passing --tag=XXX to libtool...] Gary> Alexandre Duret-Lutz wrote: >> >> How can automake determine whether the version of libtool used in >> >> a package supports --tag ? [...] Gary> _LT_AC_TAGCONFIG exists in branch-1-5 and HEAD. Not quite. branch-1-5 has _LT_AC_TAGCONFIG but HEAD has _LT_AC_TAG_CONFIG. I prefer to rely on AC_LIBTOOL_TAGS, because this macro supplies a list of supported tags (either the tags supplied by the users, or the default list of tags). Is this OK with you? Below is the implementation I propose, it traces both _LT_AC_TAG_CONFIG for Libtool 1.5 and AC_LIBTOOL_TAGS for newer versions. BTW currently the --tag option and the AC_LIBTOOL_TAGS macro are not documented in the Libtool manual. 2004-01-02 Alexandre Duret-Lutz <[EMAIL PROTECTED]> Fix for PR automake/289: * automake.in (Automake::Struct::libtool_tag): New attribute. Define it for the language that have a Libtool tag. (%libtool_tags): New variable. (handle_languages, define_compiler_variable) (define_linker_variable): Pass --tag=XXX to libtool if supported. (scan_autoconf_traces): Scan for _LT_AC_TAGCONFIG and AC_LIBTOOL_TAGS. * tests/libtool3.test, tests/subobj9.test: Check that --tag=XXX are output. Index: NEWS === RCS file: /cvs/automake/automake/NEWS,v retrieving revision 1.260 diff -u -r1.260 NEWS --- NEWS1 Jan 2004 18:54:20 - 1.260 +++ NEWS2 Jan 2004 18:37:17 - @@ -1,5 +1,8 @@ New in 1.8a: +* Libtool tags are used with libtool versions that support it. + (I.e., with Libtool 1.5 or greater.) + * Makefile.in bloat reduction. - Inference rules are used to compile sources in subdirectories when Index: automake.in === RCS file: /cvs/automake/automake/automake.in,v retrieving revision 1.1533 diff -u -r1.1533 automake.in --- automake.in 1 Jan 2004 21:57:23 - 1.1533 +++ automake.in 2 Jan 2004 18:37:21 - @@ -76,6 +76,9 @@ # (defaults to []) 'flags' => "@", + # Any tag to pass to libtool while compiling. + 'libtool_tag' => "\$", + # The file to use when generating rules for this language. # The default is 'depend2'. 'rule_file' => "\$", @@ -332,6 +335,9 @@ # Where AM_GNU_GETTEXT appears. my $ac_gettext_location; +# Lists of tags supported by Libtool. +my %libtool_tags = (); + # TRUE if we've seen AC_CANONICAL_(HOST|SYSTEM). my $seen_canonical = 0; my $canonical_location; @@ -663,6 +669,7 @@ 'linker' => 'LINK', 'link' => '$(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) $(LDFLAGS) -o $@', 'compile_flag' => '-c', + 'libtool_tag' => 'CC', 'extensions' => ['.c'], '_finish' => \&lang_c_finish); @@ -678,6 +685,7 @@ 'compiler' => 'CXXCOMPILE', 'compile_flag' => '-c', 'output_flag' => '-o', + 'libtool_tag' => 'CXX', 'lder' => 'CXXLD', 'ld' => '$(CXX)', 'pure' => 1, @@ -788,6 +796,7 @@ 'compiler' => 'F77COMPILE', 'compile_flag' => '-c', 'output_flag' => '-o', + 'libtool_tag' => 'F77', 'lder' => 'F77LD', 'ld' => '$(F77)', 'pure' => 1, @@ -820,6 +829,7 @@ 'compile' => '$(F77) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_FFLAGS) $(FFLAGS)', 'compile_flag' => '-c', 'output_flag' => '-o', + 'libtool_tag' => 'F77', 'pure' => 1, 'extensions' => ['.F']); @@ -837,6 +847,7 @@ 'compiler' => 'RCOMPILE', 'compile_flag' => '-c', 'output_flag' => '-o', + 'libtool_tag' => 'F77', 'pure' => 1, 'extensions' => ['.r']); @@ -852,6 +863,7 @@ 'compiler' => 'GCJCOMPILE', 'compile_flag' => '-c', 'output_flag' => '-o', + 'libtool_tag' => 'GCJ', 'lder' => 'GCJLD', 'ld' => '$(GCJ)', 'pure' => 1, @@ -1148,7 +1160,14 @@ if set_seen ($val); } - my $obj_ltcompile = '$(LIBTOOL) --mode=compile ' . $obj_compile; + my $libtool_tag = ''; + if ($lang->libtool_tag && exists $libtool_tags{$lang->libtool_tag}) + { + $libtool_tag = '--tag=' . $lang->libtool_tag . ' ' + } + + my $obj_ltcompile = + '$(LIBTOOL) --mod
Re: aclocal-1.8/m4_include behaving oddly
>>> "pme" == Phil Edwards <[EMAIL PROTECTED]> writes: pme> One of the GCC runtime libraries (libstdc++-v3) has for years contained pme> the following lines in acinclude.m4: pme> m4_include([../libtool.m4]) pme> dnl The lines below arrange for aclocal not to bring an installed pme> dnl libtool.m4 into aclocal.m4, while still arranging for automake to pme> dnl add a definition of LIBTOOL to Makefile.in. pme> ifelse(,,,[AC_SUBST(LIBTOOL) pme> AC_DEFUN([AM_PROG_LIBTOOL]) pme> AC_DEFUN([AC_LIBTOOL_DLOPEN]) pme> AC_DEFUN([AC_PROG_LD]) pme> ]) I agree with Andreas Schwab that if you switch to aclocal 1.8, all these lines can be removed if `-I ..' is passed to aclocal. In that case aclocal 1.8 should add the m4_include itself. It's cleaner. However what you see is definitely a bug in aclocal 1.8. aclocal 1.8 does scan m4_included files (1.7 did not), but it only scan them for required macros without looking at macro definitions. So it sees that ../libtool.m4 requires macros like _AC_LIBTOOL_CXX but does not find them. I'm installing the following fix on HEAD and branch-1-8. 2004-01-02 Alexandre Duret-Lutz <[EMAIL PROTECTED]> * aclocal.in (%file_includes): New variable. (scan_configure_dep): Compile $m4_include_rx and $ac_require_rx once. (scan_file): Scan for included files, and process these files recursively. Fill %file_includes and %file_contents. Return the list of included files, not the contents. (scan_m4_files): Adjust calls to scan_files. (strip_redundant_includes): New function. (trace_used_macros): Call it. (write_aclocal): Likewise. Also check the mtime of included files. * tests/Makfile.am (TESTS): Add acloca14.test. * tests/acloca14.test: New file. Report from Phil Edwards. Index: THANKS === RCS file: /cvs/automake/automake/THANKS,v retrieving revision 1.233 diff -u -r1.233 THANKS --- THANKS 1 Jan 2004 18:54:20 - 1.233 +++ THANKS 2 Jan 2004 14:41:00 - @@ -185,6 +185,7 @@ Peter Mattis [EMAIL PROTECTED] Peter Muir [EMAIL PROTECTED] Petter Reinholdtsen[EMAIL PROTECTED] +Phil Edwards [EMAIL PROTECTED] Phil Nelson[EMAIL PROTECTED] Philip Fong[EMAIL PROTECTED] Philip S Tellis[EMAIL PROTECTED] Index: aclocal.in === RCS file: /cvs/automake/automake/aclocal.in,v retrieving revision 1.97 diff -u -r1.97 aclocal.in --- aclocal.in 1 Jan 2004 17:34:17 - 1.97 +++ aclocal.in 2 Jan 2004 14:41:00 - @@ -74,6 +74,8 @@ # Remember the order into which we scanned the files. # It's important to output the contents of aclocal.m4 in the opposite order. +# (Definitions in first files we have scanned should override those from +# later files. So they must appear last in the output.) @file_order = (); # Map macro names to file names. @@ -82,6 +84,9 @@ # Map file names to file contents. %file_contents = (); +# Map file names to included files (transitively closed). +%file_includes = (); + # How much to say. $verbose = 0; @@ -125,7 +130,7 @@ # First, scan acinclude.m4 if it exists. if (-f 'acinclude.m4') { - $file_contents{'acinclude.m4'} = &scan_file ('acinclude.m4'); + &scan_file ('acinclude.m4'); } local ($m4dir); @@ -149,7 +154,7 @@ next if $file eq 'aclocal.m4'; $fullfile = $m4dir . '/' . $file; - $file_contents{$fullfile} = &scan_file ($fullfile); + &scan_file ($fullfile); } closedir (DIR); } @@ -219,12 +224,12 @@ s/\bdnl\b.*$//; s/\#.*$//; - while (/$m4_include_rx/g) + while (/$m4_include_rx/go) { push (@ilist, $1 || $2); } - while (/$ac_require_rx/g) + while (/$ac_require_rx/go) { push (@rlist, $1 || $2); } @@ -261,15 +266,23 @@ # Point to the documentation for underquoted AC_DEFUN only once. my $underquoted_manual_once = 0; -# Scan a single M4 file. Return contents. +# Scan a single M4 file, and all files it includes. +# Return the list of included files. sub scan_file ($) { - local ($file) = @_; + my ($file) = @_; + my $base = dirname $file; + + # Do not scan the same file twice. + return @$file_includes{$file} if exists $file_includes{$file}; + # Prevent potential infinite recursion (if two files include each other). + return () if exists $file_contents{$file}; unshift @file_order, $file; my $fh = new Automake::XFile $file; my $contents = ''; + my @inc_files = (); while ($_ = $fh->getline) { # Ignore `##' lines. @@ -277,7 +290,7 @@ $contents .= $_; - if (/$ac_defun_rx/) + while (/$ac_defun_rx/go) { if (! defined $1) { @@ -288,11 +301,12 @@