Implement fpm new

[milancurcic]

Should be a low-hanging fruit and easy project.

[urbanjost]

I tried implementing the command line parsing I could discern from the Haskell fpm(1) using a parsing module I have and implemented the "fpm new" subcommand trying to stay true to the current structure of the fpm Fortran skeleton. I also had it ech the parsed arguments in the unimplimented commands. I could not get this to push out put I have not done that all that many times so if anyone is interested in that clone https://github.com/urbanjost/M_CLI2.git and ignore the rest of it but just look in the fpm.cli/ directory.

[urbanjost]

I put a branch on called urbanjost that has a "new" subcommand. Lots of questions about what it should do when given an existing directory, like an existing github repository you want to convert to use fpm(1); to test it I added a CLI interface and did some tweeking of the "run" and "build" subcommands, but just minimal enough to run the output from a "new" subcommand" and a simple project with no dependencies. It also allows for an "-- options" instead of -args " options". The biggest issues are how to implement MKDIR, CHDIR, and GETCWD. CHDIR and GETCWD exist as extensions in gfortran, for example. I used some existing POSIX-like interfaces I had, but that limits portability unless similar functions are added to stdlib. Thought it would be useful for discussing how it should best be implimented. So I guess it gets into #135, #138, as well as #154 all in
#159. No smarts about the order of compilation or pulling packages/ dependencies but at least it actually lets you try out a "new" command concept. I was thinking maybe a -license switch might be nice for common licenses; and was thinking the default README.md might include links to the fpm page and maybe some other links as a more complete example of a markdown file, but unless a specific platform like github was selected I am not sure the markdown syntax between repositories is standardized enough to do that. Anyway, learned some things about how to use the TOML interface. Hope this might be useful for discussion. When it is done, fpm(1) is going to be an interesting code. There are enough interesting problems there just getting it to the state of the Haskell prototype that I might actually look at the Haskell code out of curiosity to see how it was done. Anyway, I find coded examples a good way to discuss potential solutions, so thought this would work as a way to discuss some possible approaches for this. Apparently the CLI is going to be done using other approaches, but if there is any interest I think this is actually a full implementation of the CLI (Cocmmand Line Interface).

[urbanjost]

Were you saying you wanted to implement this or that you think it is a good candidate for early implimentation?
I have some ideas on how I would want it to act with an extension to how it works with an existing directory for someone migrating to supporting fpm. I would like to put it in as a draft on the PR page or discuss some of it with you if you are working on it.

[certik]

Are you asking Milan? In general I would say go ahead and implement things. If you open a PR with an early implementation, everybody can collaborate there.

…

On Wed, Sep 23, 2020, at 8:17 PM, urbanjost wrote: Were you saying you wanted to implement this or that you think it is a good candidate for early implimentation? I have some ideas on how I would want it to act with an extension to how it works with an existing directory for someone migrating to supporting fpm. I would like to put it in as a draft on the PR page or discuss some of it with you if you are working on it. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#154 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAFAWHWTCJQKZEJOEKZUMLSHKT23ANCNFSM4QGN4EIA>.

[milancurcic]

@urbanjost sorry that I wasn't clear. I'm not working on it and I'm happy that you are. I agree with Ondrej, considering that fpm new has a simple and well defined API, you can go ahead with the PR.

[urbanjost]

Great. I will create a PR called "NEW". Unfortunately, I will have to include the PR "CLI" to have a model that can implement the "new" subcommand; which is not yet approved. Perhaps I should just delete "CLI" and do "NEW"?
Something weird is happening with the MSWindows build of "CLI" to boot; but I think I can do "NEW" and probably "RUN" pretty quickly far enough and I think others can extend "build" and should have pretty complete "new","run" . I am going to add a --list option to "run" for discussion about using such as option for piping into a command like GNU/Linux xargs(1) command and/or creating a --mask to make it easier to use fpm(1) with other utilitilies. On Linux I might want to have a way to use gdb, valgrind, maybe profiling ?

[LKedward]

Perhaps I should just delete "CLI" and do "NEW"?

If possible I would prefer that we keep the "CLI" pull request so that it can be reviewed separately.

[urbanjost]

