-c -o
# 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 include it is for # completeness, since a similar test exists for the C compiler. Are you aware of the fact that automake inserts -c -o in the build rule automatically? This makes the usefulness of this test even more questionable, at least in connection with automake. The same holds for C/C++, unless I'm completely mistaken. If such a test can make sense, then automake must provide a configure variable that autoconf can insert in the Makefile in order to assert correct compilation behaviour, right ? Regards Martin -- Martin Wilck [EMAIL PROTECTED] Institute for Tropospheric Research, Permoserstr. 15, D-04318 Leipzig, Germany Tel. +49-341-2352151 / Fax +49-341-2352361
Re: Fortran dependency tracking
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 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. Martin Unfortunately, that approach doesn't work for Fortran INCLUDE Martin statements, and I have not yet found a tool that parses such Martin statements like e.g. makedepend parses #include's. I think the goal here should be to have the Fortran compiler generate the include information -- it can list both the files included via #include and those included via INCLUDE. This way you get complete dependency tracking as a side effect of compilation. Writing a patch to g77 to do this shouldn't be all that hard. Martin - whether such a thing like Fortran dependency tracking is Martin desirable at all in automake/autoconf, Yes. Martin - if yes, which solution we should go for ? When possible, fix the compilers. When not possible, maybe living with less than perfect information is the only approach. Martin P.S. This problem seems to be trivial compared to providing Martin dependency tracking support for Fortran 90 modules. But Martin that's a different issue... This should also be solvable if the compiler is intelligent. Tom
Re: [patch] DESTDIR support for cpio
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
Re: -c -o
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 user. If I'm redefining the .c = .o pattern rule for my purposes (e.g., dependency generation) then I need to know whether the compiler supports -c -o, otherwise I have to do something like cc mv. Please keep it. -- Peter Eisentraut Sernanders väg 10:115 [EMAIL PROTECTED] 75262 Uppsala http://yi.org/peter-e/Sweden
Re: [Re: Shared library with source in sub directories]
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 in the top makefile.
This is suprising. I thought this was one of the benefits of libtool
-- portable library dependencies.
It depends on which version of libtool you're using. IIRC, libtool
1.3.5 (the latest release) still doesn't fully support inter-library
dependencies. 1.4-to-be (CVS trunk) is supposed to fix this problem.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Use automake for sources in subdirs?
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 files? A small example is like this In the src directory, there are two subdirectories, ls src/ a/ b/ ls src/* src/a: a.c src/b: b.c then in src I add two files: Makefile.am: lib_LIBRARIES = libjunk.a libjunk_a_SOURCES = a/a.c b/b.c and configure.in: AC_INIT AM_INIT_AUTOMAKE(junk, 0.1) AC_PROG_CC AC_PROG_CXX AC_PROG_RANLIB AC_OUTPUT(Makefile) then, after this series of commands aclocal autoconf automake -a automake responds with: automake: Makefile.am: not supported: source file `a/a.c' is in subdirectory automake: Makefile.am: not supported: source file `b/b.c' is in subdirectory so how can I use automake to manage the build of the library? One thing I can do is to add Makefile.am to each subdirectory to build a .a file there and then combine them on the top level directory, but this gets tiresome as the number of subdirectories increases. I hope there is a better way. ___ $1 million in prizes! 20 daily instant winners. AltaVista Rewards: Click here to win! http://shopping.altavista.com/e.sdc?e=3 ___
Re: Use automake for sources in subdirs?
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 convenience library in each subdir, and then combine those to make the main library in the main directory. Andy so how can I use automake to manage the build of the library? Andy One thing I can do is to add Makefile.am to each subdirectory to Andy build a .a file there and then combine them on the top level Andy directory, but this gets tiresome as the number of Andy subdirectories increases. I hope there is a better way. With libtool the pain here is minimal. You just add another .la to a list in the toplevel Makefile.am. The next major automake release will have a simple way of doing what you want. Tom
Re: Fortran dependency tracking
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 think we'd also rather avoid distributing a complete Fortran dependency-finding tool with every Fortran-using package. This is hardly ideal, I guess. Tom
