Bootstrap submodule support

[everythingfunctional]

This implements support for submodules in the Haskell (bootstrap) version of fpm. A quick note that this removes any requirements or restrictions on naming conventions for modules and source files. Those could in theory be added back in as explicit checks somewhere.

Additionally, this should now work with multiple programs in the same folder. I haven't really tested that yet, but it should work.

[awvwgk]

There are binary files checked into this branch, (several object files, some submodule files and an archive). Those should be removed from the commit history.

[everythingfunctional]

There are binary files checked into this branch, (several object files, some submodule files and an archive). Those should be removed from the commit history.

Not sure how I missed that. Fixed.

[LKedward]

Great stuff @everythingfunctional! I've played around with it and everything is working as expected! Nice to see non-interface changes don't propagate to child submodules as you discussed. Also glad the example packages have been moved to repo root, this is a better location for them.

I'm not qualified to make specific comments on the Haskell code, but the new unit tests look sound and I haven't been able to break any of the parsing. 👍

[certik]

Great work, thank you.

Why were tests moved out of the tests directory directly into top level? I would like to have a tests directory I think.
In general, the PR would be a lot easier to review if such unrelated changes were not done in the same PR.

Consequently, I hope I didn't miss it, it seems there is no test for submodules in the (no removed) tests directory. I think there might be a test for this in the Haskell version, but I think we should strive for providing tests in the tests directory, so that the Fortran version can reuse them.

[everythingfunctional]

@certik , I moved the examples out of the tests folder, because I thought it strange that they were in the fpm/tests folder, but were still used (and in fact there was a softlink) by the bootstrap version. Also, I find the examples as useful for more than just testing the code; they are examples of how one might organize their own projects to work with fpm, and should thus be much more prominently available (i.e. at the top level). We could put a softlink in the tests folder if you like.

[awvwgk]

Works quite robustly, nicely done.

[LKedward]

The example packages are more useful as demonstrations of the capabilities of fpm to potential and existing users/developers than as actual tests. We need them currently for end-to-end regression testing but their usefulness to identify bugs or general regressions is quite limited.

[certik]

It's useful to have examples, no doubt. But more importantly we need tests. I thought these were a good start. How should our testsuite look like?

…

On Sat, Oct 24, 2020, at 3:32 AM, Laurence Kedward wrote: The example packages are more useful as demonstrations of the capabilities of fpm to potential and existing users/developers than as actual tests. We need them currently for end-to-end regression testing but their usefulness to identify bugs or general regressions is quite limited. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#213 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAFAWHVVXOXRFLUUPBWY2DSMKNLJANCNFSM4S3TGKWA>.

[LKedward]

It's useful to have examples, no doubt. But more importantly we need tests. I thought these were a good start. How should our testsuite look like?

Yes, I certainly didn't mean to imply that examples are more important than tests. Rather, I want to point out that we already have a fairly comprehensive set of unit tests which give much better code coverage and diagnostic capability than building the example packages (though I agree that we absolutely still need to do this for end-to-end and regression testing).

---

I would like to have a tests directory I think.

The reason this test directory isn't in the root directory is because fortran fpm is in a sub-directory - this doesn't need to be the case. Indeed, fpm assumes other fpm packages exist in the top-level directory, why should fpm be any different? We can still keep the bootstrap version separate in a sub-directory.

[everythingfunctional]

Glad you guys are happy with the new functionality. Is there anything more you would like done in this PR before merging in?

[LKedward]

+1 to merge from me!

[everythingfunctional]

Ok, with 3 approvals I'm going to go ahead and merge. Feel free to create an issue and tag me if you'd like additional changes after.