subject:"Re\: \[CMake\] FORTRAN name mangling"

Re: [CMake] FORTRAN name mangling

2016-01-12 Thread Arjen Markus

> Exactly, that is the whole point of the standardized `ISO_C_BINDING` module 
> and C interop being added to the Fortran 2003 standard. No more ugly guess 
> work, hackery, etc.

> AFAIK, there is pretty good support for this among compiler vendors, so long 
> as you have a recent release.

> Even as far back as about five years ago, all 10 compilers surveyed by Ian 
> Chivers and Jane Sleightholme supported C interoperability.  And now there 
> are at least four compilers that even support the _additional_ C 
> interoperability features in the draft Fortran 2015 standard: the IBM, Cray, 
> Intel, and GNU compilers.  C interoperability appears to be one of the first 
> things every compiler team tackles from a new standard.

> Anyone with access to ACM Fortran Forum will benefit from consulting the 
> standards-support survey that Ian and Jane have published in almost every 
> issue for roughly a decade or so.  Standards support in  Fortran compilers is 
> not quite where it needs to be, but it's much better than it was even just a 
> couple of years ago. Great strides have been taken.

Just to chime in here, in the PLplot project (plplot.sf.net) we are currently 
reimplementing the Fortran interface to the plotting routines that have been 
implemented in C. The previous version took advantage of all Fortran 90/95 
features, such as function overloading and assumed-shape arrays to avoid the 
extra arguments needed to tell the plotting routines how many elements there 
are. This required quite a lot of C code, as the naming conventions/name 
mangling had to be handled on the C side.

The new set-up however uses the ISO_C_BINDING features to the fullest extent. 
The benefits of this new set-up are plenty:

- We can support single and double precision versions of the routines in one 
library, whereas before we had to rely on the Fortran programs using the same 
precision as the C library. This could have been done with just the Fortran 
90/95 features too - just a matter of progressive insight.

- Almost all C code has been eliminated as matching the names of the routines 
can now be done on the Fortran side. The advantage of that is that the Fortran 
compiler is completely responsible for this, rather than a set of confusing C 
macros the details of which depend on the Fortran compiler.

Of course, this means that you have to have the ability to adjust the Fortran 
code, but for a given library, you could simply write a Fortran interface layer 
that uses the ISO_C_BINDING features instead of a C one.

Regards,

Arjen
DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited. 
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] FORTRAN name mangling

2016-01-11 Thread Bill Somerville


On 11/01/2016 17:58, Michael Jackson wrote:

and we call the function from our C code like the following:


SingleEBSDPattern_(ipar, fpar, ebsdPattern, quats, accum_e, mLPNH, mLPSH);


You need to use the macros here too.

Regards
Bill Somerville.
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] FORTRAN name mangling

2016-01-11 Thread Bill Somerville


On 11/01/2016 18:48, Michael Jackson wrote:

Do other FORTRAN compilers support this “bind(C)” thing

I can only vouch for gfortran but yes that is the idea.

Regards
Bill Somerville.
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] FORTRAN name mangling

2016-01-11 Thread Michael Jackson

Actually, 
  If we just use the following:

SingleEBSDPattern(ipar, fpar, ebsdPattern, quats, accum_e, mLPNH, mLPSH);

and the same declaration in a .h file then we can link and execute just fine. 
My question now would be:

Do other FORTRAN compilers support this “bind(C)” thing, such as Intel Fortran? 
If so then I can really NOT worry about figuring out the mangling that is 
needed and just declare the functions in a C style header like normal. No 
macros needed.
--
Michael A. Jackson
BlueQuartz Software, LLC
[e]: mike.jack...@bluequartz.net

> On Jan 11, 2016, at 1:13 PM, Bill Somerville  wrote:
> 
> On 11/01/2016 17:58, Michael Jackson wrote:
>> and we call the function from our C code like the following:
>> 
>> 
>> SingleEBSDPattern_(ipar, fpar, ebsdPattern, quats, accum_e, mLPNH, mLPSH);
>> 
> You need to use the macros here too.
> 
> Regards
> Bill Somerville.
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] FORTRAN name mangling

2016-01-11 Thread Bill Somerville


On 11/01/2016 17:58, Michael Jackson wrote:
subroutine SingleEBSDPattern(ipar, fpar, EBSDpattern, quats, accum_e, 
mLPNH, mLPSH) bind(c, name='SingleEBSDPattern')


Surely if you use bind(C) you need do no more than extern "C" the 
declaration when compiling C++. I thought bind(C) meant mangle the 
external name in the same way that a C module would.


We use the FortranCInterface module for old Fortran procedures that are 
not using ISO_C_BINDING and bind(C), for them we add the symbols to the 
FortranCInterface_HEADER() command and use the generated macros to 
reference the symbols in C/C++.