Started a NEW before I saw this post. Have had some issues with the CLI PR building that @everythingfunctional seems to have been resolved and exposed an issue with quoting of arguments containing spaces after the -- argument, but if I get that sorted out I have a prototype for NEW that builds, runs, and tests. This bash(1) script actually ran with just the Fortran code and I think it will run or test a Haskell fpm directory too, which was a pleasant surprise. I pretty much just copied some of the lines from the build command and made a few guesses. Not like it pulls remote repositories and builds them or does a topological sort and builds in the right order or anything; but I hope this is a step forward. If you play with it it raises some interesting questions about what a new command should do in an existing directory, if a new pathname can be a full pathname, if you should be able to ask for a new setup that is any of the prototypes on the web page, whether an option to write some of the common LICENSE files would be useful -- I think there are some good discussions there just using this basic PR.

#!/bin/bash
##################################################
(
exec &2>1
set -x -v
fpm-new new asdf --with-executable --with-test
cd asdf
fpm-new build
fpm-new run
fpm-new test
fpm-new run --list
fpm-new test --list
fpm-new run --list --release
fpm-new test --list --release
fpm-new build --release
fpm-new run --list --release
fpm-new test --list --release
)|tee -a $0
##################################################
exit

• mkdir -p asdf
• cd asdf
• mkdir -p asdf/src
  fpm::new asdf/src/asdf.f90 already exists. Not overwriting
  fpm::new asdf/.gitignore already exists. Not overwriting
  fpm::new asdf/README.md already exists. Not overwriting
• mkdir -p asdf/test
  fpm::new asdf/test/main.f90 already exists. Not overwriting
• mkdir -p asdf/app
  fpm::new asdf/app/main.f90 already exists. Not overwriting
  fpm::new asdf/fpm.toml already exists. Not overwriting
• cd asdf;git init
  Reinitialized existing Git repository in /tmp/asdf/.git/
• gfortran -c src/asdf.f90 -Wall -Wextra -Wimplicit-interface -fPIC -fmax-errors=1 -g -fbounds-check -fcheck-array-temporaries -fbacktrace -Jbuild/gfortran_debug/asdf -o build/gfortran_debug/asdf/asdf.f90.o
• gfortran -c app/main.f90 -Wall -Wextra -Wimplicit-interface -fPIC -fmax-errors=1 -g -fbounds-check -fcheck-array-temporaries -fbacktrace -Jbuild/gfortran_debug/asdf -o build/gfortran_debug/app/main.o
• gfortran build/gfortran_debug/app/main.o build/gfortran_debug/asdf/asdf.f90.o -o build/gfortran_debug/app/asdf
• gfortran -c test/main.f90 -Wall -Wextra -Wimplicit-interface -fPIC -fmax-errors=1 -g -fbounds-check -fcheck-array-temporaries -fbacktrace -Jbuild/gfortran_debug/asdf -o build/gfortran_debug/test/main.o
• gfortran build/gfortran_debug/test/main.o build/gfortran_debug/asdf/asdf.f90.o -o build/gfortran_debug/test/runTests
• build/gfortran_debug/app/asdf
  Hello, asdf!
• build/gfortran_debug/test/runTests
  Put some tests in here!
  fpm::run:executable expected at build/gfortran_debug/app/asdf exists
  fpm::run:test expected at build/gfortran_debug/test/runTests exists
  fpm::run:executable expected at build/gfortran_release/app/asdf exists
  fpm::run:test expected at build/gfortran_release/test/runTests exists
• gfortran -c src/asdf.f90 -O3 -Wimplicit-interface -fPIC -fmax-errors=1 -ffast-math -funroll-loops -Jbuild/gfortran_release/asdf -o build/gfortran_release/asdf/asdf.f90.o
• gfortran -c app/main.f90 -O3 -Wimplicit-interface -fPIC -fmax-errors=1 -ffast-math -funroll-loops -Jbuild/gfortran_release/asdf -o build/gfortran_release/app/main.o
• gfortran build/gfortran_release/app/main.o build/gfortran_release/asdf/asdf.f90.o -o build/gfortran_release/app/asdf
• gfortran -c test/main.f90 -O3 -Wimplicit-interface -fPIC -fmax-errors=1 -ffast-math -funroll-loops -Jbuild/gfortran_release/asdf -o build/gfortran_release/test/main.o
• gfortran build/gfortran_release/test/main.o build/gfortran_release/asdf/asdf.f90.o -o build/gfortran_release/test/runTests
  fpm::run:executable expected at build/gfortran_release/app/asdf exists
  fpm::run:test expected at build/gfortran_release/test/runTests exists

If the CLI PR gets OKed I will merge NEW into a new PR I guess. I could pull this back but if anyone has some time to preview it I am curious about what anyone thinks.  I am hoping this can actually complete #154 sans some of the new questions it raises actually being able to try it.

[LKedward]

Closing as implemented in #189.