Fpm: Provide single source file fpm versions via CI workflow

[awvwgk]

Should be a fun, little task to setup a CI workflow to collect all the source files into a single file release version of fpm and upload it to the release tag.

[milancurcic]

This could be a nice fpm plugin too, perhaps fpm-singlefile. CC @urbanjost @brocolis

[awvwgk]

I hacked a bash script together which wraps gfortran (like @urbanjost suggested in a post a while ago) and appends all the source files to a single one before invoking the compiler. A plugin is way more work.

Here are all versions of fpm so far:

• fpm-0.1.0.f90.gz
• fpm-0.1.1.f90.gz
• fpm-0.1.2.f90.gz
• fpm-0.1.3.f90.gz
• fpm-0.1.4.f90.gz

[urbanjost]

A plugin would be nice to be a fortran program, but just has to be an executable. Rename your script "fpm-singlefile" and using the proposed plugin PR just enter "fpm singlefile" (with maybe a version or branch option) in the fpm(1) repository if the script does not pull it. Mine is called "fpm-singularity" and also uses a bash script, but I did not plan on publishing it. Will not work in an environment without bash(1), of course; but technically just one person or process has to run it and put the files out. It creates a scratch directory and actually builds it (the scratch directory makes it a lot easier to clean up the *.mod files) and then moves the binary and single source file back up to the top directory so it verifies the build compiles and makes a matching binary as well; it probably should insert the license file at the top but does not. Weird how simple it is to build with just a "gfortran fpm-0.1.4.f90 -o fpm-0.1.4" is it not? Cannot say there is a compelling reason to make it a plugin because most people will not run it(maybe wrong about that), but I renamed mine and a few other commands (avpgk before it was named "fpm-search", the fan(1) program to "fpm-man", tcboo (There Can Be Only One, another inside joke) to "fpm-singularity" and so on for tests and ended up liking it that way) :>. Is that already done with a CI? I have not done anything with that yet. Been thinking I wanted to add running "fpm test" runs to my fpm packages and wanted to look into that. Using your single-file sources might make that a lot easier than I thought.

[milancurcic]

Cannot say there is a compelling reason to make it a plugin because most people will not run it

Maybe not, but IMO that's the point of a plugin--something that fits the theme of fpm but is not commonly enough used to warrant being a built in.

[urbanjost]

good point. Seems like there should be at least three repository types -- fpm developer packages, fpm plugins, and applications buildable via fpm. So if I wanted to add something like fpm-plugin that searched the "plugin" repository and added plugins I could do something like "fpm plugin search" and add the "fpm-search" command. Not all plugins would have to be fpm packages though (like fpm-singlefile being a bash(1) script) so I do not know if some other kind of package manager might be needed; but wondering whether "fpm-search" and related commands will be bundled with fpm directly or how that might work; but right now the only things in the fpm repository are libraries; but some packages are potentially just apps; some would mix apps and libraries; some apps would be designed to be plugins or fpm-related tools; ... probably some other package managers have the same issue. Looking to see if other software package managers have different searchable repos or if apps and plugins are stand-alone tools, etc; it makes me wonder if there is a best or even common approach to that. And of course, a registry of registries ...

[awvwgk]

I'm totally fine to solve this with a hacky bash script, as @urbanjost pointed out we only need a single task to run it and this could be a Linux runner with GitHub actions automatically. Also, I don't think there is interest in a long-term solution for such a feature in fpm or a plugin, it's just a neat trick for bootstrapping that happens to work now.

[LKedward]

I agree, it would be nice to get a single-source file uploaded alongside the binaries. I needed to use one of @urbanjost's single-file versions to bootstrap fpm on one of our older clusters that didn't have a new enough version of glibc for the uploaded binaries — it worked a charm!

When we start incorporating c code, a possible replacement could be a self-extracting shell script using something like makeself for example.

[awvwgk]

I attached the single source versions to the existing releases to make them easier available.

[milancurcic]

@awvwgk Sorry for the confusion, I need to clarify, a hacky bash script is just fine. My proposal for plugin I didn't mean as solution for this specific issue (fpm in CI), but as an idea for long term.

[urbanjost]

makeself -- shades of shar(1)!. shar(1) (which was similar to makeself(1)) used to be used all over the place but slowly faded away as far as I know. Interesting. Could not even find shar(1) via apt-get; but I still see man-pages in a quick search for it so it is still out there somewhere. Used to have my own version that encrypted all the files (long story).

A have actually used my version of a single-file script to build sources for several pure-fortran apps I built with fpm(1) that someone wanted on a machine quickly without having to set anything else up and that worked; but with two other fpm(1) packages that also had "co-C" components I used a makefile(1) generator and tarred up the files but fpm seems so close to being able to do that automatically I did that as one-offs.

The makefile(1) generator I used does not like it if everything is not in a single directory so I had to flatten a copy of the package before running it but it only took a few minutes; but they were relatively small packages.

I have toyed with using the output of the model from --show-model to make some plugins that generate CMake and make setups of a package as prototypes but so far have not seen enough to justify it for my own needs, but thought from a few other conversations that it is already in other's plans to do that in the core fpm(1). Is this a high priority for others (and if so, is anyone working on it?). Using fpm(1) directly for small projects has been working quite well, so except for a few minor exceptions that I noted I have not personally had much need to export to anything else lately; albeit there are some projects I knew would not be good fits for fpm(1) currently that I built using previous methods.