Answering two-in-one here:
jared r r spiegel wrote:
> is it true that the denominator in the question is whether people
> installing the port will likely need/want to have the docuementation
> or not.
My initial reason to start working on a doxygen port was that it is a
BUILD_DEPENDS of libtheora-alpha4, which I wanted to play with. However,
just like pretty much any other project that uses doxygen out there,
libtheora will very likely starting coming with pre-built docs during
its time towards release. Another reason was that i heard it was worth
looking into, to document my own stuff.
So my personal usage would be actually using it, not only as a
BUILD_DEPENDS for some other package ... something for which I need
documentation.
> if it seems likely that most people will not fancy having the docs
> installed by default, then it would seem that ``docs'' and putting
> a BUILD_DEPENDS+= inside the .if ${FLAVOR} would be good; or
> otherwise if most people will want the docs, making ``no_docs'' and
> then rewriting the BUILD_DEPENDS back to stock ( is there a
> BUILD_DEPENDS-= ? ) might be ok if you want to save them the time.
I am leaning towards no_doc, since the resulting package will have
absolutely no dependencies whatsoever and will be easy to (de)install.
All the hassle is in the build process ... or not (see below, wrt the
.pdf from doxygen.org.)
Nikolay Sturm wrote:
1. Doxygen documentation
There is a separate manual distribution tarball on doxygen.org, but it
only contains the manual in PDF format. Rebuilding the docs within the
Not a problem.
For me neither, which is the reason why I was asking in the first place.
port is not a problem per se, it's simply taking for ages and is a very
memory hungry process as well. The documentation (and accompanying
Is it worth it? What other *useful* format does this bring us?
HTML that can be read with lynx. Sorry for not being clear enough about
that earlier...
The simple solution is to download the pdf and not add a PSEUDO_FLAVOR
at all.
Yep, that'd be wonderfully easy - it still leaves the question whether
those working with doxygen want to have it readable with a browser or
whether it's okay just to have the .pdf. If people that use it, use it
on rather large projects that are probably graphical and fat in one way
or another, the likelyhood of an available and comfortable .pdf reader
is pretty large.
For the complex case of building the documentation yourself, the rule of
thumb is, that ports are there for package builders to build packages.
Therefor I'd go with no_docs.
Yes, all the agreement is making me dizzy (or it's the sun/heat) ...
which leads to another point I forgot to mention earlier. Aleksander's
port does some patching to allow USE_GMAKE to stay `No', which I
personally find ... not so useful. Is it a good idea to do that in my
version as well? (Would lead to more patches that need maintenances, and
who cares about gmake anyways ...)
2. (Optional) dependencies
[...]
respective no_x11 flavors beforehand) or both. What do you think about
specifically tagging them as RUN_DEPENDS for doxygen and being done
with it?
I don't quite understand this. If they are optional, there's no reason
to add them as RUN_DEPENDS. If doxygen is hardly useable w/o them, add
them as RUN_DEPENDS as they are not really optional. If you build the
documentation yourself, additionally add them as BUILD_DEPENDS.
This also depends on the general feedback from (potential) doxygen users
I might get here - the dependencies wouldn't be optional if doxygen were
useless without them, I think it can still produce text-only .html
documentation (and probably man pages) without them. Graphviz is for
nice graphs and diagrams, teTeX and Ghostscript are for rather useful
(easy to print and easy to read) .pdf, TeX, ... output formats.
3. Miscellaneous
There is an issue I haven't found a proper solution for, yet - when
building the doxygen documentation, the `dot' utility from the graphviz
package writes_to_HOME. Any hints on how to typically solve this kind of
stuff, or a confirmation that it doesn't matter would be highly
Doesn't matter.
[... fumbling with $HOME]
Don't do this, dot might just want to update its config file or sth. As
you already see the warning, everything is doing fine. If dot really
wrote somewhere outside WRKDIR, that'd be bad.
Okay. FYI, the error message is
systrace: deny user: root, prog: /usr/local/bin/dot, pid:
25823(0)[22208], policy: /usr/bin/env, filters: 142, syscall:
native-fswrite(136), filename:
/doxygen-1.4.1_writes_to_HOME/.fonts.cache-1.LCK
Moritz
