Fpm: Haskell fpm cannot build stdlib

[awvwgk]

Trying to use stdlib (https://github.com/LKedward/stdlib-fpm at commit eadc8ad5eaf182adee04f1bd31624ad19b9eaf2c) for fpm yields the following error in Haskell fpm:

fpm: Error when running Shake build system:
  at want, called at src/Build.hs:167:11 in fpm-0.1.0.0-5jx9ZzGZ9Bb3Rtenr4ru0y:Build
* Depends on: build/gfortran_30e5626f04e0df84_2a4c534d3ee9fc79/stdlib/libstdlib.a
  at undefined, called at src/BuildModel.hs:108:16 in fpm-0.1.0.0-5jx9ZzGZ9Bb3Rtenr4ru0y:BuildModel
  at error, called at libraries/base/GHC/Err.hs:78:14 in base:GHC.Err
* Raised the exception:
Prelude.undefined

This is a major blocker for using stdlib in Fortran fpm.

[awvwgk]

@everythingfunctional Do you have any pointers on what is throwing up the Haskell version here?

[everythingfunctional]

Does stdlib have source files that don't have a program, module or submodule? The error is coming from this line, which is at the end of an if-else chain. The Haskell model of a project assumes that each file contains one (and only one) program, module or submodule. It could be extended to allow for files that contain multiple (or even no) programs, modules and/or submodules, but if the Fortran version works I don't feel much urgency in actually doing it given how close we are to being able to have fpm no longer relying on it (i.e. #253). I could be persuaded if there is a good reason to do so.

[LKedward]

Apologies, I think this is due to an empty source file common.f90 that's been included in stdlib-fpm by mistake. Removing it appears to fix the problem for me.

[LKedward]

Okay not quite fixed, there's another issue :-/

[LKedward]

Okay, so the second problem is that stdlib_bitsets is using the use :: syntax (with double-colons) which isn't supported by the Haskell implementation. Replacing it fixes the problem.

Edit: I've added a patch to stdlib-fpm; the most recent version now builds with both Fortran and Haskell implementations of fpm in the CI.

[awvwgk]

@LKedward Thanks for working around these issues. Should any of those changes get upstreamed to stdlib?

[LKedward]

Perhaps the instance of use :: stdlib_kinds should be replaced with use stdlib_kinds for consistency across stdlib, but otherwise the changes are really just workarounds for compatibility with Haskell fpm and so don't necessitate upstreaming.