I just wanted to chime in and say we are having the same issue.  In an e-mail 
(defined below) to colleagues, I was under the impression that setting the 
environment variable 'FC' would do the trick.  It wasn't until after looking 
through the installed CMake modules that 'FC' is completely ignored on Windows 
when using a Visual Studio generator.

First E-mail to colleagues:
I did a little research this morning during the planning, and it appears you 
only need to set the environment variable 'FC' to point to ifort.exe.  I assume 
your systems already have this variable based on what is installed by Intel, so 
all that really needs to be done is set the path internally.  Here is an 
example that you should be able to plug into your CMakeLists.txt for BigTac for 
testing.  Just update the paths to the required ifort.exe for the appropriate 
generator.

cmake_minimum_required(VERSION 3.5.2 FATAL_ERROR)

# this must be performed before calling project
# to set the fortran compiler...  for intel, FC
# is used to identify the fortran compiler that
# cmake will pick up on and use to determine abi
if (CMAKE_GENERATOR MATCHES "^Visual Studio")

   if (CMAKE_GENERATOR MATCHES "^Visual Studio 10")
      # set the path to the fortran compiler for vs2010
      set(ENV{FC} "C:/Path/To/VS2010/ifort.exe")
   elseif (CMAKE_GENERATOR MATCHES "^Visual Studio 14")
      # set the path to the fortran compiler for vs2015
      set(ENV{FC} "C:/Path/To/VS2015/ifort.exe")
   else ( )
      # remove from the environment just in case one is set
      unset(ENV{FC})
   endif ( )

   if (NOT EXISTS "$ENV{FC}")
      # indicate to the user that the fortran library could not be found
      # but allow the process to continue, as it should still generate c / c++ 
/ c#
      message(AUTHOR_WARNING
              "Unable to set the Intel Fortran compiler for "
              "the specified MSVC generator '${CMAKE_GENERATOR}'!!!")
   else ( )
      # message the path to the compiler to use
      message(STATUS "Fortran compiler: '$ENV{FC}'")
   endif ( )

endif ( )

project(cmake-fortran-test)
--------------------- First E-mail to colleagues End 
---------------------------------

Second E-mail to colleagues:
So, I did a bit more looking into this and this appears to be an issue with how 
Intel integrates with Visual Studio.  I would say if you create a simple 
Fortran project that the wrong version of the Intel compiler will be used to 
compile the project.  Please do try the statements below to see if this 
corrects the issue; though, I am not optimistic it will based on my research.  
I overlooked the internal files related to the FC environment variable, as it 
is used if Visual Studio is not used.  I'll pose the question to CMake, as I am 
not finding good information on this.

>From what I see, the try compile of a temp project sets a post build command 
>that sets the compiler path.

for %%i in (ifort.exe) do @echo CMAKE_Fortran_COMPILER=%%~$PATH:i

Modifying the PATH environment variable will not work because visual studio 
appends to the front of the PATH certain paths, one of them being the location 
of the Fortran compiler.  This path appears to be associated to the registry 
variable 
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Intel\Compilers\Fortran\121.258\IA32\VSNet2010\BinDir.

To be able to help here more, I would need to get a machine with both compilers 
(VS and Intel) installed on a system to test some ideas out.  It may be as easy 
as making sure that when you install to your system the Intel compilers, make 
sure to install the older Intel compiler first to make the association to 
VS2010 and then install the newer Intel compiler making only the association to 
VS2015.  It sounds like there should be the capabilities to indicate which 
version to integrate with based on the following article:

https://software.intel.com/en-us/articles/using-older-intel-visual-fortran-versions-in-different-microsoft-visual-studio-versions

It may be possible to just reset the registry variable for VS2010.  I am 
assuming that it is getting messed up, but I cannot tell without having both on 
a system to play around with.

I'll post the question to the CMake forum tomorrow to see if anyone can help 
with this situation.  This cannot be unique to us.  I'll keep you apprised, but 
if you have a machine I may be able to test with, please let me know.

Thanks and good day guys.
--------------------- Second E-mail to colleagues End 
---------------------------------

I have not sat down to try and figure this out any further, but I would be very 
interested in knowing what is the best solution.  For our case, there is a 
project that builds under VS2010 and Intel's VS2010 compatible Fortran 
compiler.  Installing VS2015 on the same machine with Intel's VS2015 compatible 
Fortran compiler causes issues when trying to generate a VS2010 version of the 
solution, as Intel's VS2015 compatible Fortran compiler is always selected.  In 
the article posted, there is a way to preserve older compiler versions within 
older visual studio versions, but I have not looked into that as an option yet. 
 I hope to get there one day.  It would be nice if this was a bit more 
configurable from within CMake so that such operations are not required to be 
performed.

Ryan H. Kawicki

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Arjen Markus
Sent: Friday, April 13, 2018 2:03 AM
To: William Clodius <w.clod...@icloud.com>; cmake@cmake.org
Subject: Re: [CMake] Testing with multiple Fortran compilers


Hi William,



The compiler is not determined via this line - that merely retrieves the name 
component from the full path to the actual compiler executable. CMake uses a 
number of methods, if I may express it that way, to determine which compiler 
(Fortran or otherwise to use). One of them is the FC environment variable. If 
that is not set, it searches through a list of possible compiler commands.



As for CMakeCache.txt and the like: it is best to start a build in a clean 
directory. Left-overs from a previous build may confuse the configuration and 
actual building of the program or programs.



(As for get_file_component: In the PLplot project the PATH part of the full 
path to the compiler is used to fine-tune the directories where the compiler 
libraries are to be found.)



Regards,



Arjen


Arjen Markus
Sr. Adviseur/Onderzoeker
T

+31(0)88 335 8559

E

arjen.mar...@deltares.nl




[Logo]<http://www.deltares.com/>

 www.deltares.com<http://www.deltares.com/>

Postbus 177
2600 MH Delft

[Deltares Twitter]
<http://www.twitter.com/deltares>

[Deltares LinkedIn]<http://www.linkedin.com/company/217430>

[Deltares Facebook]<https://www.facebook.com/pages/Deltares/154189334634001>



[Think before printing]Please consider the environment before printing this 
email


> -----Original Message-----
> From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of William Clodius
> Sent: Friday, April 13, 2018 4:34 AM
> To: cmake@cmake.org
> Subject: [CMake] Testing with multiple Fortran compilers
>
> I have been using CMake with gfortran for a number of years, and now want test
> my code with ifort. I want to switch easily switch between compilers. My
> CMakeLists.txt file is based on the fortran example from make.org an appears 
> to
> have most of the infrastructure needed, but I don't understand how the line
>
> get_filename_component (Fortran_COMPILER_NAME
> ${CMAKE_Fortran_COMPILER} NAME)
>
> determines the Fortran compiler to be used. Does it examine the FC system
> variable? Does it require the full pathname to the compiler executable? Do I 
> have to
> delete the CMakeCache.txt, Makefile, and cmake_install.cmake each time I 
> change
> compilers?
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
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:
https://cmake.org/mailman/listinfo/cmake

Reply via email to