non-recursive automake with make 3.81,automake-1.10

2013-07-26 Thread Rudra Banerjee
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: non-recursive automake with make 3.81,automake-1.10

2013-07-26 Thread Nick Bowler
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/)



Re: automake with fortran

2013-07-26 Thread Fabrício Zimmerer Murta

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: managing headers in source

2013-07-26 Thread Václav Zeman
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