fpm should search in directories above current directory for fpm.toml file

[urbanjost]

I find the fpm(1) command much nicer to use if it searches for the fpm.toml file instead of requiring it to be executed in the directorin containing the fpm.toml file. For example, if I am working on files in the src, app, and test directories and my current directory is one of those directories I have to cd(1) up one directory and run fpm(1) and then cd back into the working directory or stay in the directory with the fpm.toml file and use long path names. I have been trying that with a personal version and it makes it MUCH nicer to use on larger projects with many directories, especially since each executable source has to be kept in a seperate directory.

[LKedward]

I like this idea! I have noticed the same thing while working with fpm, having to switch back and forth between two terminal panes when building. This is also exactly how git(1) works.

... especially since each executable source has to be kept in a seperate directory.

There is discussion in #164 (Automatically discover tests and executables) to remove this restriction and further simplify user-effort.

[urbanjost]

This is trivial if CHDIR(3f) is supported. Note that a quick survey of three compilers (GCC/gfortran, Intel, PGI) shows all support a CHDIR(3f) extension; and it is easily supported via ISO_C_BINDING interfaces on POSIX machines. It almost certainly will be part of stdlib at some point. Since it is such a common extension, would greatly simplify implementation of the feature, and currently Fortran fpm is assumed to be being built with gfortran perhaps some of the gfortran POSIX-like extensions (in this case CHDIR(3f)) can be used directly?

[arjenmarkus]

@martin Diehl <martin.diehl@kuleuven.be> and I are working on that sort of routines, as part of stdlib-os. The complications are the Windows platform which consists actually of four different environments (plain Windows, Cygwin, MinGW and MSYS). CHDIR is relatively simple, the main problem is unifying the build system (CMake based), such that we do not have to rely on a preprocessor on the Fortran side. I intend to solve the immediate issue we now have today or within the next few days. Op do 19 nov. 2020 om 03:28 schreef urbanjost <notifications@github.com>:

…

This is trivial if CHDIR(3f) is supported. Note that a quick survey of three compilers (GCC/gfortran, Intel, PGI) shows all support a CHDIR(3f) extension; and it is easily supported via ISO_C_BINDING interfaces on POSIX machines. It almost certainly will be part of stdlib at some point. Since it is such a common extension, would greatly simplify implementation of the feature, and currently Fortran fpm is assumed to be being built with gfortran perhaps some of the gfortran POSIX-like extensions (in this case CHDIR(3f)) can be used directly? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#172 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN6YR22RZH3GCDD4BHRTCDSQR7DRANCNFSM4RKRSC3A> .

[MarDiehl]

@urbanjost: I agree with @arjenmarkus, relying on certain extensions is not a good long-term strategy. When os/os_path works on Windows (Cygwin, MinGW, and MSYS) and on POSIX (currently tested on Mac OS and Linux), it should be straight forward to include other system routines from C. We (i.e. mainly @arjenmarkus) almost found a suitable setup that works on all OS flavors.

[urbanjost]

I have a list of methods for handling platform-specific options. One of the easiest that does not require a preprocessor is to use a generic name like my_routine and then have a directory for each platform that has a source for my_routine. Instead of a preprocessor you just select the correct directory to build. If each solution contains very similar code or if there is a strong reason for keeping all the code in a single file a preprocessor can be more appropriate. I generally use POSIX platforms and have found the ISO_C_BINDING interface to work very well on Mac/CygWin/Unix/GNU-Linux; and in a few cases on windows I was able to make C routines that looked like the POSIX routines that called the MSWindows equivalents. I do not know of a public version of a POSIX look-alike for MSWindows like CygWin provides but that would be very useful if it exists.

Some Fortran extensions are so common they are as standard as the standard implementation is itself; CHDIR seems to fall in or close to that. It would seem like a low maintenance issue to make a wrapper library that had something like STDLIB_CHDIR in it that called the vendor routine if it existed. If it did not call a ISO_C_BINDING to the POSIX routine if the platform is POSIX, and then a custom solution. In general it would seem reasonable to use vendor extensions if they exist behind such a wrapper and leave the maintenance to the compiler supplier.

[arjenmarkus]

Well, that is the solution we have chosen now: different source code, selected per platform, where CMake does the actual selection. So, we are working along the same lines here - the details may differ, but that is all. Op vr 20 nov. 2020 om 03:17 schreef urbanjost <notifications@github.com>:

…

I have a list of methods for handling platform-specific options. One of the easiest that does not require a preprocessor is to use a generic name like my_routine and then have a directory for each platform that has a source for my_routine. Instead of a preprocessor you just select the correct directory to build. If each solution contains very similar code or if there is a strong reason for keeping all the code in a single file a preprocessor can be more appropriate. I generally use POSIX platforms and have found the ISO_C_BINDING interface to work very well on Mac/CygWin/Unix/GNU-Linux; and in a few cases on windows I was able to make C routines that looked like the POSIX routines that called the MSWindows equivalents. I do not know of a public version of a POSIX look-alike for MSWindows like CygWin provides but that would be very useful if it exists. Some Fortran extensions are so common they are as standard as the standard implementation is itself; CHDIR seems to fall in or close to that. It would seem like a low maintenance issue to make a wrapper library that had something like STDLIB_CHDIR in it that called the vendor routine if it existed. If it did not call a ISO_C_BINDING to the POSIX routine if the platform is POSIX, and then a custom solution. In general it would seem reasonable to use vendor extensions if they exist behind such a wrapper and leave the maintenance to the compiler supplier. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#172 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN6YR5XWTGI7F3CKG45UODSQXGUPANCNFSM4RKRSC3A> .

[ivan-pi]

Can we define some rules for how fpm is to stop the search?

When I run git status in a folder inside WSL which is not a repository I get the following fatal error:

$ git status
fatal: not a git repository (or any parent up to mount point /mnt)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

The environment variables which affect git can be found here.

[LKedward]

Implemented in #483.