-
Notifications
You must be signed in to change notification settings - Fork 108
Publish version to within fpm #865
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I strongly believe that this is not the way to go. To export the version from the from must not rely on an external script, rather fpm should support generating a module like this intrinsically.
I understand @awvwgk, what is your piece of advice? You mean fpm should generate that module file and add it somewhere as a dependency to the child fpm build? That's of course feasible, maybe easier than with a bash script, but it would have to read the version and commit ID starting from a CI variable or pre-processing script anyways? |
That's probably a longer discussion. To export the version from only needs to know the manifest and we already have a preprocess table to forward a version number macro. Generally I don't see any good reason to pick up the version number from a VCS tag, stuff like setuptools-scm introduce quite some edge cases in the Python ecosystem already. |
fpm.toml
Outdated
[preprocess] | ||
[preprocess.cpp] | ||
macros=["FPM_VERSION={version}"] | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The following update passes version from the manifest into fpm as a preprocessed macro @awvwgk. I like this way, but it cannot be built (fpm 0.3.0 used for bootstrapping). Should we update fpm to 0.7.0 in the bootstrapping action?
Then let's make a new release 0.7.1 which picks the bugfix or a new feature release 0.8.0 |
echo ${{ env.VERSION }} | ||
|
||
- name: Get manifest version | ||
run: | | ||
MANIFEST_VERSION=$(grep version fpm.toml | head -1 | tr -d ' ' | tr -d 'version=') | ||
echo "MANIFEST_VERSION=${MANIFEST_VERSION}" >> $GITHUB_ENV | ||
echo ${{ env.MANIFEST_VERSION }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using pre-processing flags, there are a couple more steps with the single-file-version:
- the single-source-file version is not built with fpm, so we need to first query the manifest version into a variable,
.github/workflows/release.yml
Outdated
# We need to pass the exact version string that a fpm build command would send | ||
echo "#define FPM_RELEASE_VERSION ${{ env.MANIFEST_VERSION }}" > fpm-${{ env.VERSION }}.F90 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- manually set a preprocessor flag.
src/fpm/fpm_release.f90
Outdated
! Accept solution from https://stackoverflow.com/questions/31649691/stringify-macro-with-gnu-gfortran | ||
! which provides the "easiest" way to pass a macro to a string in Fortran complying with both | ||
! gfortran's "traditional" cpp and the standard cpp syntaxes | ||
|
||
#ifndef FPM_RELEASE_VERSION | ||
# define FPM_RELEASE_VERSION UNDEFINED | ||
#endif | ||
|
||
#ifdef __GFORTRAN__ /* traditional-cpp stringification */ | ||
# define STRINGIFY_START(X) "& | ||
# define STRINGIFY_END(X) &X" | ||
#else /* default stringification */ | ||
# define STRINGIFY_(X) #X | ||
# define STRINGIFY_START(X) & | ||
# define STRINGIFY_END(X) STRINGIFY_(X) | ||
#endif | ||
|
||
character (len=:), allocatable :: ver_string | ||
ver_string = STRINGIFY_START(FPM_RELEASE_VERSION) | ||
STRINGIFY_END(FPM_RELEASE_VERSION) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Finally, gfortran needs some pretty verbose preprocessing, even just to pass along a string, because it uses the "traditional" version of the cpp preprocessor
I believe this is completed. @henilp105 @arteevraina @minhqdao @awvwgk @certik if any of you needs this merged before the weekend, please review it and do it yourself, I'll be back on Tuesday. Happy Easter! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @perazz , Looks good to me.
I would like to merge this one so we can publish the fpm version to the model dump (#879). I will wait another day or so and if there are no further requests, will go ahead and merge. |
Thank you @henilp105, I will merge this one. |
Addressing #855: for metapackages and registry handling, fpm must know what version is running.
I think there are two main ways of doing this:
In both cases, a CI script needs to keep this version up to date.
I like option 3) better because it's not compiler dependent, and once the repo is deployed, there's no way to change it, it's inside the source code. So here's what I think may work:
Extract version from
git
in the wake of what LFortran does: 09d09e1Have all fpm include files inside
include/
, so they're excluded from the build: c9a35daI think none of these
parameter
s should be public, just operate withversion_t
within fpm 44b0a2aIf there's consensus on this way forward @certik @awvwgk @urbanjost @fortran-lang/admins, please let me know and I can complete the CI and the tests! I would then address fpm version requirements as a separate PR.
cc: @arteevraina @henilp105 @minhqdao