We also execute FortranCInterface_VERIFY(CXX QUIET) before the 
FortranCInterface_HEADERS() command.


It all works OK but we only use gcc/g++/Clang/Clang++/gfortran compilers.

Regards
Bill Somerville.
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] FORTRAN name mangling

2016-01-11 Thread Thompson, KT

"bind(c)" is a part of the Fortran 2003 standard.  Any compiler that claims to 
support this standard should work for you.

I use Intel Fortran on Linux (v13-16) with bind(c) w/o issue.  FWIW - I also 
use the Portland Group (12+) and IBM Fortran (v14) compilers this way.

-kt

-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Michael Jackson
Sent: Monday, January 11, 2016 11:48 AM
To: Bill Somerville <b...@classdesign.com>
Cc: cmake@cmake.org
Subject: Re: [CMake] FORTRAN name mangling

Actually, 
  If we just use the following:

SingleEBSDPattern(ipar, fpar, ebsdPattern, quats, accum_e, mLPNH, mLPSH);

and the same declaration in a .h file then we can link and execute just fine. 
My question now would be:

Do other FORTRAN compilers support this “bind(C)” thing, such as Intel Fortran? 
If so then I can really NOT worry about figuring out the mangling that is 
needed and just declare the functions in a C style header like normal. No 
macros needed.
--
Michael A. Jackson
BlueQuartz Software, LLC
[e]: mike.jack...@bluequartz.net

> On Jan 11, 2016, at 1:13 PM, Bill Somerville <b...@classdesign.com> wrote:
> 
> On 11/01/2016 17:58, Michael Jackson wrote:
>> and we call the function from our C code like the following:
>> 
>> 
>> SingleEBSDPattern_(ipar, fpar, ebsdPattern, quats, accum_e, mLPNH, mLPSH);
>> 
> You need to use the macros here too.
> 
> Regards
> Bill Somerville.
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] FORTRAN name mangling

2016-01-11 Thread Damian Rouson

> On Jan 11, 2016, at 11:31 AM, Zaak Beekman  wrote:
> 
> 
> So if I require Fortran 2003 for our fortran codes then this whole ?fortran 
> name-mangling? thing becomes a moot point, i.e. I do not have to actually 
> worry about it at all for our project. Just have to keep the C header 
> consistent with the FORTRAN functions, but that part is on our devs.
> 
> Exactly, that is the whole point of the standardized `ISO_C_BINDING` module 
> and C interop being added to the Fortran 2003 standard. No more ugly guess 
> work, hackery, etc.
> 
> AFAIK, there is pretty good support for this among compiler vendors, so long 
> as you have a recent release.

Even as far back as about five years ago, all 10 compilers surveyed by Ian 
Chivers and Jane Sleightholme supported C interoperability.  And now there are 
at least four compilers that even support the _additional_ C interoperability 
features in the draft Fortran 2015 standard: the IBM, Cray, Intel, and GNU 
compilers.  C interoperability appears to be one of the first things every 
compiler team tackles from a new standard.

Anyone with access to ACM Fortran Forum will benefit from consulting the 
standards-support survey that Ian and Jane have published in almost every issue 
for roughly a decade or so.  Standards support in  Fortran compilers is not 
quite where it needs to be, but it’s much better than it was even just a couple 
of years ago. Great strides have been taken.

> I know for sure GCC's gfortran and Intel's ifort support this very well. I'm 
> pretty sure PGI, Cray and IBM support it too. I have never used NAG, so I 
> withhold comment there, but I'd be surprised if they had yet to add this to 
> their compiler. The demand for C interop is really high, and almost all of 
> these companies make companion C compilers, so, in my experience, they have 
> been relatively quick to implement these features, while some other Fortran 
> 2003 and later features have languished. (I'm looking at you, parameterized 
> derived types…)

PDT is one of the few Fortran 2003 features for which support is still a bit 
limited, but it is supported by at lest four compilers: IBM, Cray, Intel, and 
Portland Group, all of which are fully Fortran 2003 compliant.  I would bet 
that NAG will have it soon and GNU will likely have it in their development 
branch sometime later this year.  A developer has already put a great deal of 
work into scoping out the effort.  PDTs are a monster to implement in a 
compiler.

> 
> P.S. Unless you want to sound like an old geezer, it's spelled Fortran these 
> days, not FORTRAN. ;-)

And the standard has spelled it in mixed case at least since Fortran 90 so, in 
addition to being dated, spelling FORTRAN in all-caps is non-standard. 

:D

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] FORTRAN name mangling

2016-01-11 Thread Thompson, KT

Michael,

You should always test your toolchain first.  Compilers are often buggy or may 
not fully support a language feature.  But yes, requiring F2003 should address 
your concern.

-kt

