Prev: PGI Visual Fortran 2008 v10.3 with VS2008 Shell for Windows x86/x64
Next: Existence of a file
From: Ian Harvey on 11 Mar 2010 17:07
We use jam, with a customisation of the base build ruleset (jambase) to
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).

On 11/03/2010 3:06 AM, Eli Osherovich wrote:
> I am playing with Fortran which is new for me.
> 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.

From: Richard Maine on 11 Mar 2010 17:40
Bob Beaty <drbob(a)TheManFromSPUD.com> wrote:

> 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
From: Ron Shepard on 11 Mar 2010 18:14
In article <BQdmn.12479$pv.11852(a)news-server.bigpond.net.au>,
Ian Harvey <ian_harvey(a)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
From: Paul van Delst on 11 Mar 2010 19:13


Ron Shepard wrote:
> In article <BQdmn.12479$pv.11852(a)news-server.bigpond.net.au>,
> Ian Harvey <ian_harvey(a)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
From: Ron Shepard on 12 Mar 2010 02:39
In article <hnc0us$i74$1(a)news.boulder.noaa.gov>,
Paul van Delst <paul.vandelst(a)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
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: PGI Visual Fortran 2008 v10.3 with VS2008 Shell for Windows x86/x64
Next: Existence of a file