stdlib compatible with fpm

[jvdp1]

During the December call, @ivan-pi mentioned it would be nice that fpm could use stdlib as a package.

@certik mentioned that a possible solution would be to provide a tarball with pre-processed fypp files (similarly to the generation of binaries for fpm). This option requires that fpm being able to use tarballs.

@LKedward proposed another solution, that is an auto-generated mirror of stdlib that contains pre-processed files (see @LKedward project).

Both options have pros and cons. In both cases, I think the strucutre of stdlib must be modified to be compatible with the structure needed by fpm.

[urbanjost]

Yes. Ideally, it should require no preprocessing. The fpm package should just be .f90 files and .c files. That is probably not
possible, but if it could be done with a "MSWindows-stdlib" and a "Everyone Else" that would be great, where there are routines that will run anywhere, and then a separate directory expanded out for the special platform variations. If that is not feasible, the distributed code should contain only simple conditionals (no macros) and a simple fpp(1) program, preferably written in Fortran, should be bundled for use with fpm and fpm should provide a few defined values like OSTYPE and COMPILER. @LKedward put out an fpm package for stdlib, but I believe he did so as an alpha-release proof-of-concept.

I think it should be far more a two-way street than it is, as I think the bar is too high for some people to be interested in stdlib.
stdlib should be supporting people working together on a github+fpm prototype for some of the libraries where I think people
can more easily try out tough ideas and compare and test using much more typical steps until a prototype solidifies enough to start the process of becoming part of stdlib. That is, a domain-specific module can garner some general agreement and then be proposed as a more complete proposition (with touch-points along the way).

Right now there are several libraries, some already available via fpm that people can try and discuss, and hopefully merge into a stdlib proposal, such as random numbers, strings, Gregorian calendar, ... . Adding them piecemeal and without a defined overall scope into stdlib seems like it has been problematic so far. Essentially, spin-off mini-projects that can be worked on by an interested subgroup that would still be highly available to the general community (via a git repository and fpm) that would require only building that subset.

stdlib should be available via fpm, and an fpm-based process should exist with a defined pathway into stdlib. Assuming
some buy-in by owners of existing libraries I think that might speed things up. Ironically, stdlib seems to be running around the same speed as the standard committee. I think that is closer to the successful modules that have appeared around recent Open Source languages and deserves a closer look.

[LKedward]

Thanks for opening @jvdp1. Preprocessing aside, the main restructurings necessary for stdlib-fpm were moving the tests folder out of the library src folder and some consideration of the .dat files needed by the tests.

There's been some discussion on the issue of passing inputs to tests; currently the path to .dat files must be relative to the top level directory, hence these files are trivially relocated there in my stdlib-fpm package.

Finally I want to emphasis that support for preprocessors remains a definite goal for fpm. Unfortunately the implementation is complicated slightly by how it interacts with the detection of module dependencies.

[jvdp1]

Thanks for opening @jvdp1. Preprocessing aside, the main restructurings necessary for stdlib-fpm were moving the tests folder out of the library src folder and some consideration of the .dat files needed by the tests.

I don't remember the reasons that tests was inside src in stdlib. However, would it not be easier to move tests in stdlib to follow the structure needed by fpm? For a new user, it could sound strange that the structure of stdlib does not follow the structure needed y fpm, although both projects are fortran-lang projects.

Finally I want to emphasis that support for preprocessors remains a definite goal for fpm. Unfortunately the implementation is complicated slightly by how it interacts with the detection of module dependencies.

fpm should definitely support preprocessing. However, I think it would be good that a tarball (or a repository) with generated files is available for users who don't want to install,e.g., fypp.

[milancurcic]

See #7 for how the current structure was chosen. I agree that it should move to fpm-recommended structure.

[awvwgk]

This is resolved now.