On Mon, Apr 08, 2024 at 05:52:07AM -0400, Neal Gompa wrote:
> 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.
So… this is what I'm talking about: there is no obvious way to
figure out what to set. Looking at the logs and trying to figure out
some variables from that is not very attractive.
Of course I know pgkconfig uses variables, I don't know what you
are trying to say.
I think CMake hits the "sour spot" here in a few different ways:
- because of the historical mindset, instead of using standard
mechanisms that everybody else uses, it implements custom detection,
- this autodetection very often does things wrong,
- because of the approach with Find* scripts, each package is different
and each detection script has a custom interface, so overriding things
is a lot of work,
- the complicated language that is partially variable-based, partially
macro-based is not easy to follow.
autotools has './configure --help',
meson has all options in `meson_options.txt' and also 'meson configure'
will print all options,
but with CMake the options are buried in Find* and not easy to figure out.
> 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.
Yeah, I know we have a bazillion build systems. And all have
to work and the packagers need to use and understand all of them.
Nevertheless, for me, CMake and autotools are outdated technologies
that shouldn't be used in new projects.
Zbyszek
--
_______________________________________________
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
