Generate Package Dependency Graph

[peter-michalski]

Add code to automatically generate a package dependency graph.

[balacij]

stack dot was what I mentioned in the meeting, I don't know if it will be helpful, but it can be used to generate a GraphViz/Dot graph of the drasil-* packages (with the examples).

[peter-michalski]

@balacij Yes, this will be helpful. I used a website that uses this tool when I created the dependency graph in #2961

[peter-michalski]

Some notes:

stack dot --prune dblpendulum,gamephysics,glassbr,hghc,nopcm,pdcontroller,projectile,sglpendulum,ssp,swhs,template,drasil-website | dot -Tpng -o dependencies.png

[peter-michalski]

I have added code for generating the package dependency graphs to the Makefile: https://github.com/peter-michalski/Drasil/commit/5afbd9f1f027dc021bfbc245a9611186de1d6ac3

I am assuming we also want this graph to be shown on the website. Most likely, this "high level" package dependency graph should be added to the existing dependency graph section, perhaps replacing the current image that is there (which details some lower level drasil-website specific dependencies).

I am still deciding if drasil-website should be part of this high level graph.

[JacquesCarette]

Yes, this graph is wonderful. Although it would be even better if transitive relations were not shown, i.e. use tred also from graphviz (i.e. tred ). And yes, please add it to the web site.

[peter-michalski]

Some notes:

I noticed that make website does not actually create the graphs, nor does it create the necessary graphs folder under website/HTML. It only renders the markup code that references this missing directory and files.

make graphs creates a graphs folder under code

[peter-michalski]

@balacij, following up on our meeting discussion, can you confirm that in order to deploy the website, make deploy needs to be run before make website? I just attempted make deploy in a fresh repo and error-ed out.

[balacij]

Oh, what kind of error occurred? Did the logs show anything?

make deploy is meant to be a single command that does everything for you. However, if you want a deconstructed view of make deploy, you can manually run through the CI steps on your machine too. The CI steps follow the correct order (code, build code, doxygen, Haddock docs, analyze Haskell/Drasil code into graphviz dot files, compile dot files, build website, and gather everything together)

[peter-michalski]

Oh, what kind of error occurred? Did the logs show anything?

command prompt shows hyperref warnings, LaTeX overflow warnings, svg warnings, then finally

Makefile:4: recipe for target 'GlassBR_SRS.pdf' failed make[1]: *** [GlassBR_SRS.pdf] Error 1 make[1]: Leaving directory '/home/peter/Grad School/DrasilPlayground/peter-michalski-drasil/testWebsite2/Drasil/code/build/glassbr/SRS/PDF' Makefile:305: recipe for target 'glassbr_tex' failed make: *** [glassbr_tex] Error 2

A deploy folder was created with a bunch of content. No image folder in /Website though, which is what I was looking for.

Are you having the same problem using a fresh repo?

[balacij]

That's very interesting, I am also having the same problem now!

I tried to compile it manually now, but it still fails. Some observations:

1. The CIs tex-building step doesn't actually work anymore. It stops when it can't find a TERM environment variable (which can be set to unknown, or anything else, at the top of the scripts/tex_build.sh script to resolve it). After 'fixing this', and running it, the code errors out with a specific error "Dimension too large!" when it gets to compiling the "Table of Auxiliary Constants" in the SRS files.
2. The CI builds with extra required TeX flags that the generated Makefiles don't have! The Makefiles should, at a minimum, compile the PDF files with --shell-escape in the $(TEXFLAGS) variable. This is set in tex_build.sh script, but not explicitly required in the Makefiles (although it is implicitly required for compilation since we have SVGs being compiled with Inkscape).
3. It looks like the "Dimension too large!" issue has to do with longtable and tabu. Apparently, tabu has been largely unmaintained since 2011, but it builds on a 2011 copy of longtable. So, when a longtable update happened that changed some names around, tabu broke. It looks like we should try to replace tabu?

Should we suppress these issues so that you can at least incorporate the package dependency graph on the website? These should definitely be fixed asap though.

EDIT: The link I meant to hyperlink: https://github.com/JacquesCarette/Drasil/runs/7235504427?check_suite_focus=true#step:13:5246

[JacquesCarette]

I wonder if this was triggered by one of the PRs that I recently integrated? But this is all weird, as I would have expected the CI to have come back 'red' & not let me merge at all. So it's like something in the infrastructure itself changed out from under us.

[balacij]

Unfortunately, GitHub Actions logs expire after 90 days, so I'm not sure if we'd be able to trace the CI breakage to when it happened. However, I'm fairly confident it happened a while ago because we have an Actions run almost 3 months old that also shows the same issue (an undefined $TERM environment variable causes lualatex to halt before anything compiles). I don't immediately know why the CI didn't go 'red' -- a local make tex gives an error code, but it doesn't seem to be giving an error code in the CI runs.

The CIs LuaTeX version is from 2019, so nothing from the compiler should have changed in a while, but the TeX packages might very well have been updated.

@peter-michalski I don't have any Inkscape errors, but I do have warnings. Taking GlassBRs generated TeX as a sample, lualatex gives an error for longtabu/tabu usage.

If you run make tex in the code/ directory (expect it to fail), then cd into build/glassbr/SRS/PDF, you can run lualatex --shell-escape GlassBR_SRS.tex to find all the errors. Are all of yours then related to either lines with \midule \\ ("There's no line to end here!" error) or lines with \end{longtabu} ("Dimension too large!" error). The bib errors should be 'normal' because they require a 'biblatex' run afterwards, and then 2 more 'lualatex' runs.

So, it looks like there's at least 2 problems:

1. The CI isn't erroring out, when it should be (unknown cause).
2. The manual 'lualatex' runs now fail because of longtabu environments.

[peter-michalski]

The above problem was resolved. This issue can be closed after #3047 is closed.