I'm trying to write three shell scripts, which determine if the 
C/C++/Fortran compilers are GNU, Sun, IBM. HP etc.

The code below is makes use of the C pre-processor and checks for what 
macros are defined. Can anyone give me a clue how I might do similar in 
Fortran?

drkirkby@swan:[~] $ cat testcc
#!/usr/bin/sh
# Determine the type of C compiler, which can later
# be used to determine the flags the compiler
# will want. Do this by defining pre-processing a bit
# of C code, and checking what are defined.

# The Sun and GNU compilers have been tested.

# The HP and GNU compilers have not been tested, but
# use information gained from the documentation.

# HP-UX C and C++ compiler.
# http://docs.hp.com/en/7730/newhelp0610/preprocess.htm

# IBM Compiler Reference - XL C/C++ for AIX, V10.1
# http://www-01.ibm.com/support/docview.wss?uid=swg27012860&aid=1

# Using HP C++ for Tru64 UNIX and Linux Alpha
# http://h30097.www3.hp.com/cplus/ugu_impl.html#implem_chap


# First, make sure the enviroment variable CC is defined.

if [ -z "$CC" ]; then
    echo "Sorry, you should define the enivronment variable CC"
    exit 1
fi

# Create a test file. It does not need to be a complete
# C++ file, as it is only pre-processed. So there is no
# need for a 'main'

TESTFILE=/tmp/test.$$.c

# The flags for the GNU compilers do not change with
# operating system, so there is no need to worry too
# much about what system this is on.

echo "#ifdef __GNUC__"                   > $TESTFILE
echo "it_is_the_GNU_compiler"            >> $TESTFILE
echo "#endif"                            >> $TESTFILE

echo "#ifdef __SUNPRO_C"                 >> $TESTFILE
echo "it_is_the_Sun_compiler"            >> $TESTFILE
echo "#endif"                            >> $TESTFILE

# Not found any offical documention to suggest __DECC
# would be defined, but __DECCC is defined for C++,
# and a Google on __DECC shows many hits.
echo "#ifdef __digital__"                >> $TESTFILE
echo "#ifdef __DECC"                     >> $TESTFILE
echo "it_is_the_HP_Tru64_compiler"       >> $TESTFILE
echo "#endif"                            >> $TESTFILE
echo "#endif"                            >> $TESTFILE

echo "#ifdef __linux__"                  >> $TESTFILE
echo "#ifdef __DECCC"                   >> $TESTFILE
echo "it_is_the_HP_Alpha_Linux_compiler" >> $TESTFILE
echo "#endif"                            >> $TESTFILE
echo "#endif"                            >> $TESTFILE

echo "#ifdef __HP_aCC"                   >> $TESTFILE
echo "it_is_the_HP_HPUX_compiler"        >> $TESTFILE
echo "#endif"                            >> $TESTFILE

echo "#ifdef __xlC__"                    >> $TESTFILE
echo "it_is_the_IBM_AIX_compiler"        >> $TESTFILE
echo "#endif"                            >> $TESTFILE

${CC} -E $TESTFILE | grep it_is_the_GNU_compiler  >/dev/null 2>&1
if [ $? = 0 ]; then
    echo GNU
    rm $TESTFILE
    exit 0
fi

${CC} -E $TESTFILE | grep it_is_the_Sun_compiler  >/dev/null 2>&1
if [ $? = 0 ]; then
    echo Sun_on_Solaris
    rm $TESTFILE
    exit 0
fi

# HP make compilers for linux, HP-UX and tru64, which complicates matters.

${CC} -E $TESTFILE | grep it_is_the_HP_Tru64_compiler >/dev/null 2>&1
if [ $? = 0 ]; then
    echo HP_on_Tru64
    rm $TESTFILE
    exit 0
fi

${CC} -E $TESTFILE | grep it_is_the_HP_Alpha_Linux_compiler >/dev/null 2>&1
if [ $? = 0 ]; then
    echo HP_on_Alpha_Linux
    rm $TESTFILE
    exit 0
fi

${CC} -E $TESTFILE | grep it_is_the_HP_HPUX_compiler >/dev/null 2>&1
if [ $? = 0 ]; then
    echo HP_on_HPUX
    rm $TESTFILE
    exit 0
fi

${CC} -E $TESTFILE | grep it_is_the_IBM_AIX_compiler >/dev/null 2>&1
if [ $? = 0 ]; then
    echo IBM_on_AIX
    rm $TESTFILE
    exit 0
fi

# Exit saying 'Unknown' if the type of the compiler could not be found.
echo Unknown
rm $TESTFILE
exit 0


-- 
I respectfully request that this message is not archived by companies as
unscrupulous as 'Experts Exchange' . In case you are unaware,
'Experts Exchange'  take questions posted on the web and try to find
idiots stupid enough to pay for the answers, which were posted freely
by others. They are leeches.

Dave wrote:
> I'm trying to write three shell scripts, which determine if the 
> C/C++/Fortran compilers are GNU, Sun, IBM. HP etc.
> 
> The code below is makes use of the C pre-processor and checks for what 
> macros are defined. Can anyone give me a clue how I might do similar in 
> Fortran?
> 

Compilers which support OpenMP will support cpp style #ifdef 
pre-processing.  This is not covered by Fortran standard.
You must look up pre-defined macros in the documentation of each 
compiler, or test them, to see how they refer to themselves.

Tim Prince wrote:
> Dave wrote:
>> I'm trying to write three shell scripts, which determine if the 
>> C/C++/Fortran compilers are GNU, Sun, IBM. HP etc.
>>
>> The code below is makes use of the C pre-processor and checks for what 
>> macros are defined. Can anyone give me a clue how I might do similar 
>> in Fortran?
>>
> 
> Compilers which support OpenMP will support cpp style #ifdef 
> pre-processing.  This is not covered by Fortran standard.
> You must look up pre-defined macros in the documentation of each 
> compiler, or test them, to see how they refer to themselves.

Thank you. Would supporting OpenMP have been the normal 5 or so years 
ago? Is it now?

Is there any way to find out if the compiler does support OpenMP? 
Obviously if I can be sure the compiler supports it, then I can test it 
that way.

-- 
I respectfully request that this message is not archived by companies as
unscrupulous as 'Experts Exchange' . In case you are unaware,
'Experts Exchange'  take questions posted on the web and try to find
idiots stupid enough to pay for the answers, which were posted freely
by others. They are leeches.

Dave wrote:
> Tim Prince wrote:
>> Compilers which support OpenMP will support cpp style #ifdef 
>> pre-processing. 
> 
> Is there any way to find out if the compiler does support OpenMP? 
> Obviously if I can be sure the compiler supports it, then I can test it 
> that way.

I don't believe Tim's statement is correct.  OpenMP has its own 
conditional compilation syntax which is not cpp-style and is more 
restrictive.  Support of OpenMP does not, as far as I know, imply 
support of cpp-style conditional compilation.

Now it is true that many current Fortran compilers do support cpp-style 
directives - you may need to use a switch or name the file with an 
uppercase file type (F or F90).  I recommend reading your compiler's 
documentation to see what it supports and how to enable it.

-- 
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH

For email address, replace "invalid" with "com"

User communities for Intel Software Development Products
   http://software.intel.com/en-us/forums/
Intel Software Development Products Support
   http://software.intel.com/sites/support/
My Fortran blog
   http://www.intel.com/software/drfortran

Steve Lionel wrote:
> Dave wrote:
>> Tim Prince wrote:
>>> Compilers which support OpenMP will support cpp style #ifdef 
>>> pre-processing. 
>>
>> Is there any way to find out if the compiler does support OpenMP? 
>> Obviously if I can be sure the compiler supports it, then I can test 
>> it that way.
> 
> I don't believe Tim's statement is correct.  OpenMP has its own 
> conditional compilation syntax which is not cpp-style and is more 
> restrictive.  Support of OpenMP does not, as far as I know, imply 
> support of cpp-style conditional compilation.
> 
> Now it is true that many current Fortran compilers do support cpp-style 
> directives - you may need to use a switch or name the file with an 
> uppercase file type (F or F90).  I recommend reading your compiler's 
> documentation to see what it supports and how to enable it.
> 
Thank you.

The problem is I'm trying to write a script which will sort out what the 
compiler is, so I don't know in advance what flags the compiler may or 
may not accept.

The basic problem I have is this. Perhaps you can might have a 
suggestion on how best to resolve it.

I work on the open-source Sage maths project

http://www.sagemath.org/

which consists of a large number (around 100) open-source programs 
distributed as one huge tarball (around 205 MB compressed). Many of the 
programs have hard-coded flags like -fPIC, -soname which are GNU flags, 
but are not recognised by non-GNU compilers or linkers.

Sage will build on Solaris with gcc/g++/gfortran, but I've identified 
about 40 reasons the code will not build with Sun's Studio compiler's 
suite.

http://sagetrac.org/sage_trac/ticket/7056

Many are the result of using GNU-specific flags. My aim is to replace 
flags like -fPIC with a variable which can be set in advance, so the 
code compiles and links on other platforms with other compilers. The 
world does not start and end with GNU tools, though many software 
developers acts as though it does.

To make the code work with non-GNU compilers, I need to know what flags 
are needed on that platform. To do that, I need to know what compilers 
are in use. For C and C++ I'm doing that by use of the pre-processor.

Any suggestions you have for how I might do that with Fortran are welcome.


-- 
I respectfully request that this message is not archived by companies as
unscrupulous as 'Experts Exchange' . In case you are unaware,
'Experts Exchange'  take questions posted on the web and try to find
idiots stupid enough to pay for the answers, which were posted freely
by others. They are leeches.

Dave <foo@coo.com> wrote:
(snip)
 
< The problem is I'm trying to write a script which will sort out what the 
< compiler is, so I don't know in advance what flags the compiler may or 
< may not accept.
 
< The basic problem I have is this. Perhaps you can might have a 
< suggestion on how best to resolve it.
 
(snip)
 
< To make the code work with non-GNU compilers, I need to know what flags 
< are needed on that platform. To do that, I need to know what compilers 
< are in use. For C and C++ I'm doing that by use of the pre-processor.

As OpenMP has some connection to C, and it is certainly likely that 
all implementations support the cpp preprocessor.  As others have said,
OpenMP doesn't require that, but it may still be true.  It seems
likely that a C compiler is available along with cpp, and might
be reasonable for you to require its use with your programs.
 
< Any suggestions you have for how I might do that with Fortran 
< are welcome.

-- glen

Dave wrote:
> 
> Steve Lionel wrote:
> > Dave wrote:
> >> Tim Prince wrote:
> >>> Compilers which support OpenMP will support cpp style #ifdef
> >>> pre-processing.
> >>
> >> Is there any way to find out if the compiler does support OpenMP?
> >> Obviously if I can be sure the compiler supports it, then I can test
> >> it that way.
> >
> > I don't believe Tim's statement is correct.  OpenMP has its own
> > conditional compilation syntax which is not cpp-style and is more
> > restrictive.  Support of OpenMP does not, as far as I know, imply
> > support of cpp-style conditional compilation.
> >
> > Now it is true that many current Fortran compilers do support cpp-style
> > directives - you may need to use a switch or name the file with an
> > uppercase file type (F or F90).  I recommend reading your compiler's
> > documentation to see what it supports and how to enable it.
> >
> Thank you.
> 
> The problem is I'm trying to write a script which will sort out what the
> compiler is, so I don't know in advance what flags the compiler may or
> may not accept.
> 
> The basic problem I have is this. Perhaps you can might have a
> suggestion on how best to resolve it.
> 
> I work on the open-source Sage maths project
> 
> http://www.sagemath.org/
> 
> which consists of a large number (around 100) open-source programs
> distributed as one huge tarball (around 205 MB compressed). Many of the
> programs have hard-coded flags like -fPIC, -soname which are GNU flags,
> but are not recognised by non-GNU compilers or linkers.
> 
> Sage will build on Solaris with gcc/g++/gfortran, but I've identified
> about 40 reasons the code will not build with Sun's Studio compiler's
> suite.
> 
> http://sagetrac.org/sage_trac/ticket/7056
> 
> Many are the result of using GNU-specific flags. My aim is to replace
> flags like -fPIC with a variable which can be set in advance, so the
> code compiles and links on other platforms with other compilers. The
> world does not start and end with GNU tools, though many software
> developers acts as though it does.
> 
> To make the code work with non-GNU compilers, I need to know what flags
> are needed on that platform. To do that, I need to know what compilers
> are in use. For C and C++ I'm doing that by use of the pre-processor.
> 
> Any suggestions you have for how I might do that with Fortran are welcome.

Let's look at the main objective.  From your original C example, it
seems that you want to start with an arbitrary command name for a
Fortran compiler, ignore any meaning of the literal spelling of the
command itself, and identify the compiler based on its behavior.  Right?

For reasons I do not understand or wish to, it seems that use of
preprocessors evolved as the favored method of testing identification of
C compilers.  Now the few fortran compilers in my experience do a good
job identifying themselves directly with command switches like -V or
--version.  No test program is involved.

However, by this direct method, compare strings must be built directly
into the invoking shell script.  I do not see this as a problem.  An
added advantage is that you also get a nice version number on your
platter, for when it might matter.

So why not use this much more straightforward method for compiler
identification, and skip the preprocessor gyrations?

--Dave

glen herrmannsfeldt wrote:
> Dave <foo@coo.com> wrote:
> (snip)
>  
> < The problem is I'm trying to write a script which will sort out what the 
> < compiler is, so I don't know in advance what flags the compiler may or 
> < may not accept.
>  
> < The basic problem I have is this. Perhaps you can might have a 
> < suggestion on how best to resolve it.
>  
> (snip)
>  
> < To make the code work with non-GNU compilers, I need to know what flags 
> < are needed on that platform. To do that, I need to know what compilers 
> < are in use. For C and C++ I'm doing that by use of the pre-processor.
> 
> As OpenMP has some connection to C, and it is certainly likely that 
> all implementations support the cpp preprocessor.  As others have said,
> OpenMP doesn't require that, but it may still be true.  It seems
> likely that a C compiler is available along with cpp, and might
> be reasonable for you to require its use with your programs.
>  
>
(Following up on digression)  My OpenMP references state a specific 
requirement to support #ifdef _OPENMP for conditional inclusion of 
OpenMP function calls and the like.  Perhaps I read too much into that. 
This is not to say that no non-OpenMP compilers support some cpp-style 
pre-processing.  For example, one would expect gfortran to include 
"tradcpp" on all platforms, even in versions which predate their support 
of OpenMP.

If you gcc can be installed on all relevant platforms, for example, you 
could use gcc as the C pre-processor (gfortran -E or gcc -E -traditional 
-x C) for all Fortran compilers.  This doesn't meet what I read as in 
original requirement of seeing the pre-processor defines of the 
individual Fortran compilers.  It might make gcc-help more relevant on 
the question of distinguishing platforms.
I guess OP doesn't think anyone understood the original request, as it 
has been repeated without clarification, except for the modification 
that linker flags seem to be more important than stated originally. 
Thus, it is necessary to distinguish Sun f95 on Solaris from Sun f95 on 
linux, or ifort on Windows from ifort on linux, for example. The same 
(linux) compiler might be used on some versions of BSD, in which case 
the compiler's own flags don't answer the question. This makes the 
question nearly impossible to answer as a purely Fortran question.

I'm getting the impression that old versions of some of the compilers 
must be envisioned.  Did someone miss the acquisition of Sun by Oracle 
and announcement of a further 50% cut in Sun personnel?

On Oct 3, 10:43=A0pm, Dave <f...@coo.com> wrote:

> # The flags for the GNU compilers do not change with
> # operating system, so there is no need to worry too
> # much about what system this is on.
>
> echo "#ifdef __GNUC__" =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > $TESTFILE
> echo "it_is_the_GNU_compiler" =A0 =A0 =A0 =A0 =A0 =A0>> $TESTFILE
> echo "#endif" =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>> $=
TESTFILE

FWIW, this doesn't work. Various popular compilers (including Intel C
and Open64) define __GNUC__ also, even though they are not GNU C.

If you use gfortran, the C preprocessor commands work (see
documentation for how) and gfortran defines __GFORTRAN__.

Ciao!
Steven

In article <4ac842bf@212.67.96.135>, Dave <foo@coo.com> wrote:

> The problem is I'm trying to write a script which will sort out what the 
> compiler is, so I don't know in advance what flags the compiler may or 
> may not accept.

I don't understand exactly what the problem is.  Perhaps you have 
experience with C compilers and think you need to do the same thing to 
fortran compilers.  In my experience, you don't.

All (or at least most) C compilers are invoked with the "cc" command.  
Thus to determine which compiler you are using for conditional 
compilation, different compilers define different macros, which can then 
be used to trigger conditional compilation and so on.  But fortran 
compilers are not like that.  Each fortran compiler typically has its 
own name.  Some common names are gfortran, g95, f95, fort, ifort, pfg90, 
and xlf90, just to name a few.  Thus with fortran, you know ahead of 
time which compiler you are using, and the problem then is to set 
appropriate macros in order to invoke the appropriate conditional 
compilation.

I'm not sure which approach is best, the C way or the fortran way.  They 
both have advantages and disadvantages.  Things that are explicit one 
way are implicit the other way.

But, as I say above, I don't understand exactly what your problem is, so 
maybe all this is all off on some irrelevant tangent.

$.02 -Ron Shepard

In article <haa5hq$7do$2@naig.caltech.edu>,
 glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> As OpenMP has some connection to C, and it is certainly likely that 
> all implementations support the cpp preprocessor.  As others have said,
> OpenMP doesn't require that, but it may still be true.

Every fortran compiler I've used in the past 25 years has supported the 
cpp preprocessor.  That includes about 20 compilers on a range of 
operating systems, most of them unix-like if not certified unix.  This 
cpp support predates, and is independent of, any OpenMP support.

$.02 -Ron Shepard

In article <ron-shepard-DB106F.22073804102009@news60.forteinc.com>,
Ron Shepard  <ron-shepard@NOSPAM.comcast.net> wrote:
>In article <haa5hq$7do$2@naig.caltech.edu>,
> glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
>
>> As OpenMP has some connection to C, and it is certainly likely that 
>> all implementations support the cpp preprocessor.  As others have said,
>> OpenMP doesn't require that, but it may still be true.
>
>Every fortran compiler I've used in the past 25 years has supported the 
>cpp preprocessor.  That includes about 20 compilers on a range of 
>operating systems, most of them unix-like if not certified unix.  This 
>cpp support predates, and is independent of, any OpenMP support.

Yes, it's almost ubiquitous on Unix-derived systems, but is much
rarer on others.

A more serious problem is that cpp ceased to exist as a defined
entity some 15 years back, and its lexical analysis conflicted
with Fortran's, anyway.  Simple use works, but identifying what is
simple is very complicated.


Regards,
Nick Maclaren.

On Oct 3, 1:43=A0pm, Dave <f...@coo.com> wrote:
> I'm trying to write three shell scripts, which determine if the
> C/C++/Fortran compilers are GNU, Sun, IBM. HP etc.
>...

For what it's worth, there is an ISO standard preprocessor for Fortran
(ISO/IEC 1539-3:1998) though it's overwhelmingly less common than cpp
(the Pathscale compiler does provide it, and there's a Fortran-coded
implementation at http://users.erols.com/dnagle/coco.html) but it
doesn't predefine any macros. As to your original question, I second
the suggestion from Dave Allured that you run the compiler with
various switches like --version, -V, -v, etc and test whether it
responds with "I don't recognize that switch" or with a string giving
its name and version. A Fortran compiler which provides cpp may just
"borrow" the one provided for C, and may (deliberately or
inadvertently) leave defined whatever macros that implementation of
cpp sets up by default. Thus a non-GNU Fortran compiler's cpp may
define __GNUC__ either because the C compiler sold as a companion to
the Fortran compiler promises to be compatible with GNU C, or because
the Fortran compiler obtains the functionality of cpp by running the
GNU implementation of cpp. In any case, the string generated by --
version etc is apt to be more reliable.

stevenb wrote:
> On Oct 3, 10:43 pm, Dave <f...@coo.com> wrote:
> 
>> # The flags for the GNU compilers do not change with
>> # operating system, so there is no need to worry too
>> # much about what system this is on.
>>
>> echo "#ifdef __GNUC__"                   > $TESTFILE
>> echo "it_is_the_GNU_compiler"            >> $TESTFILE
>> echo "#endif"                            >> $TESTFILE
> 
> FWIW, this doesn't work. Various popular compilers (including Intel C
> and Open64) define __GNUC__ also, even though they are not GNU C.


I assume in this case, the Intel compiler will take the same options as 
the GNU compiler, if its trying to be a clone of it. So perhaps:

'it is the GNU_compiler_or_clone'

might be better.


> If you use gfortran, the C preprocessor commands work (see
> documentation for how) and gfortran defines __GFORTRAN__.
> 
> Ciao!
> Steven


-- 
I respectfully request that this message is not archived by companies as
unscrupulous as 'Experts Exchange' . In case you are unaware,
'Experts Exchange'  take questions posted on the web and try to find
idiots stupid enough to pay for the answers, which were posted freely
by others. They are leeches.

Ron Shepard wrote:
> In article <4ac842bf@212.67.96.135>, Dave <foo@coo.com> wrote:
> 
>> The problem is I'm trying to write a script which will sort out what the 
>> compiler is, so I don't know in advance what flags the compiler may or 
>> may not accept.
> 
> I don't understand exactly what the problem is.  Perhaps you have 
> experience with C compilers and think you need to do the same thing to 
> fortran compilers.  In my experience, you don't.
> 
> All (or at least most) C compilers are invoked with the "cc" command.  
> Thus to determine which compiler you are using for conditional 
> compilation, different compilers define different macros, which can then 
> be used to trigger conditional compilation and so on.  But fortran 
> compilers are not like that.  

I believe on AIX, the C compilers go under different names, xlC being 
one of htem. Clearly gcc is another name, though that is an easy case.

> Each fortran compiler typically has its 
> own name.  Some common names are gfortran, g95, f95, fort, ifort, pfg90, 
> and xlf90, just to name a few.  Thus with fortran, you know ahead of 
> time which compiler you are using, and the problem then is to set 
> appropriate macros in order to invoke the appropriate conditional 
> compilation.

But its quite common to see gfortran linked to f77 and friends, so 
knowing its f77 does not really help.

> I'm not sure which approach is best, the C way or the fortran way.  They 
> both have advantages and disadvantages.  Things that are explicit one 
> way are implicit the other way.
> 
> But, as I say above, I don't understand exactly what your problem is, so 
> maybe all this is all off on some irrelevant tangent.
> 
> $.02 -Ron Shepard




-- 
I respectfully request that this message is not archived by companies as
unscrupulous as 'Experts Exchange' . In case you are unaware,
'Experts Exchange'  take questions posted on the web and try to find
idiots stupid enough to pay for the answers, which were posted freely
by others. They are leeches.

nmm1@cam.ac.uk wrote:
> In article <ron-shepard-DB106F.22073804102009@news60.forteinc.com>,
> Ron Shepard  <ron-shepard@NOSPAM.comcast.net> wrote:
>> In article <haa5hq$7do$2@naig.caltech.edu>,
>> glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
>>
>>> As OpenMP has some connection to C, and it is certainly likely that 
>>> all implementations support the cpp preprocessor.  As others have said,
>>> OpenMP doesn't require that, but it may still be true.
>> Every fortran compiler I've used in the past 25 years has supported the 
>> cpp preprocessor.  That includes about 20 compilers on a range of 
>> operating systems, most of them unix-like if not certified unix.  This 
>> cpp support predates, and is independent of, any OpenMP support.
> 
> Yes, it's almost ubiquitous on Unix-derived systems, but is much
> rarer on others.

I'm only interested in Unix or Unix-like systems. There is a native 
Windows port of Sage in progress (sponsored my Microsoft I believe), but 
I'm not involved with that. I think the people working on that will need 
to have some very different code.

> A more serious problem is that cpp ceased to exist as a defined
> entity some 15 years back, and its lexical analysis conflicted
> with Fortran's, anyway.  Simple use works, but identifying what is
> simple is very complicated.


Since I do not know Fortran, could you give me a sample bit of Fortran 
which would make use of the C-preprocessor type things like I showed. 
Would my code need any changes at all, or would I simply create a file 
like I showed before, change the extension to .f and use it?


> Regards,
> Nick Maclaren.


-- 
I respectfully request that this message is not archived by companies as
unscrupulous as 'Experts Exchange' . In case you are unaware,
'Experts Exchange'  take questions posted on the web and try to find
idiots stupid enough to pay for the answers, which were posted freely
by others. They are leeches.

Dave Allured wrote:

>> Many are the result of using GNU-specific flags. My aim is to replace
>> flags like -fPIC with a variable which can be set in advance, so the
>> code compiles and links on other platforms with other compilers. The
>> world does not start and end with GNU tools, though many software
>> developers acts as though it does.
>>
>> To make the code work with non-GNU compilers, I need to know what flags
>> are needed on that platform. To do that, I need to know what compilers
>> are in use. For C and C++ I'm doing that by use of the pre-processor.
>>
>> Any suggestions you have for how I might do that with Fortran are welcome.
> 
> Let's look at the main objective.  From your original C example, it
> seems that you want to start with an arbitrary command name for a
> Fortran compiler, ignore any meaning of the literal spelling of the
> command itself, and identify the compiler based on its behavior.  Right?

Yes, basically. At one point, I thought a grep on the output of '

$somecompiler --version

would show GNU or GCC if it was a GNU compiler, but that is not true.

On Ubuntu, 'gcc --version' will output 'gcc' but not GCC or GNU. But if 
invoked by the name 'cc', it is clearly the GNU compiler, but will not 
show GNU, GCC or gcc.

% cc --version
cc (Ubuntu 4.3.3-5ubuntu4) 4.3.3
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

So relying on the name of the command is not really helpful.

OK, I could add "Free Software Foundation" to the list of things I grep 
for, but it's anyones guess what information someone will output with 
the GNU compiler.

> For reasons I do not understand or wish to, it seems that use of
> preprocessors evolved as the favored method of testing identification of
> C compilers.  

It was suggested by a few on comp.unix.shell when I originally asked 
about this.

http://groups.google.co.uk/group/comp.unix.shell/browse_thread/thread/aa0dfac7c7aeb412/1d432f8b8bfc54a?hl=en&ie=UTF-8&q=How+can+I+tell+if+%27CC%27+is+the+GNU+C+compiler%3F#01d432f8b8bfc54a


The general opinion was that using the pre-processor is the most 
reliable and that relying on the use of -v, -V, --version and other 
similar things is not so useful.

I'm also aware the linker is an issue. I found when trying to build Sage 
on Solaris, it went ok if gcc used the GNU linker and assembler, but 
failed if gcc was configured to use Sun's linker and assembler. I've 
since sorted all those issues out. Though I wish I'd given more thought 
at the time to running on other platforms. There were specific reasons 
for wanting Solaris.

  * I own SPARC hardware myself
  * Sun are providing support for the project in terms of hardware. They 
donated a Sun T5240 (16 core box) to the Sage project. I do not use that 
machine much, as I have a Sun of my own at home.

> Now the few fortran compilers in my experience do a good
> job identifying themselves directly with command switches like -V or
> --version.  No test program is involved.

Sun's does not on Solaris. Neither -v or --version work. -V does I would 
admit.

> However, by this direct method, compare strings must be built directly
> into the invoking shell script.  I do not see this as a problem.  An
> added advantage is that you also get a nice version number on your
> platter, for when it might matter.

gcc and g++ will give you the version using the -dumpversion flag. 
gfortran will not. I have reported that as a bug against gfortran, and 
believe that will be fixed in the next release.

drkirkby@swan:[~] $ gcc -dumpversion
4.4.1
drkirkby@swan:[~] $ g++ -dumpversion
4.4.1
drkirkby@swan:[~] $ gfortran -dumpversion
GNU Fortran (GCC) 4.4.1
Copyright (C) 2009 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING

drkirkby@swan:[~] $

> So why not use this much more straightforward method for compiler
> identification, and skip the preprocessor gyrations?
> 
> --Dave

Well, when 'cc' outputs neither gcc, GNU, or GCC, but is still the GNU 
compiler, you can see doing this can be a bit tricky.

Dave
-- 
I respectfully request that this message is not archived by companies as
unscrupulous as 'Experts Exchange' . In case you are unaware,
'Experts Exchange'  take questions posted on the web and try to find
idiots stupid enough to pay for the answers, which were posted freely
by others. They are leeches.

Dave <foo@coo.com> wrote:
> I'm trying to write three shell scripts, which determine if the 
> C/C++/Fortran compilers are GNU, Sun, IBM. HP etc.
> 

