Re: [OMPI devel] GNU Automake 1.14 released
I think autotools has a concept of disallowing symlinks as it seems symlinks can't be done in a portable way, and the goal of autotools is making projects portable. Well, if the autotools user feels like using symlinks, then it must be expected to break portability wherever you take your autoconfiscated code to. A choice to the user. Maybe in the case, as the project is bound to specific compilers, it would not be a problem to loose portability a bit more by considering symbolic linking around. -Original Message- From: Jeff Squyres (jsquyres) Sent: Tuesday, September 03, 2013 4:24 pm To: Open MPI Developers Cc: Automake List Subject: Re: [OMPI devel] GNU Automake 1.14 released How about sym linking the source file? Then you would only need a single Makefile.am; you can use different flags depending on which source file you compile. While somewhat gross, it's not totally disgusting, and it should work to the same effect...? On Aug 30, 2013, at 4:16 AM, Bert Wesarg bert.wes...@googlemail.com wrote: Hi, On Fri, Jun 21, 2013 at 2:01 PM, Stefano Lattarini stefano.lattar...@gmail.com wrote: We are pleased to announce the GNU Automake 1.14 minor release. - The next major Automake version (2.0) will unconditionally activate the 'subdir-objects' option. In order to smooth out the transition, we now give a warning (in the category 'unsupported') whenever a source file is present in a subdirectory but the 'subdir-object' is not enabled. For example, the following usage will trigger such a warning: bin_PROGRAMS = sub/foo sub_foo_SOURCES = sub/main.c sub/bar.c we don't understand how this warning should 'smooth' the transition to post-1.14 in our project. Here is our situation: We have a source file which needs to be compiled twice. But with different compilers. Thus we can't use per-target flags and we use two separate Makefile.am files for this. Because the compilation rules are nearly identical, we use a Makefile.common.inc.am file which will be included by both Makefile.am's. Here is the directory layout (the complete reduced testcase is attached): src/foo.c src/Makefile.am src/Makefile.common.inc.am src/second/Makefile.am The src/Makefile.am looks like: 8 src/Makefile.am 8 --- SUBDIRS = second MY_SRCDIR=. include Makefile.common.inc.am bin_PROGRAMS=foo foo_SOURCES=$(FOO_COMMONSOURCES) 8 src/Makefile.am 8 --- 8 src/second/Makefile.am 8 --- CC=$(top_srcdir)/bin/wrapper MY_SRCDIR=.. include ../Makefile.common.inc.am bin_PROGRAMS=foo-wrapped foo_wrapped_SOURCES=$(FOO_COMMONSOURCES) 8 src/second/Makefile.am 8 --- 8 src/Makefile.common.inc.am 8 --- FOO_COMMONSOURCES = $(MY_SRCDIR)/foo.c 8 src/Makefile.common.inc.am 8 --- This works with automake 1.13.4 as expected. Now, with automake 1.14 we get the newly introduced warning mentioned above in the release statements. Now enabling subdir-objects is not yet an option for us, because we use variables in the _SOURCES list and bug 13928 [1] hits us. So what would be the best transition in this situation? We don't want to remove the Makefile.common.inc.am to avoid the resulting redundancy in the two Makefile.am files. We also can't use the newly introduced %reldir%, because it also throws the warning, and also want to maintain compatibly with pre-1.14 automake. Any guidance is more than welcomed. Kind Regards, Matthias Jurenz Bert Wesarg [1] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13928 foo-subdir-objects-warnings.tar.gz___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: automake with fortran
Rudra, The make rules are really set manually.. As far as I know there's no dependency tracking support implemented to fortran until someone kind enough steps in development. For example if I have mod_a and mod_b, and code_a uses them both, in the bottom of the Makefile.am (yes, the .am), I put: code_a.o: code_a.F90 mod_a.o mod_b.o I am not sure it differs from using the '.o' or '.mod' suffix for the module files. I chose .o as there might be a chance a given compiler may produce .MOD or something else that will never be matched by a .mod rule, while I believe the .o will always be .o... In the end, I leave rules for every single file: code_a.o: code_a.F90 mod_a.o mod_b.o mod_a.o: mod_a.F90 mod_b.o: mod_b.F90 And then I can happily use -jn to perform a parallel compile. The mod_n.o lines will be there just for the case I add any dependency to them. As for the order of the source file in the Makefile.am, all that matters is the dependency be in place. Although in the example mod_a.o is listed after code_a.o, when code_a rule is analysed, it will postpone its performance for after moda_a.o rule is satisfied. The order rules show in the makefile is particularly irrelevant when you try make -jn as it will try to perform the n rules a time as far as their dependencies are met. - fabricio -Original Message- From: Rudra Banerjee Sent: Friday, July 26, 2013 5:23 AM To: FabrícioZimmerer Murta Cc: automake@gnu.org Subject: Re: automake with fortran But even then, do src/Makefile.am is happy with any order of the source file or you have to keep the order manually? On Thu, 2013-07-25 at 14:11 -0300, Fabrício Zimmerer Murta wrote: I implemented GNU Build System on a fortran project I work with.. I've created a 'Makefile.am' inside src/ (src/Makefile.am) thus my PACKAGE_ROOT/Makefile.am has a 'SUBDIRS=src'. This will make 'GNU Make' to chdir into src/ dir and the created modules works just fine. I think this 'subdirs' and sub-makefiles-am are the way gnu build system is intended to work. For example, for distributed 'datadir' files (who get into PREFIX/share), I have Makefile.am's into each directory, the inside Makefile.am's actually determines what is installed to localstatedir, datadir, as fitting. I hope this helps. - fabrício -Original Message- From: Rudra Banerjee Sent: Thursday, July 25, 2013 1:53 PM To: automake@gnu.org Subject: automake with fortran Hello friends, I am facing a small problem when trying to build my code with autotools. My file structure is: $ tree . |-- configure.ac |-- Makefile.am `-- src |-- constants.f90 |-- environment.f90 |-- init.f90 |-- main.f90 `-- util.f90 (deleted possibly unnecessary lines) and my Makefile.am is: #SUBDIRS= help bin_PROGRAMS = scasr scasr_SOURCES = \ src/constants.f90 src/environment.f90 src/util.f90 \ src/init.f90 src/main.f90 scasr_LDADD = EXTRA_DIST= autogen.sh CLEANFILES =*.mod The problem is src/(*.f90)'s except main.f90 are module. Hence, if I have to write the makefile by hand, I will have: constants.o : constants.f90 environment.o : environment.f90 init.o : init.f90 util.o constants.o main.o : main.f90 init.o constants.o environment.o util.o : util.f90 constants.o so, for Makefile.am, I have to make a strict order of files in scasr_SOURCES. i.e. with the sources as : scasr_SOURCES = \ src/constants.f90 src/environment.f90 src/util.f90 \ src/init.f90 src/main.f90 It compiles fine. But if I have as: scasr_SOURCES = src/main.f90 \ src/constants.f90 src/environment.f90 src/util.f90 \ src/init.f90 I get error: ake all-am make[1]: Entering directory `/home/rudra/Programs/ScASR/trunk' gfortran -g -O2 -c -o src/main.o src/main.f90 src/main.f90:7.4: use mget_env 1 Fatal Error: Can't open module file 'mget_env.mod' for reading at (1): No such file or directory make[1]: *** [src/main.o] Error 1 Is there any way out so that make/configure will check the dependency by itself?
Re: automake with fortran
I implemented GNU Build System on a fortran project I work with.. I've created a 'Makefile.am' inside src/ (src/Makefile.am) thus my PACKAGE_ROOT/Makefile.am has a 'SUBDIRS=src'. This will make 'GNU Make' to chdir into src/ dir and the created modules works just fine. I think this 'subdirs' and sub-makefiles-am are the way gnu build system is intended to work. For example, for distributed 'datadir' files (who get into PREFIX/share), I have Makefile.am's into each directory, the inside Makefile.am's actually determines what is installed to localstatedir, datadir, as fitting. I hope this helps. - fabrício -Original Message- From: Rudra Banerjee Sent: Thursday, July 25, 2013 1:53 PM To: automake@gnu.org Subject: automake with fortran Hello friends, I am facing a small problem when trying to build my code with autotools. My file structure is: $ tree . |-- configure.ac |-- Makefile.am `-- src |-- constants.f90 |-- environment.f90 |-- init.f90 |-- main.f90 `-- util.f90 (deleted possibly unnecessary lines) and my Makefile.am is: #SUBDIRS= help bin_PROGRAMS = scasr scasr_SOURCES = \ src/constants.f90 src/environment.f90 src/util.f90 \ src/init.f90 src/main.f90 scasr_LDADD = EXTRA_DIST= autogen.sh CLEANFILES =*.mod The problem is src/(*.f90)'s except main.f90 are module. Hence, if I have to write the makefile by hand, I will have: constants.o : constants.f90 environment.o : environment.f90 init.o : init.f90 util.o constants.o main.o : main.f90 init.o constants.o environment.o util.o : util.f90 constants.o so, for Makefile.am, I have to make a strict order of files in scasr_SOURCES. i.e. with the sources as : scasr_SOURCES = \ src/constants.f90 src/environment.f90 src/util.f90 \ src/init.f90 src/main.f90 It compiles fine. But if I have as: scasr_SOURCES = src/main.f90 \ src/constants.f90 src/environment.f90 src/util.f90 \ src/init.f90 I get error: ake all-am make[1]: Entering directory `/home/rudra/Programs/ScASR/trunk' gfortran -g -O2 -c -o src/main.o src/main.f90 src/main.f90:7.4: use mget_env 1 Fatal Error: Can't open module file 'mget_env.mod' for reading at (1): No such file or directory make[1]: *** [src/main.o] Error 1 Is there any way out so that make/configure will check the dependency by itself?
AM_CONDITIONAL to choose between building library or linking directly
Is that supposed not to work? (“LIBRARY_BUILD” AM_CONDITIONAL set accordingly on configre.ac) Makefile.am: if LIBRARY_BUILD lib_LTLIBRARIRES = libprog.la libprog_la_SOURCES = a.c b.c d.c else !LIBRARY_BUILD bin_PROGRAMS = driver driver_SOURCES = a.c b.c d.c driver.c endif !LIBRARY_BUILD if LIBRARY_BUILD a.lo: a.c b.lo b.lo: b.c d.lo: d.c a.lo b.lo else !LIBRARY_BUILD a.o: a.c b.o b.o: b.c d.o: d.c a.o b.o driver.o: driver.c a.o b.o d.o endif !LIBRARY_BUILD ### With a setup like this I get errors like Makefile.am: object ‘a.$(OBJEXT)’ created both with libtool and without for a, b and d source files. Removing ‘a.c’ from one of the libprog_la_SOURCES -or- driver_SOURCES takes out the error message but also renders either the library or driver unbuildable... thank ya. p.s.: I am using fortran, so I -must- build rules manually. anyway, the problem part is at the ‘*_SOURCES =’ definition.
Re: AM_CONDITIONAL to choose between building library or linking directly
these prerequisites look very odd as they say that object files depend on other object files Blame fortran for that. Is 'b' is a module, I have to assure 'a' is compiled only when 'b' is compiled (so the .mod file is created). With this rule, I can assure make -jN would not result in error. I think your noinst_ suggestion really does the trick, although I thought it was an incosistent error. If I am not building any library, it shouldn't think I am building one (as long as I sepparated it correctly with conditionals). :/ But thank you, I was really wondering if that noinst_ approach would fit, it turns that it's the only solution. -Original Message- From: Nick Bowler Sent: Tuesday, September 11, 2012 4:42 PM To: FabrícioZimmerer Murta Cc: Automake Mailing List Subject: Re: AM_CONDITIONAL to choose between building library or linking directly On 2012-09-11 15:41 -0300, Fabrício Zimmerer Murta wrote: Is that supposed not to work? (“LIBRARY_BUILD” AM_CONDITIONAL set accordingly on configre.ac) Makefile.am: if LIBRARY_BUILD lib_LTLIBRARIRES = libprog.la libprog_la_SOURCES = a.c b.c d.c else !LIBRARY_BUILD bin_PROGRAMS = driver driver_SOURCES = a.c b.c d.c driver.c endif !LIBRARY_BUILD Instead of the pattern above, what will probably work is to use the conditional to select between an installable libtool library or a libtool convenience library, so that libtool is used in both cases. For example (untested): if LIBRARY_BUILD lib_LTLIBRARIES = libprog.la else noinst_LTLIBRARIES = libprog.la bin_PROGRAMS = driver endif libprog_la_SOURCES = a.c b.c d.c driver_SOURCES = driver.c driver_LDADD = libprog.la if LIBRARY_BUILD a.lo: a.c b.lo b.lo: b.c d.lo: d.c a.lo b.lo else !LIBRARY_BUILD a.o: a.c b.o b.o: b.c d.o: d.c a.o b.o driver.o: driver.c a.o b.o d.o endif !LIBRARY_BUILD Then with the above change, the else case of this conditional is now not required. Note that regardless of what you do, these prerequisites look very odd as they say that object files depend on other object files (which would imply that b.o is somehow required to update a.o: very unusual in a C program). Moreover, Automake already provides prerequisites from object files to their C source files, so listing the .c files here is redundant. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
BUG: AC_PROG_FC does not define GCF when compiler is gfortran
If I read http://www.gnu.org/software/autoconf/manual/autoconf.html#Specifying-Target-Triplets, I read: If using gfortran or g77 (the GNU Fortran compilers), then set the shell variable GFC to ‘yes’. If the output variable FCFLAGS was not already set in the environment, then set it to -g -02 for GNU g77 (or -O2 where g77 does not accept -g). Otherwise, set FCFLAGS to -g for all other Fortran compilers. But this is not what happens. There’s no code on fortran.m4 to fill such variable, as there’s for GCC and G77 variables. This should be simple to fix and be present on a next variable. I found this while adequating configure.ac for cross-compiling. I realised that just checking for ‘gcc’ ‘icc’ ‘gfortran’ ‘ifort’ is not enough to define the compiler, as the host might be attached to it, so I found GFC variable interesting to define for the GNU versions. I will be using ac_cv_fc_compiler_gnu for now. I hope this information helps! - fabrício
Manual dependency: specifying config.h on Automake.am
Hello, I am unable to use automatic dependency tracking as I have been doing a project in Fortran 90. My problem is: when I change include/config.h, src/*.F90 which have the include/ file “included” are not recompiled (as would be expected). I wonder if it would be okay just to add to the Makefile rules the “../include/config.h” or if there’s a better way to express this dependency as (a) all files depend on include/config.h (b) compiles on different paths could break if they look for files inside ../include relative path. Thank you, I am sorry if this is a too dumb question, I am a newbie on GNU Build System indeed. :) - fabricio
Re: Directions on compiling the right files
That's really what I was looking for. Thank you very much for your time! -- From: dherr...@tentpost.com Sent: Tuesday, December 06, 2011 2:05 AM To: automake@gnu.org Subject: Re: Directions on compiling the right files In other words, there will be new .c files that should be compiled only for the windows version and some .c files exclusive to the linux version. Suppose also I want to specify this at configure-time (e.g. ./configure builds linux, ./configure --enable-win32 builds windows). I know I can do this on configure.ac, but I don't know, at configure time, how would I change the Makefile's dependencies for each of these two builds. Any directions on how to do this (pointing a relatively simple package that does this also can help a lot) are very well accepted! Use conditionals. http://www.gnu.org/software/automake/manual/html_node/Usage-of-Conditionals.html something like if COND_WINDOWS prog_SOURCES+=win32.c endif if COND_LINUX prog_SOURCES+=linux.c endif - Daniel
Directions on compiling the right files
Hello, I am a bit lost here. We recently started a project using GNU Build System in order to make our package installable everywhere without mysteries of package-specific builds. Now I am facing a problem I will try to explain with an easier to understand example. Suppose I am making an application and it currently supports Linux system. Now suppose I am to add Windows access and this would imply adding some source files for windows-specific routines and removing some linux-specific routines. Some of the work can be done via preprocessor macros. But if some .c files are not to be compiled at all, I could either remove the entire file via macros, but I doubt I will get any .o out of these empty files, and I will not want to include these .o's in the linking phase. In other words, there will be new .c files that should be compiled only for the windows version and some .c files exclusive to the linux version. Suppose also I want to specify this at configure-time (e.g. ./configure builds linux, ./configure --enable-win32 builds windows). I know I can do this on configure.ac, but I don't know, at configure time, how would I change the Makefile's dependencies for each of these two builds. Any directions on how to do this (pointing a relatively simple package that does this also can help a lot) are very well accepted! Thank you, Fabricio Murta
Re: fortran 77 header dependencies
I certainly don't have the cycles, but I wish I could inspire someone to write a Fortran dependency analysis module for Automake! Agreed! I've just started a fortran 90 project and I mean to have the GNU build system on it. There were two major problems I encountered: - Must make manual rules. I generated the rules with dependency tracking using a 'makemake.pl' I found somewhere (I can link/paste it here if anyone has trouble finding it on the internet) and made the needed adaptations for it to work on a Makefile.am (seemingly it worked! hehe) - Although all code files as .F90 (preprocessed fortran 90) and .h (header files), autotools require me to determine the 'c' compiler on configure.ac (AC_PROG_CC). I found a discussion about a good soul who was willing to build such support but, it seems excessive rules for the code to be accepted shoved him off the game. Not sure tough. I can say I will be an addictive tester of such a functionality shall it ever come up. It is not something too complex as a 251-lines-big file is enough to create the dependency rules. Another thing I tried as an attempt for that dependency tracking was to add on configure.ac the plugin macros AX_F90_MODULE_FLAG and AX_F90_MODULE_EXTENSION. They did nothing as far as I could see. As it looked easier to make it with manual rules, I ended up this way. Maybe I missed anything but, if there is no support for f77, I assumed it were not working on f90 as well. - fabricio -Original Message- From: Jeff Squyres Sent: Wednesday, July 13, 2011 3:06 PM To: Dave Goodell Cc: Nick Bowler ; automake@gnu.org Subject: Re: fortran 77 header dependencies On Jul 13, 2011, at 1:50 PM, Dave Goodell wrote: Your correction of Jeff's solution made me realize that my version 3 solution is wrong. It expresses a foo--bar.h dependency instead of foo.o--bar.h dependency. Your approach is what I was looking for. Unfortunately this solution gets even uglier looking if foo has any per-target flags such as foo_FFLAGS=-I.. Agreed. Most of my fortran includes are in different directories, making the manual Makefile rules lengthy / ugly / complicated. I.e., perfect for generation in .deps/. :-) I certainly don't have the cycles, but I wish I could inspire someone to write a Fortran dependency analysis module for Automake! -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
