Fix -fPIC for C sources
Issue #1205 highlighted that the fPIC, necessary for shared libraries, was not passed for C sources either with profile release or debug.
For CFLAGS, a hot fix was applied i.e. the flag is hard-coded 353ec2372eb67af3710d1e9b09af224226d97487.
Equivalent function of fpm_compiler.F90/get_<debug/release>_compile_flags should be implemented for pulling default flags for C sources as it is the case for Fortran sources.
The FFLAGS are hard-coded both profiles (release and debug) in feature_collection/default_<release/debug>_feature(). However, it might better to pull from default compile flags defined in fpm_compiler.F90/get_<release/debug>_compile_flag (cb7d15c0a222e999695e313e2e00d079e0aa3c6e)
That's what I wanted to do by adding optional arguments. I'll try to find all the adequate fPIC equivalents for the corresponding platforms.
I have generalized default_variant and set the c_flags + cxx_flags to values that I think correct. Might need to be revised by somebody that knows compilers very well. My knowledge is limited to gfortran and gcc.
You will find explanations of what I did in the description of the last 4 commits.
@jvdp1 @perazz Can I do something to try to solve the issue with metapackage-tests?
I see why it crashes. the "dev" version of fpm parses cpp macros. Hence if a macro is not "officially" defined by fpm (i.e. in case of stdlib it has not been included in the stdlib-fpm fpm.toml), the use statement guarded by #ifdefs will be skipped -> missed source file dependency. So as stated in the stdlib discussion, perhaps it was necessary to add hte build macros to the library's fpm.toml
@perazz I am not sure to understand your comment. Should the issue be resolved in fpm or in stdlib (or in both)?