The images in the installed HTML docs are broken because they point to an images subdirectory even though all the files are placed in the same directory. This patch installs the images to an images subdirectory as they are in the source tree.
It does the same for fonts although these are not referenced in the HTML files at all. A couple of the HTML files link to the Lato font on Google instead. I suggest you remove the font files from the project entirely and consistently use external fonts.
Finally I moved all the "html" docs into a html subdirectory on installation to keep them separate from the rest of the docs. This is useful for Gentoo Linux as it compresses docs that are not within the html subdirectory but it also keeps things tidier in general. This way you can easily tell which files need to be read directly and which can be accessed in a browser via index.html.
where did you find references to google? i thought i removed all of them (that was the whole point of the font dir)
edit: nevermind, found and removed. the actual references are in latofonts.css, which is imported by vice.css, which is in turn used by the html files
that said, i am not sure if removing the html docs from installation (and binary packages for that matter) wouldnt be the better idea. all major platforms can use the .pdf, which is also easier to read and search.
Last edit: gpz 2020-01-23
nsosrh.html and sortix.html are referenced by index.html but aren't actually installed. The same is true for latofonts.css so I now realise the font files are referenced from there.
ps: pdf is also what opens when using "help" in the UI - so most ppl wont ever use the html
If we remove the html docs, we need to 'rescue' (ie move) the 'vice-logo.svg' and 'vice-logo-black.svg' files, at least the black logo file is used in the vice.gresource file by reading it from the html/images directory.
I know using the logo from the doc/html/images dir isn't ideal, but I'd rather not have duplicate files in the the source tree if it can be avoided. Perhaps we can move the images into data/common and install the html docs images from there?
But, it doesn't belong there! "vice-logo-black.svg" isn't used by the HTML pages. It is only a UI file. It belongs in the directory which holds the UI's icon files.
Yes, the black variant is only used in the UI while the white variant is used in the HTML docs, so I suspect at some point either there was some intention to perhaps use both in the HTML docs (ie different themes) or both logos provided by Seven were just stored in the html/images dir to have them in the source tree.
I have no trouble moving the vice-logo-black.svg into common/data, at least makes the generation of the gresource file a bit more consistent.
ugh no, please lets keep everything together :) and the point wasnt to remove the html - but to not install it in the system (or bindist), and only use it for the website.
In that case, please see this patch. It;
texi2pdf is quite a heavy dependency so I may still install the HTML docs on Gentoo as a fallback but this can be done without the Makefile easily enough.
Recent changes led to a conflict so here's a fresh patch.
I'm taking back what I said about installing docs without the Makefile though because it's a bit fiddly avoiding the additional build files. I'll see whether I can make them install only when --htmldir= (a standard configure option) is given.
Wouldn't only installing HTML docs when
-htmldiris used break autoconf standard behaviour? Seems to me it is used to override@docdir@, not to optionally generate HTML docs. (Not that I care much).I'll check your patch, probably tomorrow.
Yeah, I reconsidered that afterwards. I'll make it a
--install-html-docsoption or something. I'd like--install-pdf-docstoo because distros try to keep builds deterministic, i.e. only install a PDF when I say, not when texi2dvi just happens to be present.That sounds good.
I just tried your patch, it generates the HTML docs just fine, but I can't find any CSS or images in ($build_dir)/doc/html (building out-of-tree here).
I noticed that when building out-of-tree too but I think it's always been like that so I figured you didn't mind or expected most people to build in-tree. I guess you'd need to copy the static files to the build directory if it's different. I can try adding that, if you like.
I think it's mostly VICE devs (and perhaps package maintainers) who build out-of-tree. Using --enable-internal-ffmpeg breaks when building out-of-tree, nobody except me ever complained about that. Should it become a problem I can fix that.
Doesn't Gentoo use a separate build dir? I think it did that when I used it, could be wrong though, when I used Gentoo you could still do a stage1 build ;)
Okay, new and hopefully final patch. It sticks to the best practise principle of:
More specifically, it:
make cleanand ensures source files aren't removed from in-tree builds.AC_PATH_PROG(PERL, perl)I noticed in resid-dtv.To answer your question, Gentoo has never built out-of-tree for Autotools-based projects by default but it frequently does anyway for packages that are multilib-enabled. In this case, I am using "multibuild" to build the GTK, SDL2, and headless variants as requested.
Patch applied in r37493, Thanks again and sorry for the delay.
Spoke too soon, this happens on both Debian and Gentoo when compiling in-tree:
Tried a few things, but it seems even with just
./configurethe src/doc/html/Makefile.am isn't correct. When I remove $(STATIC_FILES) from HTML_FILES I get less complaints, but I still get:So something is obviously wrong with the dependencies in that file.
This fixes both sets of warnings. As discussed, it would be nice to apply the Automake fix globally in configure.proto but I'm leaving you to sort out the $VICE_VERSION mess. ;-)
Last edit: James Le Cuirot 2020-02-24
Applied in r35711, works on my machine. Thanks!
As for the global Automake fix and $VICE_VERSION, I'll take my time with that, to avoid breaking the buildsystem. ;-)
Edit: seems I already did some modernizing on configure.proto in r35709. Haven't had any problems with that on Debian or msys2, so perhaps "it just works" for now?
Last edit: compyx 2020-02-26
It seems to me we fixed the issues the patch addresses, and even some more. So, I'm hoping we can close this, unless anyone has any objections.
Do it.