# Building FPM from source on Windows 10 **URL:** \ **Category:** Help\ **Created:** [July 4, 2021, 6:58pm UTC](https://fortran-lang.discourse.group/t/building-fpm-from-source-on-windows-10/1512 "2021-07-04T18:58:25Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![R\_cubed](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/r_cubed/32/263_2.png) [@R\_cubed](https://fortran-lang.discourse.group/u/R_cubed)\ **Post date:** [July 4, 2021, 6:58pm UTC](https://fortran-lang.discourse.group/t/building-fpm-from-source-on-windows-10/1512/1 "2021-07-04T18:58:25Z")
I’m reading the instructions for the FPM package manager and was wondering what the procedure was to build from source directly from git? I have the most recent sources locally, but it isn’t clear from the shell script what I need to do to get this to compile on Windows using gfortran. Any advice? ---
**Author:** ![awvwgk](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/awvwgk/32/154_2.png) [@awvwgk](https://fortran-lang.discourse.group/u/awvwgk)\ **Post date:** [July 4, 2021, 7:24pm UTC](https://fortran-lang.discourse.group/t/building-fpm-from-source-on-windows-10/1512/2 "2021-07-04T19:24:02Z")
Building fpm from the git repository head is usually a two-step bootstrap process, since fpm is build with fpm itself. Therefore, to build fpm from the git source you first have to get a fpm version from somewhere. There are several ways to get an initial fpm version: - download a statically linked Windows binary from the [release page](https://github.com/fortran-lang/fpm/releases/download/v0.3.0/fpm-0.3.0-windows-x86_64.exe) - download a single-source version from the [release page](https://github.com/fortran-lang/fpm/releases/download/v0.3.0/fpm-0.3.0.F90) and compile it with `gfortran fpm-0.3.0.F90 -o fpm` - if you using MSYS2 you can download a prepackaged version or build it yourself from [here](https://github.com/awvwgk/mingw-w64-fpm-pkgbuild) After you have your first fpm version in the `PATH` you can enter the repository root and run ```nohighlight fpm install --profile release ``` On Windows it will install to `%APPDATA%\local\bin\fpm.exe` by default. Not sure if this is the best choice on Windows, but that’s the one I put in as default there. The `install.sh` automates this two-step procedure for Unix like systems, but it might just work with git bash or the MSYS2 toolchain. ---
**Author:** ![R\_cubed](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/r_cubed/32/263_2.png) [@R\_cubed](https://fortran-lang.discourse.group/u/R_cubed)\ **Post date:** [July 4, 2021, 7:38pm UTC](https://fortran-lang.discourse.group/t/building-fpm-from-source-on-windows-10/1512/3 "2021-07-04T19:38:22Z")
Thanks. I read that section on github a number of times; I’m not sure why it didn’t click. There are a few common lisp compilers that use a similar bootstrap approach – ie. offer a reduced capability lisp kernel written in C, and use that to build the rest. Perhaps adding a phrase “bootstrapping and/or building from git” to the instructions might help? Update: @awvwgk I made some progress building from source but I still get stuck. Here is my current set up: Compiler: GCC version 10.3.0 from TDM-GCC Install PATH = $HOME\devtools\utilities\fortran I can copy that single source version and compile it. After adding the install path to my windows PATH variable, if I run your fpm install command, I get “fpm.toml cannot be found” Since I have the git sources, I tried to copy fpm.toml to the directory I compiled the bootstrap fpm source file in. I make it a bit farther. A new directory “build” gets created with cache.toml and a dependencies directory, but then I get “cannot open ‘test/cli\_test\cli\_test.f90’: no such file or directory” I wonder if I have the right version of fpm.toml. ---
**Author:** ![une](https://avatars.discourse-cdn.com/v4/letter/u/b5e925/32.png) [@une](https://fortran-lang.discourse.group/u/une)\ **Post date:** [July 5, 2021, 12:24am UTC](https://fortran-lang.discourse.group/t/building-fpm-from-source-on-windows-10/1512/4 "2021-07-05T00:24:08Z")
Hi @R_cubed. You can try this batch script ```auto rem Put required tools in PATH (git, gfortran, curl) set path=C:\Git\cmd;C:\Git\usr\bin;C:\MinGW-11.1.0-x64\bin;C:\WINDOWS\system32 git clone https://github.com/fortran-lang/fpm.git cd fpm mkdir _tmp curl -LJ https://github.com/fortran-lang/fpm/releases/download/v0.3.0/fpm-0.3.0.F90 > _tmp\fpm.F90 gfortran -J _tmp _tmp\fpm.F90 -o _tmp\fpm _tmp\fpm install --flag "-g -fbacktrace -O3" echo fpm has been installed into %appdata%\local\bin 👍 ``` ---
**Author:** ![R\_cubed](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/r_cubed/32/263_2.png) [@R\_cubed](https://fortran-lang.discourse.group/u/R_cubed)\ **Post date:** [July 5, 2021, 12:52am UTC](https://fortran-lang.discourse.group/t/building-fpm-from-source-on-windows-10/1512/5 "2021-07-05T00:52:59Z")
That looks like it worked. FPM is in my path, and I was able to build and install the FPM sources. Running fpm test gave me a message “Passed: all 11 tests passed” How do I connect my local FPM installation with this centralized repository? > **[fortran-lang/fpm-registry](https://github.com/fortran-lang/fpm-registry)** > > Centralized registry of fpm packages. Contribute to fortran-lang/fpm-registry development by creating an account on GitHub. Added: A link to setting up a development environment on Windows for those who might stumble upon this thread. > **[Setting Up Windows Fortran Development](https://everythingfunctional.wordpress.com/2021/05/26/setting-up-windows-fortran-development/)** > > If you’re just getting started with Fortran and your primary computer is Windows, figuring out how to get everything you need installed and configured can be a bit tricky. In this post I̵… ---
**Author:** ![certik](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/certik/32/4_2.png) [@certik](https://fortran-lang.discourse.group/u/certik)\ **Post date:** [July 6, 2021, 2:52am UTC](https://fortran-lang.discourse.group/t/building-fpm-from-source-on-windows-10/1512/6 "2021-07-06T02:52:07Z")
> [@R\_cubed](#): > > How do I connect my local FPM installation with this centralized repository? I believe it doesn’t work yet? But that is our plan! ---
**Author:** ![une](https://avatars.discourse-cdn.com/v4/letter/u/b5e925/32.png) [@une](https://fortran-lang.discourse.group/u/une)\ **Post date:** [July 6, 2021, 3:03am UTC](https://fortran-lang.discourse.group/t/building-fpm-from-source-on-windows-10/1512/7 "2021-07-06T03:03:39Z")
We fortran-lang community need to write the specification for fpm-registry and then implement it. Relevant issues > > > Before we make \*fpm\* aware of the \[fpm-registry\](https://github.com/fortran-lang…/fpm-registry), we should create a minimal working implementation for a local registry (this registry might even be built-in to simplify things a bit at the beginning). > > In analogy to Cargo we could use a syntax like: > > \`\`\`toml > \[dependencies\] > \[dependencies.toml-f\] > version = "^0.2.1" > registry = "internal" # or URI to a registry > \[dependencies.M\_CLI2\] > version = "^0.1.0" > registry = "default" # for whatever the default URI will be > \`\`\` > > This requires: > > 1. a way to specify and match version requirements (\`src/fpm/versioning.f90\` defines only a version type) > 2. the possibility to cache dependencies in a project (we have \`build/cache.toml\`, alternatively a lock file) > 3. a format for the registry (JSON?, TOML?, XML?, SQL?) and an \*fpm\* package implementing the format > (the fpm-registry has both TOML and JSON representations of the registry right now) > 4. an interface to fetch from URIs that are not \`local://\` or \`file://\` (libcurl interface or just shell escape to curl/wget) > > A full registry is discussed in https://github.com/fortran-lang/fpm/issues/35 > > > Right now if somebody submits a PR with a duplicate name of a new package, such …as: > \`\`\`diff > \--- a/registry.toml > +++ b/registry.toml > @@ -2,6 +2,9 @@ > "1.7.0" = {git="https://github.com/wavebitscientific/datetime-fortran", tag="v1.7.0"} > "latest" = {git="https://github.com/wavebitscientific/datetime-fortran"} > > +\[datetime\] > +"1.0.0" = {git="https://github.com/other/my\_package", tag="v1.0.0"} > + > \[M\_calculator\] > "latest" = {git="https://github.com/urbanjost/M\_calculator"} > \`\`\` > Then our CI will give an error: > \`\`\` > $ python load\_registry.py > Traceback (most recent call last): > File "load\_registry.py", line 3, in \ > d = toml.load("registry.toml") > File "/home/ondrej/miniconda3/envs/reg/lib/python3.8/site-packages/toml/decoder.py", line 134, in load > return loads(ffile.read(), \_dict, decoder) > File "/home/ondrej/miniconda3/envs/reg/lib/python3.8/site-packages/toml/decoder.py", line 477, in loads > raise TomlDecodeError("What? " + group + > toml.decoder.TomlDecodeError: What? datetime already exists?{'datetime': {'1.7.0': {'git': 'https://github.com/wavebitscientific/datetime-fortran', 'tag': 'v1.7.0'}, 'latest': {'git': 'https://github.com/wavebitscientific/datetime-fortran'}}} (line 5 column 1 char 171) > \`\`\` > > Which is great, so there will be no duplicates. > > > However, we should discuss how to handle package name conflicts. Two main options: > > 1. All package names will be made unique by prefixing them with their GitHub/GitLab organization name, so \`M\_calculator\` becomes \`urbanjost/M\_calculator\`. I believe that is what Go does. > > 2. Package names are not prefixed, and we need to provide some guidelines. We can expect a similar situation as in Rust, when people will be submitting lots of new packages with the most obvious names, such as "spline", "harmonics", "fft", "lapack" and they might not necessarily end up the most maintained. And changing a name of a package means breaking people's builds. > > > The advantages of 1: > > \* We can always switch to 2. later if needed > \* The chance of collision of the GitHub / GitLab / ... prefix is relatively low (if it happens, we'll handle it on a case by case basis) > \* We can list the main package, say \`fortran-lang/stdlib\` as well as a fork, say \`certik/stdlib\`, if the fork has some versions or branches that the main repository does not > > Disadvantages of 1: > > \* I remember the package by its name, such as "datetime", and I don't want to remember what the prefix is. Although in practice I assume one would do \`fpm search datetime\` to obtain the actual version to use (which I won't remember anyway). And \`fpm search datetime\` can print out the exact line to put into \`fpm.toml\`, such as \`wavebitscientific/datetime = "1.7.0"\`. So this might not be any more difficult than just \`datetime = "1.7.0"\`. > > Advantages of 2: > > \* Shorter names > \* Possible to change where the package lives, for example if \`wavebitscientific/datetime\` is moved to \`fortran-lang/datetime\`, then nothing changes in the \`fpm.toml\`. With the option 1., one would really need to stick to \`wavebitscientific/datetime\` as a name, or provide some kind of a redirect. > > Disadvantages of 2: > > \* First serve first come basis, in a few years all the lucrative names will be already taken > \* Possible conflicts > > > I just checked out this registry for fpm and noticed some rough edges. It is som…ewhat related to #1, but maybe worth a separate issue. > > Specifying a project with multiple releases quickly gets redundant, imagine a package which releases on a regular basis, keeping the registry data up-to-date will quickly become a copy-and-paste approach > \`\`\`toml > \[project-name\] > "1" = {git="https://github.com/project-name/project-name", tag="v1"} > "2" = {git="https://github.com/project-name/project-name", tag="v2"} > "2.1" = {git="https://github.com/user-name/project-name", tag="v2-server.1"} > "3" = {git="https://github.com/project-name/project-name", tag="v3"} > "3.1" = {git="https://github.com/project-name/project-name", tag="v3.1"} > "4" = {git="https://github.com/project-name/project-name", tag="v4"} > "latest" = {git="https://github.com/project-name/project-name", branch="main"} > \`\`\` > > A slight improvement in my opinion would be to allow specifying the upstream URL in the project section and allow to overwrite it per version basis. > > \`\`\`toml > \[project-name\] > git = "https://github.com/project-name/project-name" > "1" = {tag="v1"} > "2" = {tag="v2"} > "2.1" = {git="https://github.com/user-name/project-name", tag="v2-server.1"} > "3" = {tag="v3"} > "3.1" = {tag="v3.1"} > "4" = {tag="v4"} > latest.branch = "main" > \`\`\` > > > The documentation of the fpm-registry is currently not in a good shape. Good doc…umentation is crucial to make a project like a package registry appealing for developers to actually submit their packages. > > Currently, upon visiting the registry there are no guidelines on the scope and expectations of the registry, the packaging guidelines linked are for the package index at fortran-lang.org and not \*fpm\* specific. Especially the required keys for submitting to the registry are not documented. > > Also, the package validation is tricky, the validation should happen with the \`load\_registry.py\` script if I read the README correctly, but the actual validation of the fpm-enabled projects will only happen with \`build\_index.py --check-new\`. and many others … ---
**Author:** ![R\_cubed](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/r_cubed/32/263_2.png) [@R\_cubed](https://fortran-lang.discourse.group/u/R_cubed)\ **Post date:** [July 6, 2021, 3:20am UTC](https://fortran-lang.discourse.group/t/building-fpm-from-source-on-windows-10/1512/8 "2021-07-06T03:20:59Z")
Thanks for the info. Just so this idea doesn’t get lost or forgotten, it is worth considering to have the organization of the various libraries structured to match the taxonomies developed over the years. The NIST Guide to Available Mathematical Software ([GAMS](https://gams.nist.gov/)) as well as the Digital Library of Mathematical Functions (DLMF) were mentioned in this older thread. > [@About a Fortran Scientific Library](https://fortran-lang.discourse.group/t/about-a-fortran-scientific-library/402/16): > > Upon request of folks from the zoom call, I posted some suggestions on github that I report here: There is a standard for the class of numerical functions that are needed in scientific computation. Traditionally, that was for a long time the “blue book” \*Handbook of Mathematical Functions", by Abramowitz and Stegun. However, the American National Institute of Standard and Technology (NIST) has sing long ago taken the burden on its shoulder. After countless years of work and revision, the new [D…](https://dlmf.nist.gov/) Hopefully, that will make teaching the math along with the programming easier.