Curious problem with CMake - related to the Feq-parse project

Help
1

I have been experimenting with the feq-parse project by @fluidnumerics_joe and stumbled on some peculiarities. One of them is that the Visual Studio solution that I created via CMake fails to build in one go. The first time the compiler complains about four source files in the test directory whereas it is happy with all the others there. The complaint is that the module file for FEQparse is not found. But it is apparently found for all the others. After building a second time it works fine.

The problem is: all the options are equal for all the files in the test directory. I can find no reason whatsoever for that behaviour wrt the four files. I suspected first something regarding parallel builds and race conditions, but as the set of files about which the compiler complains is always the same, I very much doubt this is the cause.

Does anyone have any idea where to look for the problem (or rather the solution)?

2

Same problem with fpm test:

$ fpm test
 + mkdir -p build/dependencies
FEQParse_Functions.F90                 done.
FEQParse_FloatStacks.F90               done.
FEQParse_TokenStack.F90                done.
test.f90                               failed.
[  2%] Compiling...
abs_r1fp32.f90:3:7:

Fatal Error: Cannot open module file ‘feqparse.mod’ for reading at (1): Aucun fichier ou dossier de ce type
compilation terminated.
<ERROR> Compilation failed for object " test_test.f90.o "
<ERROR> stopping due to failed compilation
STOP 1
$ fpm test
FEQParse.F90                           done.
test.f90                               done.
libfeq-parse.a                         done.
linear_r2fp64.f90                      done.
sin_r2fp32.f90                         done.
sech_sfp64.f90                         done.
log_r2fp64.f90                         done.
sqrt_r2fp64.f90                        done.
gaussian3d_r3fp32.f90                  done.
asin_r3fp64.f90                        done.
...
3

Hm, thanks for this! It is a different file, but there does seem to be a dependency issue, which is independent of the build method (no pun intended).

1 Like
4

Could it be related to those include statements in test/tests.f90 ? :

...
    contains

    include "abs_r1fp32.f90"
    include "abs_r1fp64.f90"
    include "abs_r2fp32.f90"
...

Each test file has a use FEQParse.

5

Hm, my guess is that fpm does not see the dependency via the included files. Could be fixed by adding a use statement in test.f90. In the VS case I get a complaint for four source files and not for all the other ones. Each is compiled independently.

1 Like
6

Yes, it then works with fpm.

7

@vmagnin - what does your build environment look like ?

fpm test passes currently on Linux with gfortran : [WIP] Bugfix/issue 12 · FluidNumerics/feq-parse@f2a52a4 · GitHub

8

GFortran 12.3, Ubuntu 23.04 with :

$ fpm --version
Version:     0.8.2, alpha

I will try to upgrade to fpm 0.9.

9

No, same problem with fpm 0.9.0.

10

It’d be helpful to see any verbose output from FPM… however, from this output it looks like src/FEQParse.F90 is not compiled on the first go-around. If you run fpm install followed by fpm test, I suppose it would work ?

11

@vmagnin - I’ve added the use FEQParse statement to the top of test.f90 in the bugfix/issue-12 branch branch; this does cause fpm to build src/FEQParse.f90 before any of the tests in test/ .

@Arjen - what version of CMake are you working with ?

1 Like
12

@Arjen - I’ve added a fix to the bugfix/issue-12 branch that forces a dependency of the ${TARGET}_fortran target on the feqparse-static target which will guarantee that everything in src/ is compiled before starting on building anything in test/

13

Yes, that is the problem when running fpm test first.

When running first fpm install (or fpm build), src/FEQParse.F90 is immediately built:

$ fpm install
 + mkdir -p build/dependencies
FEQParse_FloatStacks.F90               done.
FEQParse_Functions.F90                 done.
FEQParse_TokenStack.F90                done.
FEQParse.F90                           done.
libfeq-parse.a                         done.
array_with_array_eval.f90              done.
array_with_scalar_eval.f90             done.
scalar_with_scalar_eval.f90            done.
scalar_function_product.f90            done.
array_with_array_eval                  done.
array_with_scalar_eval                 done.
scalar_with_scalar_eval                done.
scalar_function_product                done.
[100%] Project compiled successfully.
# Update: build/gfortran_50F62D7499E64B65/feq-parse/libfeq-parse.a -> /home/vmagnin/.local/lib
 + mkdir -p /home/vmagnin/.local/include
# Update: build/gfortran_87E2AE0597D39913/feqparse_floatstacks.mod -> /home/vmagnin/.local/include
# Update: build/gfortran_87E2AE0597D39913/feqparse_functions.mod -> /home/vmagnin/.local/include
# Update: build/gfortran_87E2AE0597D39913/feqparse_tokenstack.mod -> /home/vmagnin/.local/include
# Update: build/gfortran_87E2AE0597D39913/feqparse.mod -> /home/vmagnin/.local/include
$ fpm test
random_r3fp32.f90                      done.
sech_r2fp64.f90                        done.
tanh_r2fp64.f90                        done.
monadic_r4fp64.f90                     done.
linear_r1fp32.f90                      done.
...
1 Like
14

I believe the issue with fpm is linked to: source pre-processing prior to determining dependencies · Issue #469 · fortran-lang/fpm · GitHub

fpm would need to analyse the included files to determine that the main program depends on the FEQParse module indirectly via the contained subroutines.

1 Like
15

The addition of the add_dependencies statement helped. It now builds fine with Visual Studio.

2 Likes
16

Also got this resolved with fpm, thanks to @vmagnin 's suggestion.

2 Likes