Re: Use automake for sources in subdirs?
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? > The next major automake release will have a simple way of doing what > you want. > > Tom Thanks for the reply. By checking the latest automake out of CVS, adding this line to Makefile.am AUTOMAKE_OPTIONS = subdir-objects and copying the file "compile" from the automake distribution to the src directory, it seems to work now. I hope this is the correct way to do it when the next major version is released. Again thanks for your help. ___ $1 million in prizes! 20 daily instant winners. AltaVista Rewards: Click here to win! http://shopping.altavista.com/e.sdc?e=3 ___
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
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
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 including AC_PROG_CC in configure.in also "solves" the problem. > 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. Well, well - perhaps not. I don't know if I can do it, though. Will take some time in any case. > 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. I have tested quite a few compilers recently, and for none I found an option that would do what you suggest :-( "The compiler" is a difficult term here, as every compiler treats modules differently. They can't even agree whether module file names should be generated from module names or source file names. For example, from a file "foo.f90" containing MODULE bar END MODULE bar one compiler would generate a module file "foo.M", the other "bar.mod", yet another "BAR.mod", and again another two files, "bar.vo" and "Vfoo.inc". (These are real examples). If I understand the automake philosophy right, then it suffices to support only a few compilers, generate the dependencies on the maintainer's site, and include them into the distributed Makefiles. For Fortran 77, making g77 report correct dependencies would therefore suffice. However, for Fortran 90 we'd have two problems: 1 - unfortunately, there is no available public domain F90/F95 compiler, so we can't assume one to be available for all maintainers. 2 - As stated above, there is no compiler-independent way to associate modules with file names. Problem 2) may probably be avoided by generating dependencies only for object files (just thinking aloud :-) Regards, Martin -- Martin Wilck <[EMAIL PROTECTED]> Inst. for Tropospheric Research, Permoserstr. 15, 04303 Leipzig, Germany
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: [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
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: [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: [patch] DESTDIR support for cpio
>> 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) interesting history here. I was the cpio maintainer for a while. I started writing a pax front end to it, among other things. One day I decided to clean up the cpio Makefiles to conform to GNU standards. This turned out to be relatively painful. So I started using the original (djm) automake. Then I started extending that script (back then automake was a /bin/sh script) to do more of what I needed. I then started talking to my Gnits friends about it, and extending it to help them, too. One day (at their urging), I rewrote it in Perl, and the modern automake was born. Unfortunately cpio got dropped in the meantime. So, the package that created automake was left without the benefit of using it. cpio was then given to François for inclusion in the "paxutils" (which includes tar). From there it migrated to Paul Eggert. These programs (tar/pax/cpio) are cursed in a way -- it is hard to get a release of them out. I failed to do it anyway. Tom
Re: [patch] DESTDIR support for cpio
>
> [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 automake to generate Makefile.in. It is probably useless
to patch it since they will be erase on the next
make distclean; make dist
IMO, if that is important for you to have DESTDIR, you should rather
patch automake or have a discussion on the automake/autoconf lists
automake is the one enforcing GNU Makefile{,.in} plicies, must
Makefile.in's are autogenerated nowadays.
It was/is my understanding that automake honoured DESTDIR.
>
> Wil
> --
> Index: Makefile.in
> ===
--
au revoir, alain
Aussi haut que l'on soit assis, on n'est toujours assis que sur son cul !!!
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
Fortran dependency tracking
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 (only Fortran source files). The reason is that the Makefile contains dependencies on .deps/whatever.Po which doesn't exist, but has no rule for generating these. Once a single C source file exists in the same directory, the problem disappears. I have not understood the dependency tracking code for C/C++ well enough yet to fix this. Second, if the Fortran/cpp code became part of autoconf, it would be relatively easy to track Fortran dependencies resulting from cpp #include statements. Basically, the same approach as for C/C++ could be used (g77 supports -MM and -MD, and fpp supports -M with very similar outcome. "makedepend" also works with Fortran input files). Unfortunately, that approach doesn't work for Fortran INCLUDE statements, and I have not yet found a tool that parses such statements like e.g. makedepend parses #include's. It would be relatively simple to provide e.g. a simple perl script taking care of this. Such a script, however, would only recognize basic syntax. The following code: I Nclu De 1'i3.in 2c' which is valid Fortran 77 syntax for including a file called 'i3.inc', would certainly not recognized by a simple script, which would probably parse for something like ^ *[iI][nN][cC][lL][uU][dD][eE] *["']\(.*\)["'] In order to do it right (so that any valid Fortran INCLUDE be recognized), one would need (almost) a fully-fledged Fortran parser, and I cowardly refuse to start writing one (I have considered stripping down the parsers of either f2c or g77, but even that looks like a huge amount of work). Could anyone comment on - whether such a thing like Fortran dependency tracking is desirable at all in automake/autoconf, - if yes, which solution we should go for ? Regards, Martin P.S. This problem seems to be trivial compared to providing dependency tracking support for Fortran 90 modules. But that's a different issue... -- Martin Wilck <[EMAIL PROTECTED]> Institute for Tropospheric Research, Permoserstr. 15, D-04318 Leipzig, Germany Tel. +49-341-2352151 / Fax +49-341-2352361
Re: -c -o
> "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 removal of this macro. Martin> The same holds for C/C++, unless I'm completely mistaken. 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. Martin> If such a test can make sense, then automake must provide a Martin> configure variable that autoconf can insert in the Makefile in Martin> order to assert correct compilation behaviour, right ? That's correct. The fact that Automake does not seem to need it in just another sign this macro is probably useless. I see no point in fixing this unless someone asks for it, I'd rather remove it.
-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
