Re: PYTHON_FOR_BUILD_ONLY in lang/python/tool.mk

[Taylor R Campbell <campbell+netbsd-tech-pkg%mumble.net@localhost>]

> Date: Wed, 22 Nov 2023 11:37:10 +0000
> From: Jonathan Perkin <jperkin%mnx.io@localhost>
> 
> By far the biggest offender with the implicit DEPENDS issue is python.  
> 
> The problem is that lots of packages simply do this:
> 
>    .include "../../lang/python/tool.mk"
> 
> assuming that this will pull python in as a tool only.
> 
> However, it doesn't.  Unless PYTHON_FOR_BUILD_ONLY is specifically set 
> to "tool" prior to pulling it in, pyversion.mk will include the python 
> buildlink3.mk and we end up with the gettext/iconv issues.

I think this is a long-standing abuse of buildlink for tools that
arose in the time before we had TOOL_DEPENDS.  Even after that, the
distinction didn't seem to matter except to us weirdos who do
cross-compilation.  But it looks like the chickens are finally coming
home to roost on that abuse.

> I'd like to propose we at least do the following:
> 
>    --- a/lang/python/tool.mk
>    +++ b/lang/python/tool.mk
>    @@ -12,6 +12,7 @@
>     PYTHON_TOOL_MK=        defined
>     
>     .if !defined(PYTHON_PYVERSION_MK)
>    +PYTHON_FOR_BUILD_ONLY?=        tool
>     .include "../../lang/python/pyversion.mk"
>     .endif
> 
> so that packages that simply include tool.mk on the assumption that it 
> will only be used as a tool (a pretty reasonable assumption in my 
> opinion?) will DTRT.

Sounds reasonable.

> After that we'll need to go around and remove PYTHON_FOR_BUILD_ONLY=yes 
> from packages that really mean "tool".  These two changes fix 
> fontconfig, etc.

Sounds reasonable although it would also be reasonable to rename
things so they're less confusing.

When I introduced PYTHON_FOR_BUILD_ONLY=tool as a not-quite-boolean,
it was because I was reluctant to make tree-wide renovations just for
cross-compilation, so I added a new name for new semantics on top of
the existing boolean option.

(My first attempt in pyversion.mk 1.107 was to make
PYTHON_FOR_BUILD_ONLY=yes _always_ yield a tool dependency, never
buildlink3, but that broke things, so I went for the more circumspect
three-way route after that in 1.108.)