Re: managing headers in source
On 07/20/2013 12:52 PM, Simon Richter wrote: > Hi Václav, > >> - src/Makefile.am: Listing headers for dependencies and source >> files. >> (http://bazaar.launchpad.net/~log4cplus/log4cplus/trunk/view/head:/src/Makefile.am) > >> > You do not need to list the headers as source files as long as they > are listed somewhere. > > The dependencies start out empty before the first build (which does > not matter because we need to build anyway) and are updated with the > list of headers that were actually used during the build -- these > will include your headers. Thanks. I have removed the includes from the source listing and nothing has broken. I am not myself sure why I have done it that way in the first place. -- VZ signature.asc Description: OpenPGP digital signature
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 -j 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 -j as it will try to perform the 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: non-recursive automake with make 3.81,automake-1.10
Hi, On 2013-07-26 16:53 +0100, Rudra Banerjee wrote: > Hello friends, > In my laptop, I can very well use autotools with the following > Makefile.am : > bin_PROGRAMS = scasr > scasr_SOURCES = src/main.f90\ > src/constants.f90 src/environment.f90 src/util.f90 \ > src/init.f90 > src/constants.o : src/constants.f90 > src/environment.o : src/environment.f90 > src/init.o : src/init.f90 src/util.o src/constants.o > src/main.o : src/main.f90 src/init.o src/constants.o src/environment.o > src/util.o : src/util.f90 src/constants.o [...] > But, in the running environment, with SUSE Linux Enterprise Desktop 11 > SP2, I have: > $autoconf --version > autoconf (GNU Autoconf) 2.63 > $automake --version > automake (GNU automake) 1.10.1 > $make --version > GNU Make 3.81 > > the same thing is giving error: [...] > I am concluding either automake or make is too old to handle > non-recursive makefile. Is this correct? Or, in my Makefile.am itself is > causing the error(may be with some non-standard)? The release notes for Automake 1.11 say: "subdir-object mode works now with Fortran ..." Your Makefile is clearly depends on the subdir-object feature (typical for non-recursive setups), so it appears that you must require Automake 1.11 at minimum. Your SUSE install only has Automake 1.10.1. This is normally not a huge problem as it is normally only necessary to run automake when (re)generating the build system; this is not something users building from a release tarball will ordinarily need to do. Hope that helps, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
non-recursive automake with make 3.81,automake-1.10
Hello friends, In my laptop, I can very well use autotools with the following Makefile.am : bin_PROGRAMS = scasr scasr_SOURCES = src/main.f90\ src/constants.f90 src/environment.f90 src/util.f90 \ src/init.f90 src/constants.o : src/constants.f90 src/environment.o : src/environment.f90 src/init.o : src/init.f90 src/util.o src/constants.o src/main.o : src/main.f90 src/init.o src/constants.o src/environment.o src/util.o : src/util.f90 src/constants.o scasr_LDADD = EXTRA_DIST= autogen.sh CLEANFILES =*.mod In My laptop, I have: $ autoconf --version autoconf (GNU Autoconf) 2.69 $ automake --version automake (GNU automake) 1.13.4 $ make -v GNU Make 3.82 But, in the running environment, with SUSE Linux Enterprise Desktop 11 SP2, I have: $autoconf --version autoconf (GNU Autoconf) 2.63 $automake --version automake (GNU automake) 1.10.1 $make --version GNU Make 3.81 the same thing is giving error: $make make all-am make[1]: Entering directory `/home/physics/phslav/trunk' make[1]: *** No rule to make target `main.o', needed by `scasr'. Stop. make[1]: Leaving directory `/home/physics/phslav/trunk' I am concluding either automake or make is too old to handle non-recursive makefile. Is this correct? Or, in my Makefile.am itself is causing the error(may be with some non-standard)?
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? >
