Re: [Buildroot] [PATCH v2 5/5] package/xz: convert to cmake build

["Yann E. MORIN" <yann.morin.1998@free.fr>]

Peter, All,

(To avoid confusion: Yann@home speaking here)

On 2024-06-26 10:36 +0200, Peter Seiderer via buildroot spake thusly:
> On Tue, 25 Jun 2024 13:11:12 +0200, yann.morin@orange.com wrote:
> > On 2024-06-25 11:56 +0200, MORIN Yann INNOV/IT-S spake thusly:
> > > On 2024-06-12 15:57 +0200, Peter Seiderer via buildroot spake thusly:
> > > > Convert to cmake build with the following autoconf options without
> > > > direct equivalent cmake option:
> >
> > The autotools build system is still operational, and still works. So,
> > what was the rationale behind that change?
> >
> > Was that a defence against another backdooring attempt? If so, I think
> > it should have been stated clearly in the commit log. Also, we can be as
> > paranoid as we want, but it is possible to inject a similar backdoor
> > in cmake as was injected in autotools, so switching to cmake just for
> > this reason is not rally sufficient...
> 
> No, as the first suggestion ([1], marked as RFC - missed the RFC marking in
> patch set version v2) predates the backdoor detection (but migrating away from
> autoconf/automake was discusses as one measure for backdoor avoidance),
> my motivation was the following passage from the NEWS file ([2]):
> 
>         - The CMake-based build is now close to feature parity with the
>           Autotools-based build. Most importantly a few tests aren't
>           run yet. Testing the CMake-based build on different operating
>           systems would be welcome now. See the comment at the top of
>           CMakeLists.txt.
> 
> And the amount of work done for the cmake build system seems to hint
> that xz is moving away from autoconf/automake towards the cmake system...

Note that there is also some effort toward a meson-based buildsystem:
    https://github.com/tukaani-project/xz/pull/120

> > Note: the issue I hit can be solved by passing ENABLE_NLS=OFF in the
> > host variant; we don't really require translations, so we can
> > unconditionally turn it off.
> 
> Seems my intermediate step from 'package/xz: determine all autoconf options'
> and '--enable-nls' unconditionally for the host variant was wrong...,

Also, forcibly setting BUILD_SHARED_LIBS=OFF for the target is probably
wrong. And using the target options for the host is equivalently very
wrong.

> care to send a patch (as you can reproduce the failure)?

Yann@work provided a very sinple way to reproduce the issue:

    $ ./utils/docker-run
    (docker) $ make defconfig
    (docker) $ make host-xz

So you could at least try that to reproduce on your side.

He also provided a suggestion to turn NLS=OFF, but that was suposedly
not needed in your case, so there is something to investigate.

When maintainers apply patches, they accept that it may break something
down the line, so it is not a problem that a patch had issues; they
guess the contributor tested as best as they could, and the
reviewer-committer do their best as well, so it was good to be applied.

However, when maintainers apply patches, they also expect contributors
to own their changes, and that they are pro-active in trying to fix
their change that caused the breakage, without swinging the effort to
someone else without at least trying to reproduce and investigate on
their side. After all, the contributor is in the best position to
investigate: they know the purpose of the change, and they have the
knowledge of the tests they did, so they know where to look at.

If maintainers can't rely on that expectation, then they can get very
chilly about applying patches as they know any breakage might not be
acted upon, and that the burden of fixing it will pile upon them to
increase the existing load...

Again, it is not a problem that the patch broke something; without
trying, we can know. There is absolutely no blame on you at all for that
patch! We are very happy for your contributions! :-)

Still, this carelessness in handling a breakage is a bit disapointing...

Anyway, I have now reverted that patch, as it was exposing another issue
with host-python3 (https://gitlab.com/buildroot.org/buildroot/-/issues/5)

When the cmake buildsystem is official, then do not hesitate to resubmit
an improved patch, based on the commit that was initially applied. If
you hit a road-block, do not hesitate to ask for further help, of
course!

Thank you!

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot