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'.

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

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 dur

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 co

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

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 serv

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> co

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

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 libtoo