Initial implementation of get_os()

[certik]

It might be difficult to get this working via pre-processor.

[certik]

This PR actually fails tests, but they look like they passed due to #143.

[milancurcic]

It looks good, I added a few suggestions.

Why are you concerned that preprocessing may not work?

[certik]

@milancurcic the tests are currently failing, even though they are green. The macros do not work, if you click on the output when we just run fpm, you can see that you get a stacktrace and "error stop".

[certik]

The latest commit prints os type 1 (Linux) on all platforms. Ok, I think the macros do not work at all. I am going to use an alternative implementation using environment variables.

[jvdp1]

The latest commit prints os type 1 (Linux) on all platforms. Ok, I think the macros do not work at all. I am going to use an alternative implementation using environment variables.

How did you pass the macro to gfortran? as -DFMP_OS_xxxx?

[jvdp1]

The latest commit prints os type 1 (Linux) on all platforms. Ok, I think the macros do not work at all. I am going to use an alternative implementation using environment variables.

If it could help, fpp and macros seem to work when compiling manually:

 gfortran -cpp -D_WIN32 fpm.F90
$ ./a.out 
 Fortran Package Manager (fpm)
 OS Type:            3

[certik]

@jvdp1 the issue is that those macros do not seem to be defined by default on any platform with gfortran (and obviously we need to support all Fortran compilers down the road, each defining slightly different macros).

The current solution as of (a1dc068) seems to work. It's obviously not super robust, but it will get us started, and we can design the correct full solution in #144.

[certik]

Everything works except Windows. It just occurred tome that if $HOME doesn't exist, then we can assume Windows. I am going to rework it.

[milancurcic]

The problem now is that if a Windows user defines %HOME% for any reason, the function will fail.

I think the original %HOMEPATH% approach is more robust, but you also need to test the value:

call get_environment_variable("HOMEPATH", val, status=stat)
if (stat == 0 .and. val(1:7) == "\Users\") then
    r = OS_WINDOWS
    return
end if

[certik]

So when I first implemented $HOMEPATH for Windows, it failed: https://github.com/fortran-lang/fpm/runs/899185101, but then the later commit which didn't touch it, succeeded: https://github.com/fortran-lang/fpm/runs/899226753. This is infuriating, I spent hours yesterday due to this fragility of the GitHub Actions. I think they sometimes test a previous commit, even though they claim to test the latest commit. This is really bad from a reliability perspective.

Anyway, the latest commit (only using $HOME) also seems to work, but who know knows if it actually got tested?

I can put in back the $HOMEPATH if you prefer. This is all fragile and can easily break anyway, if somebody declares HOMEPATH on linux for example.

[milancurcic]

This is all fragile and can easily break anyway, if somebody declares HOMEPATH on linux for example.

Yes, but testing for the value ("\Users\") greatly reduces the chance of collision. I don't think we should excuse the code to be fragile if the CI is already fragile.

[certik]

Right. I did it as you suggested, but I just don't know which of the two is more robust (will succeed in more cases):

• Test for $HOMEPATH=\Users\
• Test that $HOME does not exist

Because I do not know if $HOMEPATH on Windows can be set to other paths than \Users\ quite often, or not. And compared to that how often do users define $HOME on Windows.

[certik]

I checked the CI manually, it still seems to work (assuming the CI tested the latest commit). But given the fact that the previous commit seems to work, then if the master fails after this is merged, we can always revert the latest commit.

This is ready for a final review and merge as far as I am concerned.

[certik]

@milancurcic, @everythingfunctional is this ok to go in? I have another PR (#145) that depends on this.

[milancurcic]

I think it's good to go, thanks @certik!