Push stdlib version to the stdlib-fpm branch

[perazz]

Motivation

Hello stdlib developers,

apologies I'm no stdlib expert yet.

I think it would be fantastic to soon see tighter/full integration of stdlib in fpm, meaning, that fpm could enable stdlib as a meta-package with basically no user input (like any C/C++ compiler does for their stdlibs).

I see that the CI does some minimal cleanup of the sources before pushing to the stdlib-fpm branch. I would like to:

• ask whether there is any interest in it?

• ask for feedback about whether any of those pre-processing steps could instead be replaced with more advanced source handling in fpm;

• fpm.toml does not store a VERSION, is that by design? otherwise, I'd like to suggest a PR that pushes it on deployment:

stdlib/fpm.toml

Lines 1 to 10 in 261a627

	name = "stdlib"
	version = "VERSION"
	license = "MIT"
	author = "stdlib contributors"
	maintainer = "@fortran-lang/stdlib"
	copyright = "2019-2021 stdlib contributors"
	[dev-dependencies]
	test-drive.git = "https://github.com/fortran-lang/test-drive"
	test-drive.tag = "v0.4.0"

Prior Art

No response

Additional Information

No response

[jvdp1]

I totally agree with you.
During the GSoC 2022, @arteevraina, together with @awvwgk, worked on supporting preprocessing with fpm which would enable fpm to compile stdlib. See this PR for more details. Once preprocessing is supported by fpm, it should be able to fully compile stdlib.

[arteevraina]

Motivation

Hello stdlib developers,

apologies I'm no stdlib expert yet.

I think it would be fantastic to soon see tighter/full integration of stdlib in fpm, meaning, that fpm could enable stdlib as a meta-package with basically no user input (like any C/C++ compiler does for their stdlibs).

I see that the CI does some minimal cleanup of the sources before pushing to the stdlib-fpm branch. I would like to:

• ask whether there is any interest in it?
• ask for feedback about whether any of those pre-processing steps could instead be replaced with more advanced source handling in fpm;
• fpm.toml does not store a VERSION, is that by design? otherwise, I'd like to suggest a PR that pushes it on deployment:

stdlib/fpm.toml

Lines 1 to 10 in 261a627

	name = "stdlib"
	version = "VERSION"
	license = "MIT"
	author = "stdlib contributors"
	maintainer = "@fortran-lang/stdlib"
	copyright = "2019-2021 stdlib contributors"
	[dev-dependencies]
	test-drive.git = "https://github.com/fortran-lang/test-drive"
	test-drive.tag = "v0.4.0"

Prior Art

No response

Additional Information

No response

Yes, long term goal is to build stdlib using fpm without any external build script. So, basically we need to natively support fypp preprocessing inside fortran package manager.

[perazz]

I've added the stdlib deployment as a metapackage in fpm. It's not merged yet but it can be played around with from my fork. Basically, to use stdlib it's enough to turn that on in the fpm manifest as a metapackage:

[metapackages]
stdlib = true

[beddalumia]

Since the metapackages feature has been merged in fpm (last week, details here) the old way of including it as a dependency in the toml manifest does not work anymore.

I.e. a code line as described in the current README would result in a fpm error, for fpm ≥ 0.9.0

stdlib/README.md

Lines 198 to 199 in 0efc112

	[dependencies]
	stdlib = { git="https://github.com/fortran-lang/stdlib", branch="stdlib-fpm" }

Apparently the new definitive (=merged) way would be

[dependencies]
stdlib = "*"

and I checked it works on my machine, with my fpm package. Though I cannot (have no time to) understand the details of the new way, as much as to propose my own edit to the README. In particular I could not figure out the exact meaning of the asterisk or if it can be replaced with an exact version, from the fpm documentation. @perazz you're probably the one that most efficiently can answer all of this and maybe update the stdlib readme accordingly, so to allow people on the latest fpm release to build packages depending on stdlib without accidents.

(Feel free to move to a new issue, if the case). :)

[perazz]

@bellomia there is an outstanding patch for this issue in the pipeline at fortran-lang/fpm#928.
It reinstates the option to use a standard dependency strategy for all (otherwise) reserved metapackage keywords

[beddalumia]

Oh wow, very nice (especially for developing with personal forks etc). Thanks for the quick prompt. (and good job! quite in love with openMPI and MPICH being metapackages now <3)