Re: doxygen build failing with python confusion

[Thomas Klausner <wiz%NetBSD.org@localhost>]

On Sat, Mar 25, 2023 at 01:17:38PM -0400, Greg Troxel wrote:
> Thomas Klausner <wiz%NetBSD.org@localhost> writes:
> 
> > On Sat, Mar 25, 2023 at 01:50:18PM +0100, Niclas Rosenvik wrote:
> >> Hi Greg and Thomas, as Thomas mentions in his mail there is
> >> patch-Modules_FindPythonInterp.cmake that checks if PYVERSSUFFIX is
> >> defined and uses that as a version number. PYVERSSUFFIX is passed to
> >> cmake in lang/python/pyversion.mk . It is only passed when USE_CMAKE is
> >> defined. doxygen uses devel/cmake/build.mk that does not set this
> >> variable. So checking for if devel/cmakebuild.mk is included might
> >> fix the problem. Do we have a convention on how to check for if a
> >> particular build.mk file is included? One way could be to look for the
> >> targets it defines like cmake-configure. I have tested this, aka
> >> adding "|| target(cmake-configure)" after "defined(USE_CMAKE)", in
> >> pyversion.mk and it works for me with the configuration you mention
> >> (python2.7 but no py27-expat). Also I did a grep on
> >> "defined(USE_CMAKE)" in the pkgsrc tree and the lua buildlink3 files
> >> also check for USE_CMAKE to add cmake arguments, so I hope they are not
> >> causing similar problems.
> >
> > Thanks for finding the root cause.
> >
> > I guess adding this (and similarly for lua) would be good.  (I think I
> > stumbled over this and didn't convert some packages from USE_CMAKE to
> > cmake/build.mk because they failed, and that might be the reason.)
> >
> > On the other hand, I also think it'd be nice to get rid of this
> > special handling, because it will making building using cmake outside
> > of pkgsrc harder if pkgsrc does magic that doesn't happen outside.
> 
> I'm a little baffled.
> 
> It seems that we used to have USE_CMAKE as the way for a package to say
> it built using cmake.  Now we have including cmake/build.mk.  That's
> fine, but it's IMHO a clear bug to either:
> 
>   not have build.mk set USE_CMAKE to yes
> 
>   change everything that checks USE_CMAKE to instead check if build.mk is
>   in use
> 
> That's just about the transition.  I realize there are also issues where
> each upstream package should be better, but as I see it that's just how
> the world is and it remains to file upstream bugs with N of them, and
> add the URLS to pkgsrc.
> 
> 
> Which leads to
> 
>   let's fix the use of USE_CMAKE now.  perhaps for 'now'  that menas
>   adding the alternative and post-branch it means removing USE_MAKE entirely.

I'm not sure what fix you mean here.  Setting USE_CMAKE in
cmake/build.mk is IMO not a solution since it will lead to
mk/configure/cmake.mk getting included - and that file is basically
replaced by cmake/build.mk.  This change is too big in my opinion to
go in now, since we don't even know if it improves the situation or
makes it worse; especially since the bulk builds are fine with the
current situation.

Changing lang/python/*.mk in some way is fine with me if you think it
necessary right now.

>   anyone should feel free to fix upstreams so that one passes an
>   explicit --with-python=/usr/pkg/bin/python3.10 to the cmake build
>   (really however that is spelled in cmake; it would have been too
>   simple to accept autoconf-style args...).

CMake has a different argument syntax, it's basically CMAKE_ARGS+=-DFOO=bar
 Thomas