Summary: | lang/ghc: remove unused DOCS_BUILD_DEPENDS=xetex | ||||||
---|---|---|---|---|---|---|---|
Product: | Ports & Packages | Reporter: | Siva Mahadevan <me> | ||||
Component: | Individual Port(s) | Assignee: | freebsd-haskell (Nobody) <haskell> | ||||
Status: | Closed FIXED | ||||||
Severity: | Affects Only Me | CC: | alster, arrowd, kib, me | ||||
Priority: | --- | Flags: | arrowd:
maintainer-feedback+
|
||||
Version: | Latest | ||||||
Hardware: | Any | ||||||
OS: | Any | ||||||
Attachments: |
|
> lang/ghc currently does not even package its built HTML and PDF docs, so there is no point in building them.
It doesn't seem to be true:
$ pkg info -l ghc | grep pdf
/usr/local/share/doc/ghc/Haddock.pdf
/usr/local/share/doc/ghc/html/users_guide/_static/logo.pdf
/usr/local/share/doc/ghc/html/users_guide/_static/prof_scc.pdf
/usr/local/share/doc/ghc/users_guide.pdf
$ pkg info -l ghc | grep html | wc -l
5069
Ah that's my mistake, I looked through the pkg-plists, Makefiles, and patch files, and found no mention of PDF documentation being packaged. I'm fine with the HTML documentation being built because: * it's very easy to read it on both graphical and non-graphical freebsd systems * as plaintext, it's lightweight * it doesn't pull in any other dependencies except Sphinx The PDF documentation is essentially unreadable on non-graphical freebsd systems, which are (in my understanding) the majority of the freebsd market share. Yet it pulls in quite heavyweight ports just to build something that is already mostly available online (to someone who is able to view it with a graphical browser/PDF viewer anyway). For the sake of the general/majority consumer of lang/ghc, could we stop building PDF documentation, but keep HTML documentation as-is? A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=0e32e26d3800536e3c065ff45c6342ff4db1ad37 commit 0e32e26d3800536e3c065ff45c6342ff4db1ad37 Author: Gleb Popov <arrowd@FreeBSD.org> AuthorDate: 2024-12-19 17:14:27 +0000 Commit: Gleb Popov <arrowd@FreeBSD.org> CommitDate: 2024-12-19 17:17:45 +0000 lang/ghc: Do not build PDF docs to avoid a heavy dependency on xetex PR: 283368 lang/ghc/Makefile | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) Can we please still have an option to build pdf? Or a separate port with pdf docs. I can chase this goal, if there is a demand. The same information is available in the HTML form, so I wonder when PDF is really needed. An user that has a PDF viewer, but not a browser? (In reply to Gleb Popov from comment #5) No, a user that much prefers pdf reader than the browser. E.g. for me, a bunch of html pages is much less convenient to read than properly formatted print-ready doc (be it pdf, ps, dvi, or any other high quality page description language). I will look into adding the PDFDOCS option then. (In reply to Gleb Popov from comment #7) Thank you A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=344cf9384c54007933590e02c6a9758615dbb5e4 commit 344cf9384c54007933590e02c6a9758615dbb5e4 Author: Gleb Popov <arrowd@FreeBSD.org> AuthorDate: 2024-12-21 12:29:54 +0000 Commit: Gleb Popov <arrowd@FreeBSD.org> CommitDate: 2024-12-21 12:30:53 +0000 lang/ghc: Introduce PDFDOCS option. PR: 283368 lang/ghc/Makefile | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) Thank you for your efforts for keeping PDF documentation. I also like and use it in general. (In reply to commit-hook from comment #9) Thanks from me as well. |
Created attachment 255899 [details] [PATCH] lang/ghc: remove unused DOCS_BUILD_DEPENDS=xetex lang/ghc currently does not even package its built HTML and PDF docs, so there is no point in building them. Furthermore, users can still generally view PDF docs using their web browser pointing to upstream PDF URLs at haskell.org. In order to build the PDF docs, it BUILD_DEPENDS on print/tex-xetex, which pulls GBs worth of dependencies and takes quite a long time to build. This patch removes the essentially "unused" dependency on print/tex-xetex and saves on this time and storage cost.