Re: cmake circular dependency

[Greg Troxel <gdt%lexort.com@localhost>]

Thomas Klausner <wiz%netbsd.org@localhost> writes:

> On Fri, Jul 24, 2026 at 12:05:43PM +0100, Jonathan Perkin wrote:
>> Adam's groff update also included this line:
>> 
>>   +DEPENDS+=      netpbm>=10.0:../../graphics/netpbm
>> 
>> but again I don't know why this is now necessary (it feels pretty
>> heavyweight to me, especially as groff is often a core tool).
>
> After disabling both dependencies, groff's configure says:

Thanks for doing this.

I think we are having a major collaboration problem in pkgsrc.  Adam
committed a change that caused serioue breakage -- unintentionally I'm
sure -- and has not been present in the discussion, which started 3 days
ago.

While we have a "don't revert" norm, that should only apply to commits
that meet pkgsrc standards (do not cause breakage AND are not over the
line that should have been discussed).  We should freely, quickly, and
with minimal discussion revert things that cause significant breakage,
and then figure out how to redo them.

> configure: The uchardet library was not found.
>
>   The 'preconv' preprocessor program will be unable to attempt automatic
>   inference of an input file's character encoding.  See the preconv(1)
>   man page.
>
> configure: The programs 'pnmcrop', 'pamcut', 'pnmtopng', and 'pnmtops' were not found in $PATH.
>
>   Consequently, groff's HTML output driver, 'grohtml', will not work
>   properly.  It will not be possible to prepare or install
>   groff-generated documentation in HTML format.
>
> I'll make netpbm another default-off option. We can enable them again
> when the 'simple' cmake exists.

The real bug is that the cmake package depends on groff.   Surely groff
is not necessary to build packages with cmake.

(That's on top of "the real bug is cmake", which does not appear to
grasp that build tools need to be minimal -- but that's not going to get
fixed.)

It's work of course, but it would seem that any package which is in a
build system dependency chain should have minimal dependencies, and that
anything which can be in a split package can be, and documentation
certainly is in that category.

> Btw, I'd appreciate an option to use the newest cmake instead of the
> 'simple' one.

I think it's important that people developing pkgsrc are using the same
toolchain as the default bulk builds, to avoid latent problems.   It's
an interesting question as to how recent cmake ought to be.

I'm not sure there's real value in intentionally having cmake-minimal be
really old, vs just updated judiciously, rather than reflexively without
considering the implications when there's a release.   Having build skew
between cmake and cmake-minimal seems seriously unhelpful, and the newer
cmake-minimal is, the less of that.  There's a least-total-pain tradeoff
someplace.