cmake.mk: add indirect argument for ports

[makc]

Summary

cmake:indirect is intended primarily for ports, which use meson or pep517 for build, but rely on cmake underneath. cmake:indirect adds cmake to BUILD_DEPENDS and exposes CMAKE_ARGS and some other bits, which can be of use.

Update documentation as well.

See also:
https://bugs.freebsd.org/274505

Test Plan

ports can be converted one by one, I've already tested a couple of them.

[makc]

Update diff with full context.

[adridg]

With kde@ hat on, but only nit-picking on language in comments. I think Gleb's question in the PR is relevant, though: what does this do-or-simplify that BUILD_DEPENDS does not?

CHANGES

18

Mk/Uses/cmake.mk

8

9

37

50

[makc]

In D44509#1015209, @adridg wrote:

With kde@ hat on, but only nit-picking on language in comments. I think Gleb's question in the PR is relevant, though: what does this do-or-simplify that BUILD_DEPENDS does not?

/
This hides from consumers that cmake port has been split and cmake binary is provided by devel/cmake-core. Secondly, cmake:noconf allows ports to use CMAKE_* helpers from cmake.mk, although I don't know whether pep517 (or meson, cargo, etc.) should use them, but several ports which use cmake for a side target could be simplified.

[arrowd]

In D44509#1015388, @makc wrote:

This hides from consumers that cmake port has been split and cmake binary is provided by devel/cmake-core.

I don't see this a big problem. I doubt there would be another disruption caused by renaming the port again.

Secondly, cmake:noconf allows ports to use CMAKE_* helpers from cmake.mk, although I don't know whether pep517 (or meson, cargo, etc.) should use them, but several ports which use cmake for a side target could be simplified.

I think this change should come with respective changes in consumer ports to show off the value.

[makc]

In D44509#1015389, @arrowd wrote:

In D44509#1015388, @makc wrote:

This hides from consumers that cmake port has been split and cmake binary is provided by devel/cmake-core.

I don't see this a big problem. I doubt there would be another disruption caused by renaming the port again.

I don't see a big problem here too. This change is more stylistic rather than functional.

Secondly, cmake:noconf allows ports to use CMAKE_* helpers from cmake.mk, although I don't know whether pep517 (or meson, cargo, etc.) should use them, but several ports which use cmake for a side target could be simplified.

I think this change should come with respective changes in consumer ports to show off the value.

e.g. deskutils/mindforger, sysutils/datadog-agent.
There are also x11-wm/gamescope, x11-wm/hyprland, x11/waybar however these ports would not need this after FreeBSD 13 EOL.

[makc]

Apply Ade's suggestions and convert a couple of ports for example.

[arrowd]

I'm still unsure if it is worth it. Anyways, a bit of bikeshedding - the seemingly similar python.mk option is called env. Maybe follow pythom.mk here?

[makc]

In D44509#1015772, @arrowd wrote:

I'm still unsure if it is worth it. Anyways, a bit of bikeshedding - the seemingly similar python.mk option is called env. Maybe follow pythom.mk here?

Not a bikeshedding at all. I named it build at first, then I thought it could be confusing in the cmake context, despite common meaning of build in USES. I've thought about env too, however usually env exports variables only and does not add any dependencies. I'm not fond of noconf name also, so I welcome other options.

[diizzy]

For consistency with other USES toggles I think build fits better however I think the cmake configuration bits should be broken out from build into a separate toggle or combined into another toggle.

I personally think it makes more sense in terms of consistency to keep cmake dependencies into USES rather than having it partially.

[arrowd]

Can't agree with Daniel here. USES=cmake should be the most common case which is "depend on cmake executable and use it for configuring the project'. The cmake:build might be misleading - I'd think of it as the same as just cmake currently is.

The most appropriate course IMO is cmake:env and just define CMAKE_DEP to be used in consumer ports. It follows the python.mk idea in both :env part and a knob to be used in *_DEPENDS (like ${PY_CRYPTOGRAPHY}, ${PY_PILLOW}, etc.)

[makc]

In D44509#1015937, @arrowd wrote:

Can't agree with Daniel here. USES=cmake should be the most common case which is "depend on cmake executable and use it for configuring the project'. The cmake:build might be misleading - I'd think of it as the same as just cmake currently is.

+

The most appropriate course IMO is cmake:env and just define CMAKE_DEP to be used in consumer ports. It follows the python.mk idea in both :env part and a knob to be used in *_DEPENDS (like ${PY_CRYPTOGRAPHY}, ${PY_PILLOW}, etc.)

Well in this case ports would need both USES=cmake:env and BUILD_DEPENDS+=${CMAKE_DEP} to record dependency on cmake. Seems excessive to me. Moreover, nothing in the ports tree needs plain cmake:env without dependency on cmake.

[arrowd]

In D44509#1017272, @makc wrote:

Moreover, nothing in the ports tree needs plain cmake:env without dependency on cmake.

That makes sense. All right, let it be noconf then.

A couple of inline comments follow.

CHANGES

16

From what I learned about English in school this should say "now supports" with "s" at the end.

Mk/Uses/cmake.mk

75–79

Hmm, isn't .if ${cmake_ARGS:M_internal} enough?

130

Don't we need && empty(cmake_ARGS:Mrun) here?

137

Same here, if run is like noconf but for RUN_DEPENDS then we need && empty(cmake_ARGS:Mrun)

[makc]

In D44509#1017273, @arrowd wrote:

In D44509#1017272, @makc wrote:

Moreover, nothing in the ports tree needs plain cmake:env without dependency on cmake.

That makes sense. All right, let it be noconf then.

Shall we call it indirect? It is not obscure as noconf and it implies that cmake is used somehow, making obvious dependency on cmake.

Mk/Uses/cmake.mk

75–79

No difference, I've just kept the original line.

130

No, if run means use cmake for configure and add cmake to the RUN_DEPENDS. I've tried to keep the original logic while introducing new cmake argument. If we are going to change meaning of run, I'd prefer to make it in a separate commit.

[makc]

Rename cmake:noconf to cmake:indirect

[arrowd]

Mk/Uses/cmake.mk

130

Ah, sorry, I missed the fact that run was already present before your change. Disregard all my run-related comments, then.