[Buildroot] [PATCH 1/2] meson: add entry for libgcrypt-config in cross file
Peter Seiderer
ps.report at gmx.net
Thu May 2 20:02:26 UTC 2019
Hello Arnout,
On Thu, 2 May 2019 14:17:45 +0200, Arnout Vandecappelle <arnout at mind.be> wrote:
> On 01/05/2019 21:04, Peter Seiderer wrote:
> > Hello Arnout,
> >
> > On Wed, 1 May 2019 13:13:03 +0200, Arnout Vandecappelle <arnout at mind.be> wrote:
> >
> >> On 30/04/2019 13:04, Jörg Krause wrote:
> >>> Hello Peter,
> >>>
> >>> On Tue, 2019-04-30 at 10:27 +0200, Peter Seiderer wrote:
> >> [snip]
> >>>> Would have expected the trick/non-trivial thing to add more than one
> >>>> binary entry (to get the newlines for the entries right)...
> >>>
> >>> That's indeed a difficult case to solve. I didn't managed to get
> >>> multpile binary entries added to the [binaries] field, e.g.
> >>>
> >>> PKG_TARGET_BINARIES = \
> >>> libgcrypt-config = '...' \
> >>> llvm-config = '...'
> >>>
> >>> .. will not work.
> >>>
> >>> I spent some time to find a magic rule which splits the Makefile
> >>> variable into a proper newline seperated string which can be used by
> >>> sed, but I failed.
> >>>
> >>> Maybe you have an idea?
> >>
> >> Instead of sed, use the PRINTF macro and append to the file:
> >>
> >> $Q$$(if $$($$(PKG)_TARGET_BINARIES),\
> >> $$(call PRINTF,$$($$(PKG)_TARGET_BINARIES)) \
> >> >> $$($$(PKG)_SRCDIR)/build/cross-compilation.conf
> >
> > Simple appending will not work, the extra binaries must be under the '[binaries]'
> > section (maybe reordering the sections in the cross-compilation.conf.in template
> > will work)
>
> It should work if the [binaries] part is at the end, right? And if binaries is
> empty, that's OK, no?
>
> Alternatively, the [binaries] part could be included in the _TARGET_BINARIES
> (which would then have to be renamed to _CROSS_COMPILATION_CONF). So for a
> package that needs libgcrypt-config, it would be
>
> define FOO_CROSS_COMPILATION_CONF
> [binaries]
> libgcrypt-config = '$(STAGING_DIR)/usr/bin/libgcrypt-config'
> endef
With this and the printf approach I get the following in the cross-compilation.conf
file (mind the leading spaces in the binaries line):
[host_machine]
system = 'linux'
cpu_family ='arm'
cpu = 'cortex-a53'
endian = 'little'
[binaries]
libgcrypt-config = '.../host/arm-buildroot-linux-gnueabihf/sysroot/usr/bin/libgcrypt-config'
And meson complains with:
ERROR: Malformed value in cross file variable endian.
Regards,
Peter
>
> > , does the printf approach fix the newline problem for more than one
> > entry?
>
> It does, but you can't use _CROSS_COMPILATION_CONF = ..., you have to use
> define, because the actual newlines have to be in the variable itself. Actually,
> you can still use = assignment, but then you need to use $(sep), i.e.:
>
> FOO_CROSS_COMPILATION_CONF = [binaries]$(sep)libgcrypt-config =
> '$(STAGING_DIR)/usr/bin/libgcrypt-config'$(sep)
>
> (which is ugly so don't do that :-)
>
>
> >
> >>
> >>
> >> Completely unrelated to this, but I notice now some things in that pkg-meson.mk
> >> that make me wonder what our coding style is in pkg-infra.mk files... Adding
> >> Yann and Eric in Cc for that.
> >>
> >> - We usually use $(2), but here it's $$(PKG). Recently there was a patch that
> >> changed the $(PKG) back to $(2) in the download infra. So I think we really
> >> should be using $(2).
> >
> > Any link to the relevant patch? Can test/rework my patch/pkg-meson.mk in case...
>
> 5a0d6813948fea2cdb88a2e35984520eec856dec
>
> Note that the reasons for doing it in that patch don't apply here. However, I
> feel it is better/easier to have a general rule to always do things the same
> way, which is diverged from only in specific cases when there is a good reason
> to diverge. Like we have the rule that in macros which get $(eval)'ed, we always
> use $$ (even though it's really needed only in a small minority of the instances).
>
> It doesn't really matter which one we choose, $(PKG) or $(2), as long as it is
> done consistently.
>
> The advantage of $(PKG) is that it can be used in contexts where you don't have
> a $(2). The advantage of $(2) is that it is less surprising - by the time $(PKG)
> gets expanded, it's hard to be sure which value it has (depends on the rule
> within which it is expanded).
>
>
> >> - meson infra builds in PKG_SRCDIR/build. That really should be PKG_BUILDDIR,
> >> with a default of $(2)_BUILDDIR ?= $$($(2)_SRCDIR)/build.
> >
> > O.k.
> >
> >>
> >> - I don't think it's appropriate to generate the cross-compilation.conf file in
> >> PKG_BUILDDIR. I think it should be at top level, i.e. $(@D).
> >
> > Why (I think more a matter of taste?)? With cross-compilation.conf in PKG_BUILDDIR
> > (or in other words build) it is automatically removed/refreshed by pkg-meson.mk
> > (see the rm command in the configure step) and there is no danger of potentially
> > collision with an already source package provided version?
>
> It's a matter of taste unless there are additional reasons, and you gave
> additional reasons, so it's no longer a matter of taste :-) Let's keep it in
> BUILDDIR.
>
> Regards,
> Arnout
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
More information about the buildroot
mailing list