-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Projects including legacy files #107
Comments
I was playing around with gtk-fortran and I found a work-around for non-module sources by renaming them to It's not ideal and I'm not sure what the plan is for supporting non-module sources but I think they should be supported in some form. Perhaps the larger question is whether we will make |
At the moment, @LKedward , clever workaround. I may even suggest that as a recommended migration path. In the mean time, there is always the out that |
We have to support non-module sources. But this might be a feature to put into the Fortran based fpm to keep the Haskell based on minimal to be used in bootstrapping. |
I've been trying to get fpm to work with some old-school packages like MINPACK: https://github.com/certik/minpack. These projects are generally just a bunch of fixed format ".f" files. For modern applications that rely on such legacy codes, an interface module is the first step towards safe function calls.
Trying to run
fpm build
on @certik's MINPACK fails with errors akin to:I understand that fpm is expecting to find a module file for each single ".f" file. Is it possible to somehow work around this? The farthest I could get it in the fpm source was to remove to the "-Wimplicit-interface" flag which was creating lots of warnings 🙈 .
Am I right to think fpm is currently most suitable for projects composed of multiple module files?
The text was updated successfully, but these errors were encountered: