Prev: year to Modified Julian day
Next: Cantera
From: bio_amateur on 6 Nov 2009 12:01
Can anyone tell me how to write a fortran source with directives and
use a preprocessor so that it can be compiled with different
compilers, e.g PGI and Intel fortran
Suppose that I have a source file in which contains the code that can
either use a fortran function that is defined differently in PGI
Fortran and Intel Fortran compiler.

I want to add some directives and know which preprocesors to use so
that when I call the makefile, depending on the compiler I defined in
FCC variable. the preprocessor can extract the correct version of the
code and give to the compiler.

I know this would be a long answer for you to help me. I couldnot find
any sources to know.

Thank you,
Tuan
GMU
From: Richard Maine on 6 Nov 2009 13:00
bio_amateur <hoangtrongminhtuan(a)gmail.com> wrote:

> Can anyone tell me how to write a fortran source with directives and
> use a preprocessor so that it can be compiled with different
> compilers, e.g PGI and Intel fortran

I was slightly amused by what seemed to me a discrepancy between the
subject line and the content of the question. To me, portable Fortran
code would be code that did not need different versions for different
compilers, while this is about how to deal with Fortran code that is not
portable.

I'll describe three broad approaches to this kind of thing.

1. There is the possibility of actually making the code portable, so
that it doesn't need such shenanigans. SInce you don't mention much in
the way of particulars, I can't tell how practical this would be. It
isn't always the best answer in the end, but I think it should normally
be the first option considered.

2. My usual recommendation for dealing with code that is nor portable
can be summarized in two words - isolate and document. I wont cover the
documentation part here, though it is an important one. The isolation
part seems pretty directly relevant to the question, though. Where
practical, I recommend isolating system-dependent things to small
portions of the program. Generally, this implies putting the system
dependence in a small, separate subroutine, which can have different
versions for different systems.

If you have isolated the system dependence to a subroutine (as opposed
to strewing it in-line all over the application), put that subroutine
(or a collection of simillarly system-dependent subroutines) in a
separate file as part of the isolation, and if you have made that
subroutine small and limitted to the system dependent matter, then it is
typically reasonable to have different files for the versions of the
subroutine for different systems. Then you have only to select the
apropriate file for the appropriate system/compiler.

3. Then there is the approach that you mention - of using preprocessors.
There are cases where this can be the best approach, but I recommend
seriously considering the other two approaches first. This is the
messiest and least portable one. I generally find it a lot harder to
assure portability for preprocessors and makefiles than for Fortran
code. That is particularly so if the application is to be used by other
people who might not have your particular favored collection of
utilities. For example, while plenty of Make utilities for Windows
exist, I can't assume that a random user of my applications would have
any particular Make utility installed unless it was one that came by
default with the compiler in question. Some of the users don't even have
the option of installing extra software utilities on their machines.

I use Makefiles for most of my target systems/compilers, but there have
been some cases where I didn't find that worked out well, so I just
broke down and wrote a short installation batch file to select and
compile the appropriate set of files for that compiler. If you have
isolated the system dependencies into separate files as I described
above, then doing such a batch file is easy and doesn't involve any
special utilities other than whatever batch file processor comes with
the system in question.

If you really are stuck with doing everything via preprocessors and
make... well, I don't have much in the way of specific recommendations
there. I'll leave that to others. I've done things like that, but I've
also run into difficulties with it and I prefer to avoid it. I have an
order of magnitude (or two) more preprocessing in my Makefile
customization than in my Fortran code, and there are still cases where
it isn't enough and I use the above-mentioned batch file approach
instead.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: feenberg on 7 Nov 2009 07:27
On Nov 6, 12:01 pm, bio_amateur <hoangtrongminht...(a)gmail.com> wrote:
> Can anyone tell me how to write a fortran source with directives and
> use a preprocessor so that it can be compiled with different
> compilers, e.g PGI and Intel fortran
> Suppose that I have a source file in which contains the code that can
> either use a fortran function that is defined differently in PGI
> Fortran and Intel Fortran compiler.
>
> I want to add some directives and know which preprocesors to use so
> that when I call the makefile, depending on the compiler I defined in
> FCC variable. the preprocessor can extract the correct version of the
> code and give to the compiler.
>
> I know this would be a long answer for you to help me. I couldnot find
> any sources to know.
>
> Thank you,
> Tuan
> GMU

