Fixes relative links in HTML output

[SuzanneSoy]

When the destination directory has more than one path component, e.g. raco cover -d foo/coverage file.rkt, the URLs were of the form coverage/coverage/file.html . Also, when the -d option was a relative path starting with ./, e.g. ./foo/coverage, the URL in the links was an absolute path, like /home/user/project/foo/coverage/file.html, which doesn't work if the generated HTML is put online.

This patch fixes both cases (foo/coverage, and ./foo/coverage, I also tested with just ".", it works).

[florence]

How does this now behave if you, from the top of your share/pkgs directory, do:

raco cover -c pict -c compiler ?

[SuzanneSoy]

@florence It hogged up all of my memory, and took an awful amount of time (both in the original and the patched versions), but diff -r tells me the result "coverage/" folders are identical (and the links were already relative in this case).

Was there something specific I should have looked for?

By the way, my installation is running on NixOS, which does some funny things to the system paths (/usr etc.), so you might want to test yourself too, if there's something specific to the system folders happening.

[florence]

Looking into things, this actually regresses af35a4dd1a7403a18

raco cover -p pict from a directory not a parent of my extra-package directory generate this html page:

The rendered links in the index should be relative to the least common relative directory of all files in the output, NOT relative the current directory.

[florence]

(I should really have tests for this...)

[SuzanneSoy]

@florence Unless I didn't see something when I changed the code, I only touched the href part of the links:

• My change is in the definition of file/path-mapping
• file/path-mapping gets passed down to table:file-reports
• When table:file-reports calls tr:file-report, it passes k as the name (from which local-file is constructed, which in turn is displayed as the link's text), and path for the path parameter, which is used in the href, but not in the link text.

The k / name should be untouched by my change, so the visible ../../.. is another issue I think.

[SuzanneSoy]

@florence I agree about tests, although checking for broken links might be a bit difficult… Unless you mean checking against the HTML when it is still in s-exp form.

[florence]

Ok I must have broken this at some other point and not noticed.

(The proper tests would be to read the files back in and mung those in sexp form)

[florence]

Merged, thanks!