Build system for Fortran
Eli Osherovich
Slowly, my collection of files becomes large enough to abandon manual
(re) compilation each time I change a bit here and there. This is the
time chose a build system to work with. I could go with makefile,
however, rumors say there are much better alternatives these days.
Most mention SCons and CMake. Which one would be the best choice for
Fortran?
Thank you.
aerogeek
Please do let us know your system, compiler and other stuff so we can
give any intelligent reply.. without it its like shooting in the
air... :)
Eli Osherovich
Oooops, I thought everyone has switched to Linux :)
It is linux with gfortran and ifort.
Thank you.
Paul van Delst
You might want to take a look at "ruby make", or rake.
http://rake.rubyforge.org/
You'll need to learn a bit of ruby to write rakefiles, but (in my opinion) that's a
feature. :o)
The documentation at http://docs.rubyrake.org/ show how to use rakefiles for building
external programs via compilation (the example is for a C "hello world" program, but same
dog, different leg for Fortran)
If you're a gui/java fan, the Fortran plugin for Eclipse, Photran,
http://www.eclipse.org/photran
might be something you'd find useful (I'm a command line guy myself.)
cheers,
paulv
Craig Powers
I haven't used it myself, but another option might be TCBuild:
http://www.macresearch.org/tcbuild-new-build-tool-fortran
I had dependency issues that precluded being able to give it a test run.
Leclerc
I recomend CMake:
In the company I work for, we use Cmake to manage compilation process of
quite large SW system on linux, Solaris (sparc and X86), and Win32.
Sources are somposed of Fortran sources, C++ sources, couple of XSD
schemas (compiled into c++ using xsd), and CORBA IDL files (compiled
using OmniORB).
Needles to say, we had very little problems with managing this, using CMake.
cheers,
Gordan
andy2O
I've used "MakeMake" to make a Makefile for some medium sized Fortran
(77 & 90) projects with good success. It generates a Makefile from a
directory of source files which you use in the normal way. It coped
with the admittedly basic dependencies in my code without problem, and
was fantastically easy to use (basically just one line at the command
prompt). I think it's the version available at
http://www.fortran.com/makemake.perl
but there's some evidence on Google of other sources and I can't
remember where I got it from - I'll check tomorrow. So, I'm sure it's
not the most advanced system, but if it works and is as easy as it was
for me I think you'll be happy.
Regards,
andy
Arjen Markus
In the PLplot project (http://plplot.sf.net) we switched from autoconf
to CMake
a couple of years ago and that has been a very good decision. The
PLplot project
supports a multitude of programming languages and platforms, and
relies
on quite a few external libraries. CMake has made life a lot easier to
manage
all this complexity.
That is not to say that it is ideal: it has its flaws and you need to
jump through
hoops sometimes, but it does the job.
Minf you: it is a way to _generate_ Makefiles or project files or
solutions or
whatever the compiler tools want to call them. The advantage is that
you can
specify in detail what libraries to pull in, how to find them on the
target
system etc, but you can also rely on the defaults it provides.
Regards,
Arjen
Eli Osherovich
Meanwhile, I tried TCBuild and SCons.
This is VERY preliminary results as I had no time to learn the tools.
First, writing TCBuild file is about as lengthy as writing a makefile.
The second drawback of the tool that it tries to recompile EVERY
fortran and C file in your directory. This approach is probably good
for a project that must be built and shipped. However, in my situation
most of the files don't even compile. I would be much happier if it
were rebuilding only what is needed for the executable you specifies
in the build file.
SCons ignored completely dependencies, i.e., if you USEd a modmod
module in your source it did not try to compile the file with MODMOD
module. However, this is probably doable, since there is a parser that
detects USE and INCLUDE statements, but I have to find out how to make
it working.
I will try CMake and MakeMake later.
Thanks again.
Bob Beaty
easiest system, it's not the most feature-rich, but I'll tell you this
- it'll run on almost any platform there is. For that reason, I think
it's a good choice.
Do you really want your build system to be something you need to think
about? I just want it to be a toaster - put in the bread, get the
toast. Just work.
--
Thanks,
Bob
Ian Harvey
make it fortran 90/95/2003 aware (parsing of USE statements to build the
dependency tree, ignoring INTRINSIC modules). Once set-up it works
quite nicely and is easy to extend, but it might be overkill for first
steps.
Make (and makefiles) persists because of the large body of existing
code, not because it makes a great build system (the tab versus space
thing is lunacy).
Richard Maine
> Do you really want your build system to be something you need to think
> about? I just want it to be a toaster - put in the bread, get the
> toast. Just work.
You obviously haven't seen some of the toaster "incidents" that I have.
:-(
Starting from "The timer went off and the bread popped up not even
warmed; wonder if the heater element stopped working?", going on through
"I'm not about to eat that; I wonder if the dogs will?", and culminating
with "Glad someone was in the kitchen when that happened."
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
Ron Shepard
Ian Harvey <ian_h...@bigpond.com> wrote:
> Make (and makefiles) persists because of the large body of existing
> code, not because it makes a great build system (the tab versus space
> thing is lunacy).
I agree about the practical advantages of using make and makefiles. I
also agree about its obvious shortcomings, most of which were obvious 25
or 30 years ago, have not yet been fixed, and probably will never be
fixed.
Among those shortcomings I would include the needless space/tab syntax
quirks, the lack of a simple conditional syntax (if-then-else
statements, select case statements, etc.), and the lack of a standard
include capability to allow nesting and sharing of information between
makefiles in a portable manner. Some of the specific versions of make
(e.g. recent versions of GNU make) address some of these issues, but
they should have been addressed in a standard (e.g. POSIX) portable way
decades ago.
Despite these aggravating faults, make is the best answer for most of my
needs, and I expect to continue to use it for years to come.
$.02 -Ron Shepard
Paul van Delst
Ron Shepard wrote:
> In article <BQdmn.12479$pv.1...@news-server.bigpond.net.au>,
> Ian Harvey <ian_h...@bigpond.com> wrote:
>
>> Make (and makefiles) persists because of the large body of existing
>> code, not because it makes a great build system (the tab versus space
>> thing is lunacy).
>
> I agree about the practical advantages of using make and makefiles. I
> also agree about its obvious shortcomings, most of which were obvious 25
> or 30 years ago, have not yet been fixed, and probably will never be
> fixed.
>
> Among those shortcomings I would include the needless space/tab syntax
> quirks, the lack of a simple conditional syntax (if-then-else
> statements, select case statements, etc.),
Well, you *can* use bash case or if-then-else stuff in your makefiles, e.g.
all:
@echo "OS type detected: "`uname -s`
@case `uname -s` in \
"SunOS") make -f $(MAKE_FILE) build $(SUNOS_FLAGS) ;; \
"AIX") make -f $(MAKE_FILE) build $(AIX_FLAGS) ;; \
"IRIX64") make -f $(MAKE_FILE) build $(IRIX64_FLAGS) ;; \
"HP-UX") make -f $(MAKE_FILE) build $(HPUX_FLAGS) ;; \
"Linux"|"Darwin") make -f $(MAKE_FILE) build $(LINUX_FLAGS) ;; \
*) echo "This system is not supported" ;; \
esac
install:
@if [ -d $(HOME)/bin ]; then \
$(MOVE) $(EXE_FILE) $(HOME)/bin; \
fi
but you have to be careful to basically make the commands all one line (the reason for all
the "\" characters) so you don't start a new shell.
One more quirk to deal with I guess..... :o)
> and the lack of a standard
> include capability to allow nesting and sharing of information between
> makefiles in a portable manner.
?
But this capability is available. My makefiles all contain stuff like:
# Define macros
include $(CRTM_SOURCE_ROOT)/make.macros
# Define common make targets (all, build, clean, install)
include $(CRTM_SOURCE_ROOT)/make.common_targets
# Source dependency lists
include make.dependencies
# Define default rules
include $(CRTM_SOURCE_ROOT)/make.rules
As you can see I have *one* copy of the make.macros, make.common_targets, and make.rules
include files that all my makefiles use. [The $(CRTM_SOURCE_ROOT) is an envar defining the
root of my current trunk, or branch, working copy checked out from our subversion server]
> Some of the specific versions of make
> (e.g. recent versions of GNU make) address some of these issues, but
> they should have been addressed in a standard (e.g. POSIX) portable way
> decades ago.
>
> Despite these aggravating faults, make is the best answer for most of my
> needs, and I expect to continue to use it for years to come.
Agreed. But one day I will switch to ruby make. One day.....
cheers,
paulv
Ron Shepard
Paul van Delst <paul.v...@noaa.gov> wrote:
> > and the lack of a standard
> > include capability to allow nesting and sharing of information between
> > makefiles in a portable manner.
>
> ?
>
> But this capability is available. My makefiles all contain stuff like:
>
> # Define macros
> include $(CRTM_SOURCE_ROOT)/make.macros
>
> # Define common make targets (all, build, clean, install)
> include $(CRTM_SOURCE_ROOT)/make.common_targets
>
> # Source dependency lists
> include make.dependencies
>
> # Define default rules
> include $(CRTM_SOURCE_ROOT)/make.rules
>
>
> As you can see I have *one* copy of the make.macros, make.common_targets, and
> make.rules
> include files that all my makefiles use. [The $(CRTM_SOURCE_ROOT) is an envar
> defining the
> root of my current trunk, or branch, working copy checked out from our
> subversion server]
Yes, I do this too with GNU make, but it is not standard (e.g. it is
not part of POSIX make) and there are current versions of make that
do not support it. For versions of make that do not support
include, there are several work arounds. One is to use some kind of
preprocessor (e.g. m4 or filepp) that does support include to create
the concatenated makefiles. Another is to use multiple -f flags
when make is invoked from the shell.
make -f first_makefile -f second_makefile -f third_makefile
In practice, some or all of these are usually shell variables rather
than simple filenames. I've used all of these at one time or
another. But the simplest and most straightforward way to achieve
this would be for make itself to support nested include statements.
$.02 -Ron Shepard
Paul van Delst
> In article <hnc0us$i74$1...@news.boulder.noaa.gov>,
> Paul van Delst <paul.v...@noaa.gov> wrote:
>
>
> Yes, I do this too with GNU make, but it is not standard (e.g. it is
> not part of POSIX make) and there are current versions of make that
> do not support it.
Huh. I did not know that (might explain some strange requests for help from other users
though....)
Thanks,
paulv