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?

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.

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.

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.

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?

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.

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.

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.)

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.

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.

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.