Change how output is presented

[certik]

Currently fpm's output is very verbose and it's hard to see what is going on. A bunch of commands (typically compiler invocations) are printed to stdout. Instead, let's do something like Rust's Cargo does:

$ cargo build
   Compiling libc v0.2.103
   Compiling autocfg v1.0.1
   Compiling proc-macro2 v1.0.26
   Compiling unicode-xid v0.2.2
   Compiling syn v1.0.72
   Compiling pkg-config v0.3.19
   Compiling cfg-if v1.0.0
   Compiling serde_derive v1.0.130
...
   Compiling path_abs v0.5.1
   Compiling encoding v0.2.33
   Building [============>             ] 79/150: encoding, proc-macro-hack...

Or the Julia's Pkg:

julia> import Pkg

julia> Pkg.add("SymEngine")
   Resolving package versions...
   Installed RecipesBase ─── v1.1.2
   Installed MPC_jll ─────── v1.2.1+0
   Installed SymEngine_jll ─ v0.6.0+1
   Installed SymEngine ───── v0.8.6
  Downloaded artifact: SymEngine
  Downloaded artifact: MPC
    Updating `~/.julia/environments/v1.6/Project.toml`
  [123dc426] + SymEngine v0.8.6
    Updating `~/.julia/environments/v1.6/Manifest.toml`
  [3cdcf5f2] + RecipesBase v1.1.2
  [123dc426] + SymEngine v0.8.6
  [2ce0c516] + MPC_jll v1.2.1+0
  [3428059b] + SymEngine_jll v0.6.0+1
  [781609d7] + GMP_jll
  [3a97d323] + MPFR_jll
Precompiling project...
  6 dependencies successfully precompiled in 4 seconds (48 already precompiled)

Note that Julia's Pkg prints all kinds of nice progress markers that all disappear when it is done, so the above output only captures the final result. I recommend you try the above commands yourself to see what I mean.

The final output of Cargo seems cleaner and it seems it contains all the information you need to know, which is which package got built and which version. We can also print which Fortran compiler was used (I am not sure).

P.S I thought I already opened up an issue for exactly this, but I can't find it, so I opened a new one.

[LKedward]

I made an attempt at this a while back (see this post) but didn't get a chance to finish it off and the code was a little hectic. You can see the changes here. I might have some time to clean it up for a PR next weekend.

[certik]

Perfect! That's exactly what we need. If you had time to finish it that'd be great. The code looks minimal.

A change like this I expect will require all kinds of testing and tweaking to ensure it works on all platforms (Windows) and that you can turn it off to redirect the output to a file, and so on. But I would recommend to simply get it merged into master, and then we'll fix all bugs as we go.

[urbanjost]

Since a lot of the messages are still set up for it from previous runs at this (#502 and #505 in particular) note that a lot of the messages are set up with and prefixes (and others) to be used with M_attr, which is a small module that was designed to just be included into fpm(1) to allow for color mode, and that a (probably) simple one that should probably done first is to add the verbose mode into the backend model, as there were concerns about it just being provided as a global state type. M_attr was designed to add color in a manner that can be turned of except when writing to a tty device and to allow for extensions and customization without changing the code, but as a simplified version of M_escape that could just be added as file in the fpm distribution, although I suppose there is nothing wrong with using it as a dependency. The model that made most sense to me was that the command output for each command is written to a file in build and then copied back only if verbose mode is on or if an error occurs by default; but can be examined with new options at any time after the build without rebuilding.
That seemed like an excellent model, providing logging and controlling verbosity at the same time, and allowing for options like not showing messages from dependencies, showing messages with a specific string and so on that can probably be prototyped with a plug-in (but a dumb at TOML or NAMELIST of the machine info to the plugins would allow them to be far more powerful, which does not exist yet). One of the advantages of adding color with M_attr is the log files can still contain the strings like and so easily re-displayed with and without color. If/when the last PR I put in was accepted adding a verbose state was on my list but others can probably add that very quickly in less time, as what held me back was wanting to re-familiarize myself with the backend as it has changed a lot since I last was altering it.

M_attr

You can see how it was used in the quiet mode, as well as with help text in the referenced PRs and issues from the last two times; and the github repository explains some of the reasons to use this approach for color rather than directly using the escape sequences.

[urbanjost]

PS; although their is an ncurses library for WIndow, i was playing with a plugin that used ncurses that displayed the source files like the output in a tree(1) output like at the beginning of the video from @LKedward ward where the file names changed color as they were done and you could click on them to see their messages or edit them (via the environment variable EDITOR) that was promising, but without a nice interface from the plugin to the backend it was way too kludgy but at some point (maybe using an entirely different GUI tool) maybe a mini-IDE would be nice; but my general impression was that those so inclined to use an IDE already were using a full-blown one and just wanted interfaces into their favorite one. I would probably restart if I try that again, but you can get an idea of how it worked by looking at fixedform in M_ncurses

[certik]

@urbanjost if you are interested, we created this library: https://github.com/jupyter-xeus/cpp-terminal/ which implements ncurses like functionality and it works on Windows. It also implements a multiline editing "widget" (that works on all platforms), that LFortran uses.

[urbanjost]

Thanks. I will give that a try. What I was picturing was a scroll-able window that looks like the output of the tree(1) command that would be colored according to whether built with no warnings, with warnings, or with errors and you could click on the names to edit, see the build log of the routine, or run if an executable, sort of like a graphical windows commander plugin; but just have not had the time to pursue it.

[LKedward]

Reopening for some outstanding tasks:

• Command to print last set of build messages (Cleanup the backend output #622)
• Only print verbose output for the current package (not dependencies)
• Detect terminal type at startup to allow using color in the rest of fpm (Cleanup the backend output #622)
• Output more information on files during build: e.g. <project>:path/from/project/root/to/source.f90 (Cleanup the backend output #622)