Re: doxygen build failing with python confusion

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

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.

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