I have found some previous discussions on this
I still do not understand the steps to use fpm with intel. I want to use it for windows 10. What I mean is perhaps where I should replace gfortran with ifx or whatever I need to modify. I do not see any relevant info here How-To guides — Fortran Package Manager (fortran-lang.org)
It should be as simple as,
fpm build --compiler ifx
Alternatively, you can set an environment variable in your session:
set FPM_FC=ifx
More details on the set command here: set | Microsoft Learn
Yes. Note all the environment variables and command keywords related to compiling and linking options are described in the built-in help text, so “fpm help build” provides some descriptions.
All the help text can be placed in a text file with a single command
fpm manual >fpm.txt
which describes using a response file as well.
For example, in the same directory as the fpm.toml manifest file create a file called “fpm.rsp” with lines like
@buildi
options build --compiler ifx --verbose
@buildg
options build --compiler gfortran --verbose
and then you can use the abbreviations you just created by using the names on the command lines:
fpm @buildi
as well. This is most useful when you want to repeatedly use long custom compiler and loader options.
Of course, you can also use wrapper scripts and shell aliases, but that varies from system to system type.
Using ifx on windows requires properly settings a lot of paths and environmental variables.
The simplest is usually to use the intel console shipped with the compiler. It’s the classical cmd in which the required variables are properly set.
Then, you can just proceed as @ivanpribec said. And if you are using response file as @urbanjost suggested, just do not do it from a powershell terminal (@ character is not properly interpreted)
@ in powershell is a problem, but double-quoting or using names with a dash in them works around it, as per
i did change from system variables and created this new one
The fpm build manual says
ENVIRONMENT VARIABLES
FPM_FC sets the path to the Fortran compiler used for the build,
will be overwritten by --compiler command line option
So the environment variable here is supposed to find the location of intel compiler by itself ?
You haven’t set all the environment varaibles that are needed for the compiler to work.
If you are using the Intel oneApi toolkit, you should find a .bat file, that will set up everything for you. You should find it here:
C:\Program Files (x86)\Intel\oneAPI\setvars.bat
So run it in the terminal, then you should be able to find the ifort command (the ifx compiler should be available for you now too)
If you do not use the oneApi command prompt (that simply run the setvars mentioned above) that will be a lot trickier. In addition, since you are using the msys2 terminal, the variables need to be set in your mingw environment, not on windows.
so far my understanding is:
There are three terminals
So now the relevant options are 1) and 3).
Now I wanna know which command I should use for setting environment variable in the Msys2 terminal? and how about the path? path is the same as environment variable? I think they are different!
From my personal experience, only option 1 is straightforward and with option 3 you will face many issues starting with incompatible paths between Windows and the Unix kinds used by msys2.
The simplest for you is to use option 1 and make sure that fpm is in the Windows Path. If you installed fpm with msys2, just add the installation folder into your path environmental variables. On my computer, fpm is installed under “C:\msys64\mingw64\bin”. Once done, just start the intel terminal and type fpm --help to make sure it is accessible.
From there, you should be good to go.
By the way, if you are using VSCode you can add the intel terminal to your default terminals.
Simply create a script named intel.cmd with the following command
%ComSpec% /E:ON /K ""C:\Program Files (x86)\Intel\oneAPI\setvars.bat" intel64 vs2019"
just make sure that the paths and arguments are correct for you. I usually place that file in the .vscode folder.
Then, in your *.code-workspace (alternatively, in the settings.json), paste the following
"settings" : {
...
"terminal.integrated.profiles.windows": {
"Intel Prompt": {
"path": [
"${env:windir}\\System32\\cmd.exe"
],
"args": ["/K",
".\\.vscode\\intel.cmd"],
"icon": "terminal-cmd"
}
},
"terminal.integrated.defaultProfile.windows": "Intel Prompt"
}
This will run the script setvars.bat every time you start a new terminal
@davidpfister what if Windows had a shell that would be a strict subset of Bash/Zsh, but unlike git-bash/msys2 without any weird/confusing Linux like path overlay, so it would handle Windows paths directly? I would think a lot of the native Windows command-line programs might work better, and as a bonus one could write exactly the same script to build a project (or do other things) and it would run unmodified on Linux, macOS and Windows, which would be very handy for end users and at a CI, etc.
It would sound like Christmas to me 
. You also have to consider that the rules for specifying the root is different, the max path length is different… and allowed characters and spaces. In the example mentioned above with vscode I could not get it to work without using a script because of the space between ‘Program’ and ‘Files’ and because vscode does not support double quoting the arguments.
From what I saw Cygwin is shipped with some utility program (cygpath) that can do the path conversion.
@davidpfister excellent. 
I have not fully figured out all cases yet, but I’ve noticed PowerShell just automatically quotes Windows paths with spaces. So that’s how the interactive Bash like shell can behave too. Instead of:
%ComSpec% /E:ON /K ""C:\Program Files (x86)\Intel\oneAPI\setvars.bat" intel64 vs2019"
The Bash like script would be something like:
$ComSpec /E:ON /K '"C:\Program Files (x86)\Intel\oneAPI\setvars.bat" intel64 vs2019'
It needs to work with most .bat files, I am hoping that if one can check what environment variables changed, the Bash-like shell can figure it out and bring it to the current environment.
If that helps, upon installation, oneapi installer creates the env. var. ONEAPI_ROOT that should correspond to “C:\Program Files (x86)\Intel\oneAPI”. It still needs to be double-quoted though.
As for powershell, despite the disturbing syntax, it’s a pretty cool shell. Too bad it does not handle response files very well as mentionned above.
I set the variable there in the intel batch file.
Where should I add this and how? If this is for msys2, I do not know the msys2 settings for path variables!
Sorry if I was not clear. I assumed that you used msys2 to install fpm and because of this, fpm will not be automatically present in the Windows path.
So you can proceed as follows:
fpm with your method of choicefpm:fpm build --compiler ifx(since you are using a script you can simply add the line fpm build after the call to set FPM_FC ifx)
C:\Program Files (x86)\Intel\oneAPI>cd /d C:\Users\owner\Desktop\fpm_test
C:\Users\owner\Desktop\fpm_test>fpm build --compiler ifx
‘fpm’ is not recognized as an internal or external command,
operable program or batch file.
The last message confirm that the path to fpm is not set in you PATH env. var.
Try this in your script (at the very beginning)
set PATH=%PATH%;“C:\msys64\mingw64\bin”
that should do the trick
After revisiting this (not an MSWindows/powershell user so not positive) but it looks like @ is only special at the beginning of a simple name so allowing an @ at the end to be treated as equivalent to an @ at the beginning of the word seems more appealing than double-quoting or creating responses with a dash in the name. I am not sure how much interest in that there is but I can put in a PR for that if it seems like a solution anyone would use/need.