On Mon, 17 July 2000, Tom Tromey wrote:
>
> Andy> I am trying to use automake 1.4 on an existing software package
> Andy> whose source directory are organized as a set of subdirectories.
> Andy> How can I write a makefile.am to automatically generate a
> Andy> library file from these source files
Martin> If I understand the automake philosophy right, then it
Martin> suffices to support only a few compilers, generate the
Martin> dependencies on the maintainer's site, and include them into
Martin> the distributed Makefiles.
Actually, ideally we'd like to support every compiler. However, I
Andy> I am trying to use automake 1.4 on an existing software package
Andy> whose source directory are organized as a set of subdirectories.
Andy> How can I write a makefile.am to automatically generate a
Andy> library file from these source files?
The easiest way in 1.4 is to make a libtool conv
On Mon, 17 Jul 2000, Tom Tromey wrote:
> Could you submit a bug report to the automake Gnats? Mark it
> "critical/high". We need to fix this before the next release.
> There should be a link to Gnats from http://sourceware.cygnus.com/automake/
> Thanks.
Just sent it in. I just discovered that
Hi, I am new to automake, so please excuse me if this question is basic:
I am trying to use automake 1.4 on an existing software package whose source directory
are organized as a set of subdirectories. How can I write a makefile.am to
automatically generate a library file from these source fil
On Jul 16, 2000, Tom Tromey <[EMAIL PROTECTED]> wrote:
Murray> 1) This doesn't work recursively. For instance, if sub
Murray> contains, subsub, which contains subsusbsub, then the library
Murray> at sub will contain subsub but not subsubsub. Therefore you
Murray> have to LIBADD all the libraries
Akim Demaille writes:
> I'm all for the removal of this macro.
> I'm for the removal of C's one too (there is none for C++ right?), but
> here we are hitting the backward compatibility barrier. In fact, this
> macro should move under GNU Make's responsibility, since it's probably
> the only use
Alain> It was/is my understanding that automake honoured DESTDIR.
It does.
Any failure of DESTDIR is most likely a bug in a particular package's
Makefile.am. If not, then it is an automake bug and should be
reported.
Tom
>> This patch adds support to cpio 2.4.2 for the DESTDIR macro, which
>> according to people on gnu.misc.discuss is the appropriate macro for
>> supporting an installation root.
Alain> It was/is my understanding that automake honoured DESTDIR.
Note that cpio in particular has a sad but (perhaps)
>
> [This message has also been posted.]
> This patch adds support to cpio 2.4.2 for the DESTDIR macro, which
> according to people on gnu.misc.discuss is the appropriate macro for
> supporting an installation root.
I'm not sure you are taking the right approach most of the GNU utils
use automak
I removed the autoconf list from the followups. Dependency tracking
doesn't involve autoconf.
Martin> First of all, an automake-generated makefile refuses to work
Martin> if there is no C source file specified in Makefile.am (only
Martin> Fortran source files).
Could you submit a bug report to
I'd like to draw your attention to the following problem:
There is one thing the autoconf/automake support for Fortran 77
is currently lacking: dependency tracking like for C/C++.
First of all, an automake-generated makefile refuses to work
if there is no C source file specified in Makefile.am
> "Martin" == Martin Wilck <[EMAIL PROTECTED]> writes:
Martin> Are you aware of the fact that automake inserts -c -o in the
Martin> build rule automatically? This makes the usefulness of this
Martin> test even more questionable, at least in connection with
Martin> automake.
I'm all for the
# AC_PROG_F77_C_O
# ---
# Test if the Fortran 77 compiler accepts the options `-c' and `-o'
# simultaneously, and define `F77_NO_MINUS_C_MINUS_O' if it does not.
#
# The usefulness of this macro is questionable, as I can't really see
# why anyone would use it. The only reason I inclu
14 matches
Mail list logo
