1.8 and mkdir_p

2004-01-02 Thread Harlan Stenn
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

2004-01-02 Thread Tom Tromey
> "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?

2004-01-02 Thread Tom Tromey
> "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

2004-01-02 Thread Tom Tromey
> "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

2004-01-02 Thread Tom Tromey
> "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

2004-01-02 Thread zaufi
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

2004-01-02 Thread Bruce Korb
"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)

2004-01-02 Thread Tom Tromey
> "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

2004-01-02 Thread Alexandre Duret-Lutz
>>> "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)

2004-01-02 Thread Alexandre Duret-Lutz
>>> "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

2004-01-02 Thread Alexandre Duret-Lutz
>>> "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 @@