Most of the readers of this group are probably thinking "If I knew
what he wanted to vary by compiler, I bet I could show him how to
write it in standard fortran, so conditional compilation wouldn't be
necessary". That may not be true, but you might as well tell us what
stands in your way to achieve a standard-conforming program.

Daniel Feenberg
From: Terence on 7 Nov 2009 17:53
On Nov 7, 5:00 am, nos...(a)see.signature (Richard Maine) wrote:
> bio_amateur <hoangtrongminht...(a)gmail.com> wrote:
> > Can anyone tell me how to write a fortran source with directives and
> > use a preprocessor so that it can be compiled with different
> > compilers, e.g PGI and Intel fortran
>
> I was slightly amused by what seemed to me a discrepancy between the
> subject line and the content of the question. To me, portable Fortran
> code would be code that did not need different versions for different
> compilers, while this is about how to deal with Fortran code that is not
> portable.
>
> I'll describe three broad approaches to this kind of thing.
>
> 1. There is the possibility of actually making the code portable, so
> that it doesn't need such shenanigans. SInce you don't mention much in
> the way of particulars, I can't tell how practical this would be. It
> isn't always the best answer in the end, but I think it should normally
> be the first option considered.
>
> 2. My usual recommendation for dealing with code that is nor portable
> can be summarized in two words - isolate and document. I wont cover the
> documentation part here, though it is an important one. The isolation
> part seems pretty directly relevant to the question, though. Where
> practical, I recommend isolating system-dependent things to small
> portions of the program. Generally, this implies putting the system
> dependence in a small, separate subroutine, which can have different
> versions for different systems.
>
> If you have isolated the system dependence to a subroutine (as opposed
> to strewing it in-line all over the application), put that subroutine
> (or a collection of simillarly system-dependent subroutines) in a
> separate file as part of the isolation, and if you have made that
> subroutine small and limitted to the system dependent matter, then it is
> typically reasonable to have different files for the versions of the
> subroutine for different systems. Then you have only to select the
> apropriate file for the appropriate system/compiler.
>
> 3. Then there is the approach that you mention - of using preprocessors.
> There are cases where this can be the best approach, but I recommend
> seriously considering the other two approaches first. This is the
> messiest and least portable one. I generally find it a lot harder to
> assure portability for preprocessors and makefiles than for Fortran
> code. That is particularly so if the application is to be used by other
> people who might not have your particular favored collection of
> utilities. For example, while plenty of Make utilities for Windows
> exist, I can't assume that a random user of my applications would have
> any particular Make utility installed unless it was one that came by
> default with the compiler in question. Some of the users don't even have
> the option of installing extra software utilities on their machines.
>
> I use Makefiles for most of my target systems/compilers, but there have
> been some cases where I didn't find that worked out well, so I just
> broke down and wrote a short installation batch file to select and
> compile the appropriate set of files for that compiler. If you have
> isolated the system dependencies into separate files as I described
> above, then doing such a batch file is easy and doesn't involve any
> special utilities other than whatever batch file processor comes with
> the system in question.
>
> If you really are stuck with doing everything via preprocessors and
> make... well, I don't have much in the way of specific recommendations
> there. I'll leave that to others. I've done things like that, but I've
> also run into difficulties with it and I prefer to avoid it. I have an
> order of magnitude (or two) more preprocessing in my Makefile
> customization than in my Fortran code, and there are still cases where
> it isn't enough and I use the above-mentioned batch file approach
> instead.
>
> --
> Richard Maine                    | Good judgment comes from experience;
> email: last name at domain . net | experience comes from bad judgment.
> domain: summertriangle           |  -- Mark Twain

Good advice in Richard's response.
To quote an example of the problem, I have one set of about 70 F77
programs which call certain system-dependent routines, aminly for
screen control and file name enquiries.

I adopted the same methods as Richard suggests; in my case all
routines have the same name, but those which are system dependent are
pre-compiled and resulting modules stored in linkable libraries, each
one for the target systems for compiling or executing.

For example, I compile and eventually run in DOS, MSDOS emulation in
Windows and Macintosh, and native MS Windows modes.
The main source code of each program is the same (and makes upkeep
simple); the system-dependent subroutines, although called by the same
name may themselves call DOS service or Windows API's (and usuall need
no upkeep).
 | 
Pages: 1
Prev: year to Modified Julian day
Next: Cantera