tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: doxygen build failing with python confusion

On Sat, Mar 25, 2023 at 01:17:38PM -0400, Greg Troxel wrote:
> Thomas Klausner <> 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/ . It is only passed when USE_CMAKE is
> >> defined. doxygen uses devel/cmake/ that does not set this
> >> variable. So checking for if devel/ is included might
> >> fix the problem. Do we have a convention on how to check for if a
> >> particular 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
> >> 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/ 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/  That's
> fine, but it's IMHO a clear bug to either:
>   not have set USE_CMAKE to yes
>   change everything that checks USE_CMAKE to instead check if 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/ is IMO not a solution since it will lead to
mk/configure/ getting included - and that file is basically
replaced by cmake/  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

Home | Main Index | Thread Index | Old Index