Update manual makefiles

[milancurcic]

This PR:

• Removes old (dummy) source files mod_stdlib.f90 and test_dummy.f90
• Updates manual Makefiles so they build the library and tests
• Updates the README to include build instructions with CMake or manual Makefiles

[milancurcic]

Considering #48, can we rename Makefile.manual to just Makefile and require out-of-source builds for CMake? This would do away with having to make -f Makefile.manual which is quite tedious.

[certik]

I use in tree builds often. Since most users would presumably use cmake, is there a problem keeping the Makefiles as is? I think both in tree and out of tree builds are very useful.

…

On Thu, Dec 26, 2019, at 4:36 PM, Milan Curcic wrote: Considering #48 <#48>, can we rename `Makefile.manual` to just `Makefile` and require out-of-source builds for CMake? This would do away with having to `make -f Makefile.manual` which is quite tedious. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#46?email_source=notifications&email_token=AAAFAWFIFRFVXL7U2O7PVALQ2U5YTA5CNFSM4J7A2Y6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHWIWXA#issuecomment-569150300>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAFAWF3FXBWSGLGQXLSNR3Q2U5YTANCNFSM4J7A2Y6A>.

[milancurcic]

No problem, it's just verbose. I normally use CMake, and manual Makefiles only when I update them, i.e. this PR.

I realize now that this may even serve to motivate using CMake, for those who are on the fence.

[certik]

It's verbose, but if we rename, then in tree cmake builds overwrite them, and the git wants to commit those changes which is really annoying with no easy fix, as cmake doesn't allow to rename the generated makefiles.

…

On Thu, Dec 26, 2019, at 5:27 PM, Milan Curcic wrote: No problem, it's just verbose. I normally use CMake, and manual Makefiles only when I update them, i.e. this PR. I realize now that this may even serve to motivate using CMake, for those who are on the fence. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#46?email_source=notifications&email_token=AAAFAWHXFWO3YDFVVE5SB63Q2VDWZA5CNFSM4J7A2Y6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHWJ6XY#issuecomment-569155423>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAFAWEQVTUDTB64K3LNOJLQ2VDWZANCNFSM4J7A2Y6A>.

[zbeekman]

Relevant to the discussion in #50: do we want to maintain (test) in source and out of source CMake builds. Out of source is cleaner IMO, and less error prone, but I don't care that much other than pointing out that this is yet another combinatorial expansion of build systems beyond maintaining CMake in parallel to Makefiles, now we need to maintain (i.e., test) in source builds and out of source builds. This seems like unnecessary complexity to me.

[zbeekman]

In general: LGTM.

I'm an advocate for defaulting to out-of-source CMake builds because I think there are fewer issues to bite the developer and user, and cleanup is super easy. So I made that one suggestion.

[zbeekman]

I'd advocate pointing people in the direction of out of source builds. There is less that can go wrong and surprise you, and cleanup is a snap.

[milancurcic]

I agree. I scratch my head every time I want to clean the top-level directory after an in-source build

[zbeekman]

LGTM, FWIW

[milancurcic]

@certik Can this be merged? We can add the tests with manual Makefiles to CI in a separate PR.

[certik]

I agree, let's merge this and improve upon it with further PRs.