-Original Message-
From: Michael Jackson [mailto:mike.jack...@bluequartz.net] 
Sent: Monday, January 11, 2016 12:11 PM
To: Thompson, KT <k...@lanl.gov>
Cc: cmake@cmake.org
Subject: Re: [CMake] FORTRAN name mangling

So if I require Fortran 2003 for our fortran codes then this whole “fortran 
name-mangling” thing becomes a moot point, i.e. I do not have to actually worry 
about it at all for our project. Just have to keep the C header consistent with 
the FORTRAN functions, but that part is on our devs.

--
Michael A. Jackson
BlueQuartz Software, LLC
[e]: mike.jack...@bluequartz.net

> On Jan 11, 2016, at 2:06 PM, Thompson, KT <k...@lanl.gov> wrote:
> 
> "bind(c)" is a part of the Fortran 2003 standard.  Any compiler that claims 
> to support this standard should work for you.
> 
> I use Intel Fortran on Linux (v13-16) with bind(c) w/o issue.  FWIW - I also 
> use the Portland Group (12+) and IBM Fortran (v14) compilers this way.
> 
> -kt
> 
> -Original Message-
> From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Michael Jackson
> Sent: Monday, January 11, 2016 11:48 AM
> To: Bill Somerville <b...@classdesign.com>
> Cc: cmake@cmake.org
> Subject: Re: [CMake] FORTRAN name mangling
> 
> Actually, 
>  If we just use the following:
> 
> SingleEBSDPattern(ipar, fpar, ebsdPattern, quats, accum_e, mLPNH, mLPSH);
> 
> and the same declaration in a .h file then we can link and execute just fine. 
> My question now would be:
> 
> Do other FORTRAN compilers support this “bind(C)” thing, such as Intel 
> Fortran? If so then I can really NOT worry about figuring out the mangling 
> that is needed and just declare the functions in a C style header like 
> normal. No macros needed.
> --
> Michael A. Jackson
> BlueQuartz Software, LLC
> [e]: mike.jack...@bluequartz.net
> 
>> On Jan 11, 2016, at 1:13 PM, Bill Somerville <b...@classdesign.com> wrote:
>> 
>> On 11/01/2016 17:58, Michael Jackson wrote:
>>> and we call the function from our C code like the following:
>>> 
>>> 
>>> SingleEBSDPattern_(ipar, fpar, ebsdPattern, quats, accum_e, mLPNH, mLPSH);
>>> 
>> You need to use the macros here too.
>> 
>> Regards
>> Bill Somerville.
>> -- 
>> 

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] FORTRAN name mangling

2016-01-11 Thread Zaak Beekman

> So if I require Fortran 2003 for our fortran codes then this whole
> ?fortran name-mangling? thing becomes a moot point, i.e. I do not have to
> actually worry about it at all for our project. Just have to keep the C
> header consistent with the FORTRAN functions, but that part is on our devs.
>

Exactly, that is the whole point of the standardized `ISO_C_BINDING` module
and C interop being added to the Fortran 2003 standard. No more ugly guess
work, hackery, etc.

AFAIK, there is pretty good support for this among compiler vendors, so
long as you have a recent release. I know for sure GCC's gfortran and
Intel's ifort support this very well. I'm pretty sure PGI, Cray and IBM
support it too. I have never used NAG, so I withhold comment there, but I'd
be surprised if they had yet to add this to their compiler. The demand for
C interop is really high, and almost all of these companies make companion
C compilers, so, in my experience, they have been relatively quick to
implement these features, while some other Fortran 2003 and later features
have languished. (I'm looking at you, parameterized derived types...)

Happy hacking!

P.S. Unless you want to sound like an old geezer, it's spelled Fortran
these days, not FORTRAN. ;-)
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] FORTRAN name mangling

2016-01-11 Thread Michael Jackson

So if I require Fortran 2003 for our fortran codes then this whole “fortran 
name-mangling” thing becomes a moot point, i.e. I do not have to actually worry 
about it at all for our project. Just have to keep the C header consistent with 
the FORTRAN functions, but that part is on our devs.

--
Michael A. Jackson
BlueQuartz Software, LLC
[e]: mike.jack...@bluequartz.net

> On Jan 11, 2016, at 2:06 PM, Thompson, KT <k...@lanl.gov> wrote:
> 
> "bind(c)" is a part of the Fortran 2003 standard.  Any compiler that claims 
> to support this standard should work for you.
> 
> I use Intel Fortran on Linux (v13-16) with bind(c) w/o issue.  FWIW - I also 
> use the Portland Group (12+) and IBM Fortran (v14) compilers this way.
> 
> -kt
> 
> -Original Message-
> From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Michael Jackson
> Sent: Monday, January 11, 2016 11:48 AM
> To: Bill Somerville <b...@classdesign.com>
> Cc: cmake@cmake.org
> Subject: Re: [CMake] FORTRAN name mangling
> 
> Actually, 
>  If we just use the following:
> 
> SingleEBSDPattern(ipar, fpar, ebsdPattern, quats, accum_e, mLPNH, mLPSH);
> 
> and the same declaration in a .h file then we can link and execute just fine. 
> My question now would be:
> 
> Do other FORTRAN compilers support this “bind(C)” thing, such as Intel 
> Fortran? If so then I can really NOT worry about figuring out the mangling 
> that is needed and just declare the functions in a C style header like 
> normal. No macros needed.
> --
> Michael A. Jackson
> BlueQuartz Software, LLC
> [e]: mike.jack...@bluequartz.net
> 
>> On Jan 11, 2016, at 1:13 PM, Bill Somerville <b...@classdesign.com> wrote:
>> 
>> On 11/01/2016 17:58, Michael Jackson wrote:
>>> and we call the function from our C code like the following:
>>> 
>>> 
>>> SingleEBSDPattern_(ipar, fpar, ebsdPattern, quats, accum_e, mLPNH, mLPSH);
>>> 
>> You need to use the macros here too.
>> 
>> Regards
>> Bill Somerville.
>> -- 
>> 

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] FORTRAN name mangling

2016-01-11 Thread Bill Hoffman


On 1/11/2016 2:31 PM, Zaak Beekman wrote:

Happy hacking!

FYI:
There is a longer version of that blog found here:
http://www.netlib.org/lapack/lawnspdf/lawn270.pdf
bind(c) sounds like a good idea if your compilers support it.

-Bill

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Fortran name mangling

2009-12-02 Thread Brad King

Brad King wrote:
 My guess is that CMake is generating a bad .vfproj file

It was generating a bad file in the case of per-source compiler definitions.

 perhaps
 due to the presence of both C and Fortran sources in one of the
 detection project targets.

This was not the cause because there are no mixed language targets
in the detection project.  There is a mixed-language target in the
project created by FortranCInterface_VERIFY() but you do not need
to use that macro to get the mangling set up.

The commit below fixes the problem.  I've scheduled it for 2.8.1.

-Brad

Fix .vfproj files with per-source settings
/cvsroot/CMake/CMake/Source/cmLocalVisualStudio7Generator.cxx,v  --  
Source/cmLocalVisualStudio7Generator.cxx
new revision: 1.258; previous revision: 1.257
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Fortran name mangling

2009-12-02 Thread Biddiscombe, John A.

Brad

Great. Thanks very much for looking at it. 

JB

 -Original Message-
 From: Brad King [mailto:brad.k...@kitware.com]
 Sent: 02 December 2009 17:57
 To: Biddiscombe, John A.
 Cc: cmake@cmake.org
 Subject: Re: [CMake] Fortran name mangling

 Brad King wrote:
  My guess is that CMake is generating a bad .vfproj file

 It was generating a bad file in the case of per-source compiler definitions.

  perhaps
  due to the presence of both C and Fortran sources in one of the
  detection project targets.

 This was not the cause because there are no mixed language targets
 in the detection project.  There is a mixed-language target in the
 project created by FortranCInterface_VERIFY() but you do not need
 to use that macro to get the mangling set up.

 The commit below fixes the problem.  I've scheduled it for 2.8.1.

 -Brad

 Fix .vfproj files with per-source settings
 /cvsroot/CMake/CMake/Source/cmLocalVisualStudio7Generator.cxx,v  --
 Source/cmLocalVisualStudio7Generator.cxx
 new revision: 1.258; previous revision: 1.257
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Fortran name mangling

2009-11-25 Thread Brad King


Biddiscombe, John A. wrote:
However, for unknown reasons, when I use this code on the win32 machine 
which is compiling the primary fortran projects happily, this happens

[snip]
The question is, why is/are the solution files being corrupted when 
running  in the CFortranInterface try compile stages – when other 
projects are generated correctly.


I don't think this was ever fully tested with the IDE generators.

My guess is that CMake is generating a bad .vfproj file, perhaps
due to the presence of both C and Fortran sources in one of the
detection project targets.

I'll have time next week to investigate further.

-Brad
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] FORTRAN name mangling

Re: [CMake] FORTRAN name mangling

Re: [CMake] FORTRAN name mangling

Re: [CMake] FORTRAN name mangling

Re: [CMake] FORTRAN name mangling

Re: [CMake] FORTRAN name mangling

Re: [CMake] FORTRAN name mangling

Re: [CMake] FORTRAN name mangling

Re: [CMake] FORTRAN name mangling

Re: [CMake] FORTRAN name mangling

Re: [CMake] FORTRAN name mangling

Re: [CMake] Fortran name mangling

Re: [CMake] Fortran name mangling

Re: [CMake] Fortran name mangling

14 matches

Site Navigation

Mail list logo

Footer information