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

[Peter Seiderer via buildroot <buildroot@buildroot.org>]

Hello Yann,

On Tue, 25 Jun 2024 13:11:12 +0200, yann.morin@orange.com wrote:

> Peter, All,
>
> 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: 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...,
care to send a patch (as you can reproduce the failure)?

>
> However, we might hit a similar issue in target builds, and there, I am
> not sure what would be the best solution...

Already handled(?) in package/xz/xz.mk:

ifeq ($(BR2_SYSTEM_ENABLE_NLS),y)
XZ_CONF_OPTS += -DENABLE_NLS=ON
else
XZ_CONF_OPTS += -DENABLE_NLS=OFF
endif

Regards,
Peter

[1] https://lore.kernel.org/all/20240307165218.10027-4-ps.report@gmx.net/
[2] https://github.com/tukaani-project/xz/blob/master/NEWS

>
> Regards,
> Yann E. MORIN.
>
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot