Re: Updating net/deskflow - #include <format> and doxygen issues

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

David Brownlee <abs%absd.org@localhost> writes:

> I noticed that net/deskflow didn't build for me - turns out if doxygen
> is installed it unconditionally tries to build its docs.
>
> There was an existing "-DBUILD_DOCS=OFF" attempt to disable the docs,
> but should we be trying to build it with these (user, not dev) docs?

If the docs are useful, I think it makes sense to TOOL_DEPENDS on
doxygen.

> I looked at updating to the next version, but it now uses '#include
> <format>' which looks to be a c++20 feature... but pkgsrc allows gcc12
> for c++20... which does not include support for <format>

For better or for worse, or current convention is:

  featureA: some feature from c++nn
  featureB: another feature from c++nn
  c++nn: means the standard except that it need not support feature*

I'm not really a fan of this, because it leads to reading upstream docs
that say c++nn is required, encoding that, and then losing.

My preference is to rename our current c++nn to c++nn-lite and add c++nn
that requires a compiler with full conformance.  And leave the feature*
for those who want to play the lite/feature game.   But that obviously
needs discussion, and really obviously not in freeze.

There's a semi-related issue, to move the "round to a limited set" logic
from being open-coded in requirements (for c++nn but not features, which
I also think is wrong) to being explicit rounding based on per-platform
sets.  It probably makes sense to do that before any rototills.

> So, we could
> - Add GCC_REQD=13 to force a version of gcc that supports <format>

I object to that, because it isn't really how it is.  If you wanted to
add a format feature and code that for 13, that seems ok.  (I guess it's
a good question what the limited version set contains after 12)

> - Patch the package to not need <format> (There is already an
> __APPLE__ path that avoids it)

I think that's the best answer.  I think programs (upstreams) should try
hard to only use languages that have been in stable gcc releases for
many years, if that's at all reasonable.  gcc 13 seems very new to me,
and 13.1 was in April 2023.

> WIP diff at https://sync.absd.org/pkgsrc/deskflow.diff

strangely the WIP diff is not in pkgsrc-wip :-)


While I think patching out format is best for this package now, we're
going to have to deal sooner or later.