Sounds like a good idea. I can help you test whenever you have something ready if you want.
1 Like
Great. Just need a few minutes but probably tomorrow at a miniumum I can make a single-file fpm.F90 file for testing. Between msys2, cygwin, powershell, cmd, \ and / in pathnames and which compiler you build with there is probably something I am missing but I think it should just be a few lines to make name@ equivalent to @name and then maybe some issues with executable ending in .exe and what OS and separator behavior you need as you can start in cygwin and spawn a powershell and so on; and powershell recognizes POSIX pathnames and DOS ones and so on. So maybe some testing with a single-file first and then will be more confident about the PR behavior in mixed environments. Thanks then.
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.
If you want to invoke fpm from the command line (as per your last image) then you need to write ‘set %PATH%…’ IN the command BEFORE calling fpm OR make sure that the path is in your env. var (which is clearly not the case). That should be fairly simple. Here is a step by step procedure
Otherwise, you can simply invoke your script from the intel terminal directly. The modification of the PATH variable is only valid within your current session.
Bottom line, your problem is not related to the intel compiler but to the fact that fpm is not in your PATH.
Draft of version that should take NAME@ as well as @NAME so theoretically will be easier to use in powershell:
https://raw.githubusercontent.com/urbanjost/index/main/bootstrap/fpmrsp.F90
gfortran fpmrsp.F90 -o fpm
just a draft, have not tried it on a non-ULS system; after it looks reliable it can go into a PR but this is just a single-file fpm source but I find that easiest to move around through programming environments I do not have set up otherwise.
So I manage to find some time and gave a try to your draft. Compilation worked fine and I decided to test the resulting fpm on a project of mine.
Unfortunately it does not seem to work on Windows 10 using Powershell. It looks like PS is still treating the ‘@‘ as a special command even when placed at the end of the string. I could not find a clear documentation on this behavior but I did find something about the ‘$’ character.
If I put the command between quotes it works as expected.
It was worth trying.
1 Like
Thanks. What I read implied to me it would not be treated as the splat character unless it was at the beginning of the word; which might have been incorrect or because @ appears to have multiple uses that I did not see earlier. If the CLI_RESPONSE_PREFIX variable is set to something like underscore that might work but I the way it works now you have to change the @ to _ in the response file too. If I change that so the prefix just gets changed to @ so you do not have to change the files that might be useful.
So far a leading underscore looks safe but PowerShell appears to use a lot of special character sequences.
Oh well.
After some extensive research I came across a post that might save powershell users.
Apparently one can change the behavior of the argument parser and make it « dumb » by using ‘-%’. I will give it a try.
In the end @urbanjost, do not change anything, the solution might already be in powershell.
Here is a very early Christmas present for you then: GitHub - prefix-dev/shell: The ultimate cross-platform, bash-like shell. This is obviously a very early alpha, expect it to break, etc. But I already use it as my daily driver on Windows and it’s amazing!
3 Likes