On Mon, Apr 8, 2024 at 5:37 AM Zbigniew Jędrzejewski-Szmek
<zbyszek@xxxxxxxxx> wrote:
>
> On Mon, Apr 08, 2024 at 12:03:19AM +0200, Kevin Kofler via devel wrote:
> > I wrote:
> > > On Sun, Apr 7 2024 at 13:52:26 +00:00:00, Zbigniew Jędrzejewski-Szmek
> > > <zbyszek@xxxxxxxxx> wrote:
> > >> Hmm, why? Oh, rpm uses cmake, and cmake has it's own special
> > >> detection of python, and it found /usr/bin/python3.13t that I have
> > >> installed, and subsequently it got all the paths wrong.
> > >
> > > That's why you should never build packages outside of mock.
>
> That's another way of saying "it's broken" ;]
> Mock is great, but I'm doing local development and a local build
> against my envirnoment is what I need.
>
> > PS: Autotools also loves to autodetect random libraries that happen to be
> > installed on the system. It is in no way specific to CMake.
> >
> > >> How do I override this?
> > >> ('cmake -LAH' doesn't yield anything useful.)
> >
> > Usually -DSOME_VARIABLE=/some/path is the way, look in FindPython.cmake for
> > the variables it uses. (First, try to figure out whether RPM is using a
> > system-installed FindPython or its own custom version, so you look at the
> > correct version.)
>
> Exactly. I'm sure it doable, but CMake ecosystem somehow doesn't
> want to integrate with the Linux userspace in the normal way.
>
You know that pkgconfig *also* uses variables too, right? It's
perfectly "normal" to do it this way. Arguably, the fact that every
variable is known and saved in the CMakeLists and CMakeCache data for
you to read is a boon, because if you need to know a variable to
override, you can find it easily in the logs.
And this your statement on normalcy is silly since we don't *have* a
normal way. The GNU Build System (Autotools), Meson, and CMake all do
things differently, and all three have significant share in our
packages. Projects that use plain Makefiles are even *more*
non-standard, as they do whatever they want too.
--
真実はいつも一つ！/ Always, there's only one truth!
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
