ccache, ccache-devel: allow installation without asciidoc

[Russell-Jones-OxPhys (Russell Jones)]

We'd like to install this early in our build process without pulling in too many deps, so I've added a (default) +doc variant.

I've changed

depends_lib         port:zlib \
                    port:autoconf \
                    port:asciidoc

to

depends_lib         port:zlib \
                    port:autoconf

default_variants +doc

variant doc description "Whether to build docs or not" {
	depends_build-append port:asciidoc
}
if {![variant_isset doc]} {
	configure.args-append --disable-man
}

[Russell-Jones-OxPhys (Russell Jones)]

ccache portfile with +doc variant

[mf2k (Frank Schima)]

Thanks. ​Per the guidelines, please instead attach a unified diff of the Portfile so we can easily see what changes you are proposing.

Personally I feel that adding a ccache-doc(s) sub-port is the best way to go instead.

[Russell-Jones-OxPhys (Russell Jones)]

Unified diff of changes to ccache Portfile

[ryandesign (Ryan Carsten Schmidt)]

Sorry I didn't see this ticket earlier.

I'm highly suspicious of asciidoc and autoconf having been listed as lib dependencies of ccache, without explanation. autoconf was already changed from a lib dep to a build dep as it should be but asciidoc remains declared as a lib dep, which it most likely does not need to be, since it's only used to build the manpages and is not used by ccache at runtime.

[ryandesign (Ryan Carsten Schmidt)]

In cd9de49321c755c9760e06cc6b9a71ebd5a0557b/macports-ports (master):

asciidoc: installs_libs no

See: #58460
See: #59778

[ryandesign (Ryan Carsten Schmidt)]

In ef61db74412546afa46fe3597485b2641ebec6a5/macports-ports (master):

ccache, ccache-devel: asciidoc is a build dep only

See: #58460

[ryandesign (Ryan Carsten Schmidt)]

Now that we've indicated that asciidoc doesn't install any libraries, its license no longer affects the distributability of ccache, and since nothing else prevented its distributability, we now have binary archives of ccache that we can distribute.

And now that we have properly indicated that ccache only needs asciidoc as a build dependency, asciidoc will only be installed if you build ccache from source, but won't be installed if you install a binary of ccache.

Is that sufficient? Or do you still think a variant is needed? Normally manpages are the kind of thing we would always want to install; a doc variant would normally only be used for less-frequently-used documentation.

[Russell-Jones-OxPhys (Russell Jones)]

Thanks Ryan, LGTM, but would like to confirm with my colleague who'll be back tomorrow.

[majoc-at-astro (majoc-at-astro)]

Replying to ryandesign:

And now that we have properly indicated that ccache only needs asciidoc as a build dependency, asciidoc will only be installed if you build ccache from source, but won't be installed if you install a binary of ccache.

Is that sufficient?

I'm doing a final acceptance test as we speak, but all looks good so far: installing ccache no longer pulls in half the known world to build asciidoc, which is all I was really after. Many thanks.

[ryandesign (Ryan Carsten Schmidt)]

Now that I've looked at it more closely, I don't think there was any good reason to have added the asciidoc dependency in the first place. It was done when the port was updated to 3.7.1 because the project switched to GitHub and the port was changed to get the source code using an automatically-generated tarball. Git repositories don't usually contain generated files so it's understandable that the port had to run autogen.sh and have a dependency on asciidoc in that case. But I don't know why the port used an automatically-generated tarball when it is preferable to use a release tarball if the project provides them, and ccache does. I switched the port to do that now and removed the asciidoc dependency entirely.

[ryandesign (Ryan Carsten Schmidt)]

As of version 4.0 ccache has switched to the cmake build system and no longer includes a pre-generated ccache manpage so now we do need asciidoc again to generate it.