Have you looked at autoconf
(http://www.gnu.org/software/autoconf/manual/html_node/index.html)?

-- 
Klaus Wacker              klaus.wacker@udo.edu
Experimentelle Physik V   http://www.physik.uni-dortmund.de/~wacker
TU Dortmund               Tel.: +49 231 755 3587
D-44221 Dortmund          Fax:  +49 231 755 4547

Dave wrote:
> I'm trying to write three shell scripts, which determine if the 
> C/C++/Fortran compilers are GNU, Sun, IBM. HP etc.

We use autoconf and M4 macros for this.

Lately, we've decided that checking for a specific compiler
is not the way to go, but to check for the functionality that
we need/want.

Regards,
--
Bil Kleb
http://fun3d.larc.nasa.gov

Bil Kleb wrote:
> Dave wrote:
>> I'm trying to write three shell scripts, which determine if the 
>> C/C++/Fortran compilers are GNU, Sun, IBM. HP etc.
> 
> We use autoconf and M4 macros for this.
> 
> Lately, we've decided that checking for a specific compiler
> is not the way to go, but to check for the functionality that
> we need/want.
> 
> Regards,
> -- 
> Bil Kleb
> http://fun3d.larc.nasa.gov

I'm well aware of autoconf. Quite a few of the 100 or so problems in 
Sage use it. We try to touch the original source as little as possible, 
so upgrades can be used.

I have written a configure.ac to do some of the things I want, but some 
are not so easy. I think libtool might handle them, but that has a 
reputation for opening a can of worms to use that.

Dave

-- 
I respectfully request that this message is not archived by companies as
unscrupulous as 'Experts Exchange' . In case you are unaware,
'Experts Exchange'  take questions posted on the web and try to find
idiots stupid enough to pay for the answers, which were posted freely
by others. They are leeches.

Dave wrote:
> 
> Dave Allured wrote:
> 
> >Dave wrote:
> >> Many are the result of using GNU-specific flags. My aim is to replace
> >> flags like -fPIC with a variable which can be set in advance, so the
> >> code compiles and links on other platforms with other compilers. The
> >> world does not start and end with GNU tools, though many software
> >> developers acts as though it does.
> >>
> >> To make the code work with non-GNU compilers, I need to know what flags
> >> are needed on that platform. To do that, I need to know what compilers
> >> are in use. For C and C++ I'm doing that by use of the pre-processor.
> >>
> >> Any suggestions you have for how I might do that with Fortran are welcome.
> >
> > Let's look at the main objective.  From your original C example, it
> > seems that you want to start with an arbitrary command name for a
> > Fortran compiler, ignore any meaning of the literal spelling of the
> > command itself, and identify the compiler based on its behavior.  Right?
> 
> Yes, basically. At one point, I thought a grep on the output of '
> 
> $somecompiler --version
> 
> would show GNU or GCC if it was a GNU compiler, but that is not true.

Please do not mix up C and Fortran issues in this topic.  Your original
question was about Fortran compilers, not C.  I get the message that C
is handled in special ways.  If you want to identify gfortran, then
simply do the following.  A case insensitive comparison seems to be a
bit more robust for this one:

$somecompiler --version | grep -i 'GNU Fortran'

> On Ubuntu, 'gcc --version' will output 'gcc' but not GCC or GNU. But if
> invoked by the name 'cc', it is clearly the GNU compiler, but will not
> show GNU, GCC or gcc.
> 
> % cc --version
> cc (Ubuntu 4.3.3-5ubuntu4) 4.3.3
> Copyright (C) 2008 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> So relying on the name of the command is not really helpful.

For Fortran as well as C, I agree on this particular point.  As
previously discussed, some compilers are normally installed with
identifying command names e.g. gfortran, g95; others use generic
commands, e.g. Sun and others' f77, f90, etc.

> OK, I could add "Free Software Foundation" to the list of things I grep
> for, but it's anyones guess what information someone will output with
> the GNU compiler.
> 
> > For reasons I do not understand or wish to, it seems that use of
> > preprocessors evolved as the favored method of testing identification of
> > C compilers.
> 
> It was suggested by a few on comp.unix.shell when I originally asked
> about this.
> 
> http://groups.google.co.uk/group/comp.unix.shell/browse_thread/thread/aa0dfac7c7aeb412/1d432f8b8bfc54a?hl=en&ie=UTF-8&q=How+can+I+tell+if+%27CC%27+is+the+GNU+C+compiler%3F#01d432f8b8bfc54a
> 
> The general opinion was that using the pre-processor is the most
> reliable and that relying on the use of -v, -V, --version and other
> similar things is not so useful.

I am sure this is sage advice for C compilers.  Fortran is different.

> I'm also aware the linker is an issue. I found when trying to build Sage
> on Solaris, it went ok if gcc used the GNU linker and assembler, but
> failed if gcc was configured to use Sun's linker and assembler. I've
> since sorted all those issues out. Though I wish I'd given more thought
> at the time to running on other platforms. There were specific reasons
> for wanting Solaris.
> 
>   * I own SPARC hardware myself
>   * Sun are providing support for the project in terms of hardware. They
> donated a Sun T5240 (16 core box) to the Sage project. I do not use that
> machine much, as I have a Sun of my own at home.
> 
> > Now the few fortran compilers in my experience do a good
> > job identifying themselves directly with command switches like -V or
> > --version.  No test program is involved.
> 
> Sun's does not on Solaris. Neither -v or --version work. -V does I would
> admit.

So your test for Sun Fortran starts with $somecompiler -V !!  What's the
problem?  Don't expect all Fortrans to play so nicely that they all
implemented the same "version" flag!  Heh, that's not in the standard!

> > However, by this direct method, compare strings must be built directly
> > into the invoking shell script.  I do not see this as a problem.  An
> > added advantage is that you also get a nice version number on your
> > platter, for when it might matter.
> 
> gcc and g++ will give you the version using the -dumpversion flag.
> gfortran will not. I have reported that as a bug against gfortran, and
> believe that will be fixed in the next release.
> 
> drkirkby@swan:[~] $ gcc -dumpversion
> 4.4.1
> drkirkby@swan:[~] $ g++ -dumpversion
> 4.4.1
> drkirkby@swan:[~] $ gfortran -dumpversion
> GNU Fortran (GCC) 4.4.1
> Copyright (C) 2009 Free Software Foundation, Inc.
> 
> GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
> You may redistribute copies of GNU Fortran
> under the terms of the GNU General Public License.
> For more information about these matters, see the file named COPYING
> 
> drkirkby@swan:[~] $

This is far astray from "how to identify a fortran compiler".  You
already know that gfortran --version will be fine for this purpose.

> > So why not use this much more straightforward method for compiler
> > identification, and skip the preprocessor gyrations?
> 
> Well, when 'cc' outputs neither gcc, GNU, or GCC, but is still the GNU
> compiler, you can see doing this can be a bit tricky.

Again, that is C, this is Fortran.

In conclusion, modern fortran compilers usually support some kind of
reliable self identification with a command line flag.  No dummy test
program is needed.  It is the user's responsibility to determine and use
the correct ID flag for each compiler, and to do the appropriate custom
string matching on the output.

--Dave