[1/2] meson: add entry for libgcrypt-config in cross file
diff mbox series

Message ID 20190403183202.19682-1-joerg.krause@embedded.rocks
State Changes Requested
Headers show
Series
  • [1/2] meson: add entry for libgcrypt-config in cross file
Related show

Commit Message

Jörg Krause April 3, 2019, 6:32 p.m. UTC
Since version 0.49.0 the Meson build system has native support for
looking for `libgcrypt-config` if no pkg-config file is found. As the
latest version 1.8.4 of libgcrypt does not provide a .pc file, using
`libgcrypt-config` is the only way for detecting the required libraries
when linking agains libgrypt.

The `libgcrypt-config` entry is necessary for updating package mpd,
which switched from the Autotools to the Meson build system when bumping
from version 0.20 to 0.21.

Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
---
 package/meson/cross-compilation.conf.in | 1 +
 package/meson/meson.mk                  | 1 +
 package/pkg-meson.mk                    | 1 +
 3 files changed, 3 insertions(+)

Comments

Thomas Petazzoni April 3, 2019, 7:33 p.m. UTC | #1
Hello,

On Wed,  3 Apr 2019 20:32:01 +0200
Jörg Krause <joerg.krause@embedded.rocks> wrote:

> Since version 0.49.0 the Meson build system has native support for
> looking for `libgcrypt-config` if no pkg-config file is found. As the
> latest version 1.8.4 of libgcrypt does not provide a .pc file, using
> `libgcrypt-config` is the only way for detecting the required libraries
> when linking agains libgrypt.
> 
> The `libgcrypt-config` entry is necessary for updating package mpd,
> which switched from the Autotools to the Meson build system when bumping
> from version 0.20 to 0.21.
> 
> Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
> ---
>  package/meson/cross-compilation.conf.in | 1 +
>  package/meson/meson.mk                  | 1 +
>  package/pkg-meson.mk                    | 1 +
>  3 files changed, 3 insertions(+)
> 
> diff --git a/package/meson/cross-compilation.conf.in b/package/meson/cross-compilation.conf.in
> index fc8e27f7eb..b68499a6fa 100644
> --- a/package/meson/cross-compilation.conf.in
> +++ b/package/meson/cross-compilation.conf.in
> @@ -9,6 +9,7 @@ cpp = '@TARGET_CROSS@g++'
>  ar = '@TARGET_CROSS@ar'
>  strip = '@TARGET_CROSS@strip'
>  pkgconfig = '@HOST_DIR@/usr/bin/pkg-config'
> +libgcrypt-config = '@STAGING_DIR@/usr/bin/libgcrypt-config'

Hm, this is a bit annoying. We really have no other solution but to
pass this through cross-compilation.conf ? It cannot be passed on the
meson command line, on a per-package basis, like we do for the autotools ?

Thanks,

Thomas
Jörg Krause April 5, 2019, 6:58 a.m. UTC | #2
Hello,

Am Mittwoch, den 03.04.2019, 21:33 +0200 schrieb Thomas Petazzoni:
> Hello,
> 
> On Wed,  3 Apr 2019 20:32:01 +0200
> Jörg Krause <joerg.krause@embedded.rocks> wrote:
> 
> > Since version 0.49.0 the Meson build system has native support for
> > looking for `libgcrypt-config` if no pkg-config file is found. As the
> > latest version 1.8.4 of libgcrypt does not provide a .pc file, using
> > `libgcrypt-config` is the only way for detecting the required libraries
> > when linking agains libgrypt.
> > 
> > The `libgcrypt-config` entry is necessary for updating package mpd,
> > which switched from the Autotools to the Meson build system when bumping
> > from version 0.20 to 0.21.
> > 
> > Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
> > ---
> >  package/meson/cross-compilation.conf.in | 1 +
> >  package/meson/meson.mk                  | 1 +
> >  package/pkg-meson.mk                    | 1 +
> >  3 files changed, 3 insertions(+)
> > 
> > diff --git a/package/meson/cross-compilation.conf.in b/package/meson/cross-compilation.conf.in
> > index fc8e27f7eb..b68499a6fa 100644
> > --- a/package/meson/cross-compilation.conf.in
> > +++ b/package/meson/cross-compilation.conf.in
> > @@ -9,6 +9,7 @@ cpp = '@TARGET_CROSS@g++'
> >  ar = '@TARGET_CROSS@ar'
> >  strip = '@TARGET_CROSS@strip'
> >  pkgconfig = '@HOST_DIR@/usr/bin/pkg-config'
> > +libgcrypt-config = '@STAGING_DIR@/usr/bin/libgcrypt-config'
> 
> Hm, this is a bit annoying. We really have no other solution but to
> pass this through cross-compilation.conf ? It cannot be passed on the
> meson command line, on a per-package basis, like we do for the autotools ?

I am not a Meson expert, but I did not find any options howto pass
libgcrypt-config path through the command line.

Best regards
Jörg Krause
Thomas Petazzoni April 13, 2019, 4:24 p.m. UTC | #3
Hello Jörg,

+Peter Seiderer in Cc.

On Wed,  3 Apr 2019 20:32:01 +0200
Jörg Krause <joerg.krause@embedded.rocks> wrote:

> Since version 0.49.0 the Meson build system has native support for
> looking for `libgcrypt-config` if no pkg-config file is found. As the
> latest version 1.8.4 of libgcrypt does not provide a .pc file, using
> `libgcrypt-config` is the only way for detecting the required libraries
> when linking agains libgrypt.
> 
> The `libgcrypt-config` entry is necessary for updating package mpd,
> which switched from the Autotools to the Meson build system when bumping
> from version 0.20 to 0.21.
> 
> Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>

As I said in my previous reply, I'm not too happy with this
libgcrypt-config variable creeping into the global cross-compilation
file. Can we instead look at extending what Peter Seiderer is doing in
http://patchwork.ozlabs.org/patch/1081486/ and allow some per-package
additions to the per-package cross-compilation file ? Peter's patch
does it for CFLAGS/CXXFLAGS/LDFLAGS, we could perhaps do the same with
arbitrary program paths ?

Thanks!

Thomas
Peter Seiderer April 23, 2019, 9:29 p.m. UTC | #4
Hello Jörg, Thomas,

On Sat, 13 Apr 2019 18:24:22 +0200, Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:

> Hello Jörg,
> 
> +Peter Seiderer in Cc.
> 
> On Wed,  3 Apr 2019 20:32:01 +0200
> Jörg Krause <joerg.krause@embedded.rocks> wrote:
> 
> > Since version 0.49.0 the Meson build system has native support for
> > looking for `libgcrypt-config` if no pkg-config file is found. As the
> > latest version 1.8.4 of libgcrypt does not provide a .pc file, using
> > `libgcrypt-config` is the only way for detecting the required libraries
> > when linking agains libgrypt.
> > 
> > The `libgcrypt-config` entry is necessary for updating package mpd,
> > which switched from the Autotools to the Meson build system when bumping
> > from version 0.20 to 0.21.
> > 
> > Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>  
> 
> As I said in my previous reply, I'm not too happy with this
> libgcrypt-config variable creeping into the global cross-compilation
> file. Can we instead look at extending what Peter Seiderer is doing in
> http://patchwork.ozlabs.org/patch/1081486/ and allow some per-package
> additions to the per-package cross-compilation file ? Peter's patch
> does it for CFLAGS/CXXFLAGS/LDFLAGS, we could perhaps do the same with
> arbitrary program paths ?

Something like the following (draft) should work:

diff --git a/package/meson/cross-compilation.conf.in b/package/meson/cross-compilation.conf.in
index 4056c2b2f4..7cd372128e 100644
--- a/package/meson/cross-compilation.conf.in
+++ b/package/meson/cross-compilation.conf.in
@@ -9,6 +9,7 @@ cpp = '@TARGET_CROSS@g++'
 ar = '@TARGET_CROSS@ar'
 strip = '@TARGET_CROSS@strip'
 pkgconfig = '@HOST_DIR@/usr/bin/pkg-config'
+@PKG_TARGET_BINARIES@
 
 [properties]
 needs_exe_wrapper = true
diff --git a/package/meson/meson.mk b/package/meson/meson.mk
index 70128f6bad..e550c80c9d 100644
--- a/package/meson/meson.mk
+++ b/package/meson/meson.mk
@@ -60,6 +60,7 @@ define HOST_MESON_INSTALL_CROSS_CONF
            -e "s%@TARGET_CFLAGS@%$(HOST_MESON_SED_CFLAGS)%g" \
            -e "s%@TARGET_LDFLAGS@%$(HOST_MESON_SED_LDFLAGS)%g" \
            -e "s%@TARGET_CXXFLAGS@%$(HOST_MESON_SED_CXXFLAGS)%g" \
+           -e "s%@PKG_TARGET_BINARIES@%%g" \
            -e "s%@PKG_TARGET_CFLAGS@%%g" \
            -e "s%@PKG_TARGET_LDFLAGS@%%g" \
            -e "s%@PKG_TARGET_CXXFLAGS@%%g" \
diff --git a/package/pkg-meson.mk b/package/pkg-meson.mk
index 9974b1e513..93df43fe3e 100644
--- a/package/pkg-meson.mk
+++ b/package/pkg-meson.mk
@@ -74,6 +74,7 @@ define $(2)_CONFIGURE_CMDS
            -e "s%@TARGET_CFLAGS@%$$(HOST_MESON_SED_CFLAGS)%g" \
            -e "s%@TARGET_LDFLAGS@%$$(HOST_MESON_SED_LDFLAGS)%g" \
            -e "s%@TARGET_CXXFLAGS@%$$(HOST_MESON_SED_CXXFLAGS)%g" \
+           -e "s%@PKG_TARGET_BINARIES@%$$($$(PKG)_MESON_BINARIES)%g" \
            -e "s%@PKG_TARGET_CFLAGS@%$$($$(PKG)_MESON_SED_CFLAGS)%g" \
            -e "s%@PKG_TARGET_LDFLAGS@%$$($$(PKG)_MESON_SED_LDFLAGS)%g" \
            -e "s%@PKG_TARGET_CXXFLAGS@%$$($$(PKG)_MESON_SED_CXXFLAGS)%g" \


and with: 

MPD_MESON_BINARIES = libgcrypt-config = '$(STAGING_DIR)/usr/bin/libgcrypt-config'

Regards,
Peter

> 
> Thanks!
> 
> Thomas
Jörg Krause April 24, 2019, 11:09 a.m. UTC | #5
Hello Peter,

On Tue, 2019-04-23 at 23:29 +0200, Peter Seiderer wrote:
> Hello Jörg, Thomas,
> 
> On Sat, 13 Apr 2019 18:24:22 +0200, Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
> 
> > Hello Jörg,
> > 
> > +Peter Seiderer in Cc.
> > 
> > On Wed,  3 Apr 2019 20:32:01 +0200
> > Jörg Krause <joerg.krause@embedded.rocks> wrote:
> > 
> > > Since version 0.49.0 the Meson build system has native support for
> > > looking for `libgcrypt-config` if no pkg-config file is found. As the
> > > latest version 1.8.4 of libgcrypt does not provide a .pc file, using
> > > `libgcrypt-config` is the only way for detecting the required libraries
> > > when linking agains libgrypt.
> > > 
> > > The `libgcrypt-config` entry is necessary for updating package mpd,
> > > which switched from the Autotools to the Meson build system when bumping
> > > from version 0.20 to 0.21.
> > > 
> > > Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>  
> > 
> > As I said in my previous reply, I'm not too happy with this
> > libgcrypt-config variable creeping into the global cross-compilation
> > file. Can we instead look at extending what Peter Seiderer is doing in
> > http://patchwork.ozlabs.org/patch/1081486/ and allow some per-package
> > additions to the per-package cross-compilation file ? Peter's patch
> > does it for CFLAGS/CXXFLAGS/LDFLAGS, we could perhaps do the same with
> > arbitrary program paths ?
> 
> Something like the following (draft) should work:
> 
> diff --git a/package/meson/cross-compilation.conf.in b/package/meson/cross-compilation.conf.in
> index 4056c2b2f4..7cd372128e 100644
> --- a/package/meson/cross-compilation.conf.in
> +++ b/package/meson/cross-compilation.conf.in
> @@ -9,6 +9,7 @@ cpp = '@TARGET_CROSS@g++'
>  ar = '@TARGET_CROSS@ar'
>  strip = '@TARGET_CROSS@strip'
>  pkgconfig = '@HOST_DIR@/usr/bin/pkg-config'
> +@PKG_TARGET_BINARIES@
>  
>  [properties]
>  needs_exe_wrapper = true
> diff --git a/package/meson/meson.mk b/package/meson/meson.mk
> index 70128f6bad..e550c80c9d 100644
> --- a/package/meson/meson.mk
> +++ b/package/meson/meson.mk
> @@ -60,6 +60,7 @@ define HOST_MESON_INSTALL_CROSS_CONF
>             -e "s%@TARGET_CFLAGS@%$(HOST_MESON_SED_CFLAGS)%g" \
>             -e "s%@TARGET_LDFLAGS@%$(HOST_MESON_SED_LDFLAGS)%g" \
>             -e "s%@TARGET_CXXFLAGS@%$(HOST_MESON_SED_CXXFLAGS)%g" \
> +           -e "s%@PKG_TARGET_BINARIES@%%g" \
>             -e "s%@PKG_TARGET_CFLAGS@%%g" \
>             -e "s%@PKG_TARGET_LDFLAGS@%%g" \
>             -e "s%@PKG_TARGET_CXXFLAGS@%%g" \
> diff --git a/package/pkg-meson.mk b/package/pkg-meson.mk
> index 9974b1e513..93df43fe3e 100644
> --- a/package/pkg-meson.mk
> +++ b/package/pkg-meson.mk
> @@ -74,6 +74,7 @@ define $(2)_CONFIGURE_CMDS
>             -e "s%@TARGET_CFLAGS@%$$(HOST_MESON_SED_CFLAGS)%g" \
>             -e "s%@TARGET_LDFLAGS@%$$(HOST_MESON_SED_LDFLAGS)%g" \
>             -e "s%@TARGET_CXXFLAGS@%$$(HOST_MESON_SED_CXXFLAGS)%g" \
> +           -e "s%@PKG_TARGET_BINARIES@%$$($$(PKG)_MESON_BINARIES)%g" \
>             -e "s%@PKG_TARGET_CFLAGS@%$$($$(PKG)_MESON_SED_CFLAGS)%g" \
>             -e "s%@PKG_TARGET_LDFLAGS@%$$($$(PKG)_MESON_SED_LDFLAGS)%g" \
>             -e "s%@PKG_TARGET_CXXFLAGS@%$$($$(PKG)_MESON_SED_CXXFLAGS)%g" \
> 
> 
> and with: 
> 
> MPD_MESON_BINARIES = libgcrypt-config = '$(STAGING_DIR)/usr/bin/libgcrypt-config'

Looks good to me. I will test and send an updated patch if Thomas
agrees.

Jörg
Jörg Krause April 30, 2019, 8:11 a.m. UTC | #6
Hi Peter,

On Tue, 2019-04-23 at 23:29 +0200, Peter Seiderer wrote:
> Hello Jörg, Thomas,
> 
> On Sat, 13 Apr 2019 18:24:22 +0200, Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
> 
> > Hello Jörg,
> > 
> > +Peter Seiderer in Cc.
> > 
> > On Wed,  3 Apr 2019 20:32:01 +0200
> > Jörg Krause <joerg.krause@embedded.rocks> wrote:
> > 
> > > Since version 0.49.0 the Meson build system has native support for
> > > looking for `libgcrypt-config` if no pkg-config file is found. As the
> > > latest version 1.8.4 of libgcrypt does not provide a .pc file, using
> > > `libgcrypt-config` is the only way for detecting the required libraries
> > > when linking agains libgrypt.
> > > 
> > > The `libgcrypt-config` entry is necessary for updating package mpd,
> > > which switched from the Autotools to the Meson build system when bumping
> > > from version 0.20 to 0.21.
> > > 
> > > Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>  
> > 
> > As I said in my previous reply, I'm not too happy with this
> > libgcrypt-config variable creeping into the global cross-compilation
> > file. Can we instead look at extending what Peter Seiderer is doing in
> > http://patchwork.ozlabs.org/patch/1081486/ and allow some per-package
> > additions to the per-package cross-compilation file ? Peter's patch
> > does it for CFLAGS/CXXFLAGS/LDFLAGS, we could perhaps do the same with
> > arbitrary program paths ?
> 
> Something like the following (draft) should work:
> 
> diff --git a/package/meson/cross-compilation.conf.in b/package/meson/cross-compilation.conf.in
> index 4056c2b2f4..7cd372128e 100644
> --- a/package/meson/cross-compilation.conf.in
> +++ b/package/meson/cross-compilation.conf.in
> @@ -9,6 +9,7 @@ cpp = '@TARGET_CROSS@g++'
>  ar = '@TARGET_CROSS@ar'
>  strip = '@TARGET_CROSS@strip'
>  pkgconfig = '@HOST_DIR@/usr/bin/pkg-config'
> +@PKG_TARGET_BINARIES@
>  
>  [properties]
>  needs_exe_wrapper = true
> diff --git a/package/meson/meson.mk b/package/meson/meson.mk
> index 70128f6bad..e550c80c9d 100644
> --- a/package/meson/meson.mk
> +++ b/package/meson/meson.mk
> @@ -60,6 +60,7 @@ define HOST_MESON_INSTALL_CROSS_CONF
>             -e "s%@TARGET_CFLAGS@%$(HOST_MESON_SED_CFLAGS)%g" \
>             -e "s%@TARGET_LDFLAGS@%$(HOST_MESON_SED_LDFLAGS)%g" \
>             -e "s%@TARGET_CXXFLAGS@%$(HOST_MESON_SED_CXXFLAGS)%g" \
> +           -e "s%@PKG_TARGET_BINARIES@%%g" \
>             -e "s%@PKG_TARGET_CFLAGS@%%g" \
>             -e "s%@PKG_TARGET_LDFLAGS@%%g" \
>             -e "s%@PKG_TARGET_CXXFLAGS@%%g" \
> diff --git a/package/pkg-meson.mk b/package/pkg-meson.mk
> index 9974b1e513..93df43fe3e 100644
> --- a/package/pkg-meson.mk
> +++ b/package/pkg-meson.mk
> @@ -74,6 +74,7 @@ define $(2)_CONFIGURE_CMDS
>             -e "s%@TARGET_CFLAGS@%$$(HOST_MESON_SED_CFLAGS)%g" \
>             -e "s%@TARGET_LDFLAGS@%$$(HOST_MESON_SED_LDFLAGS)%g" \
>             -e "s%@TARGET_CXXFLAGS@%$$(HOST_MESON_SED_CXXFLAGS)%g" \
> +           -e "s%@PKG_TARGET_BINARIES@%$$($$(PKG)_MESON_BINARIES)%g" \
>             -e "s%@PKG_TARGET_CFLAGS@%$$($$(PKG)_MESON_SED_CFLAGS)%g" \
>             -e "s%@PKG_TARGET_LDFLAGS@%$$($$(PKG)_MESON_SED_LDFLAGS)%g" \
>             -e "s%@PKG_TARGET_CXXFLAGS@%$$($$(PKG)_MESON_SED_CXXFLAGS)%g" \
> 
> 
> and with: 
> 
> MPD_MESON_BINARIES = libgcrypt-config = '$(STAGING_DIR)/usr/bin/libgcrypt-config'

I've just tested your draft. This still inserts libgcrypt-config in the
global cross-compilation.conf.

I will send an updated version of the patch which does insert
libgcrypt-config in the package cross file, but not in the global cross
file.

Many thanks!

Jörg
Peter Seiderer April 30, 2019, 8:27 a.m. UTC | #7
Hello Jörg,

> Gesendet: Dienstag, 30. April 2019 um 10:11 Uhr
> Von: "Jörg Krause" <joerg.krause@embedded.rocks>
> An: "Peter Seiderer" <ps.report@gmx.net>, "Thomas Petazzoni" <thomas.petazzoni@bootlin.com>
> Cc: buildroot@buildroot.org
> Betreff: Re: [Buildroot] [PATCH 1/2] meson: add entry for libgcrypt-config in cross file
>
> Hi Peter,
> 
> On Tue, 2019-04-23 at 23:29 +0200, Peter Seiderer wrote:
> > Hello Jörg, Thomas,
> > 
> > On Sat, 13 Apr 2019 18:24:22 +0200, Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
> > 
> > > Hello Jörg,
> > > 
> > > +Peter Seiderer in Cc.
> > > 
> > > On Wed,  3 Apr 2019 20:32:01 +0200
> > > Jörg Krause <joerg.krause@embedded.rocks> wrote:
> > > 
> > > > Since version 0.49.0 the Meson build system has native support for
> > > > looking for `libgcrypt-config` if no pkg-config file is found. As the
> > > > latest version 1.8.4 of libgcrypt does not provide a .pc file, using
> > > > `libgcrypt-config` is the only way for detecting the required libraries
> > > > when linking agains libgrypt.
> > > > 
> > > > The `libgcrypt-config` entry is necessary for updating package mpd,
> > > > which switched from the Autotools to the Meson build system when bumping
> > > > from version 0.20 to 0.21.
> > > > 
> > > > Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>  
> > > 
> > > As I said in my previous reply, I'm not too happy with this
> > > libgcrypt-config variable creeping into the global cross-compilation
> > > file. Can we instead look at extending what Peter Seiderer is doing in
> > > http://patchwork.ozlabs.org/patch/1081486/ and allow some per-package
> > > additions to the per-package cross-compilation file ? Peter's patch
> > > does it for CFLAGS/CXXFLAGS/LDFLAGS, we could perhaps do the same with
> > > arbitrary program paths ?
> > 
> > Something like the following (draft) should work:
> > 
> > diff --git a/package/meson/cross-compilation.conf.in b/package/meson/cross-compilation.conf.in
> > index 4056c2b2f4..7cd372128e 100644
> > --- a/package/meson/cross-compilation.conf.in
> > +++ b/package/meson/cross-compilation.conf.in
> > @@ -9,6 +9,7 @@ cpp = '@TARGET_CROSS@g++'
> >  ar = '@TARGET_CROSS@ar'
> >  strip = '@TARGET_CROSS@strip'
> >  pkgconfig = '@HOST_DIR@/usr/bin/pkg-config'
> > +@PKG_TARGET_BINARIES@
> >  
> >  [properties]
> >  needs_exe_wrapper = true
> > diff --git a/package/meson/meson.mk b/package/meson/meson.mk
> > index 70128f6bad..e550c80c9d 100644
> > --- a/package/meson/meson.mk
> > +++ b/package/meson/meson.mk
> > @@ -60,6 +60,7 @@ define HOST_MESON_INSTALL_CROSS_CONF
> >             -e "s%@TARGET_CFLAGS@%$(HOST_MESON_SED_CFLAGS)%g" \
> >             -e "s%@TARGET_LDFLAGS@%$(HOST_MESON_SED_LDFLAGS)%g" \
> >             -e "s%@TARGET_CXXFLAGS@%$(HOST_MESON_SED_CXXFLAGS)%g" \
> > +           -e "s%@PKG_TARGET_BINARIES@%%g" \
> >             -e "s%@PKG_TARGET_CFLAGS@%%g" \
> >             -e "s%@PKG_TARGET_LDFLAGS@%%g" \
> >             -e "s%@PKG_TARGET_CXXFLAGS@%%g" \
> > diff --git a/package/pkg-meson.mk b/package/pkg-meson.mk
> > index 9974b1e513..93df43fe3e 100644
> > --- a/package/pkg-meson.mk
> > +++ b/package/pkg-meson.mk
> > @@ -74,6 +74,7 @@ define $(2)_CONFIGURE_CMDS
> >             -e "s%@TARGET_CFLAGS@%$$(HOST_MESON_SED_CFLAGS)%g" \
> >             -e "s%@TARGET_LDFLAGS@%$$(HOST_MESON_SED_LDFLAGS)%g" \
> >             -e "s%@TARGET_CXXFLAGS@%$$(HOST_MESON_SED_CXXFLAGS)%g" \
> > +           -e "s%@PKG_TARGET_BINARIES@%$$($$(PKG)_MESON_BINARIES)%g" \
> >             -e "s%@PKG_TARGET_CFLAGS@%$$($$(PKG)_MESON_SED_CFLAGS)%g" \
> >             -e "s%@PKG_TARGET_LDFLAGS@%$$($$(PKG)_MESON_SED_LDFLAGS)%g" \
> >             -e "s%@PKG_TARGET_CXXFLAGS@%$$($$(PKG)_MESON_SED_CXXFLAGS)%g" \
> > 
> > 
> > and with: 
> > 
> > MPD_MESON_BINARIES = libgcrypt-config = '$(STAGING_DIR)/usr/bin/libgcrypt-config'
> 
> I've just tested your draft. This still inserts libgcrypt-config in the
> global cross-compilation.conf.

Are you sure? The

+           -e "s%@PKG_TARGET_BINARIES@%%g"

in package/meson/meson.mk should not add anything to the global file...

Would have expected the trick/non-trivial thing to add more than one
binary entry (to get the newlines for the entries right)...

Regards,
Peter

> 
> I will send an updated version of the patch which does insert
> libgcrypt-config in the package cross file, but not in the global cross
> file.
> 
> Many thanks!
> 
> Jörg
> 
>
Jörg Krause April 30, 2019, 11:04 a.m. UTC | #8
Hello Peter,

On Tue, 2019-04-30 at 10:27 +0200, Peter Seiderer wrote:
> Hello Jörg,
> 
> > Gesendet: Dienstag, 30. April 2019 um 10:11 Uhr
> > Von: "Jörg Krause" <joerg.krause@embedded.rocks>
> > An: "Peter Seiderer" <ps.report@gmx.net>, "Thomas Petazzoni" <thomas.petazzoni@bootlin.com>
> > Cc: buildroot@buildroot.org
> > Betreff: Re: [Buildroot] [PATCH 1/2] meson: add entry for libgcrypt-config in cross file
> > 
> > Hi Peter,
> > 
> > On Tue, 2019-04-23 at 23:29 +0200, Peter Seiderer wrote:
> > > Hello Jörg, Thomas,
> > > 
> > > On Sat, 13 Apr 2019 18:24:22 +0200, Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
> > > 
> > > > Hello Jörg,
> > > > 
> > > > +Peter Seiderer in Cc.
> > > > 
> > > > On Wed,  3 Apr 2019 20:32:01 +0200
> > > > Jörg Krause <joerg.krause@embedded.rocks> wrote:
> > > > 
> > > > > Since version 0.49.0 the Meson build system has native support for
> > > > > looking for `libgcrypt-config` if no pkg-config file is found. As the
> > > > > latest version 1.8.4 of libgcrypt does not provide a .pc file, using
> > > > > `libgcrypt-config` is the only way for detecting the required libraries
> > > > > when linking agains libgrypt.
> > > > > 
> > > > > The `libgcrypt-config` entry is necessary for updating package mpd,
> > > > > which switched from the Autotools to the Meson build system when bumping
> > > > > from version 0.20 to 0.21.
> > > > > 
> > > > > Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>  
> > > > 
> > > > As I said in my previous reply, I'm not too happy with this
> > > > libgcrypt-config variable creeping into the global cross-compilation
> > > > file. Can we instead look at extending what Peter Seiderer is doing in
> > > > http://patchwork.ozlabs.org/patch/1081486/ and allow some per-package
> > > > additions to the per-package cross-compilation file ? Peter's patch
> > > > does it for CFLAGS/CXXFLAGS/LDFLAGS, we could perhaps do the same with
> > > > arbitrary program paths ?
> > > 
> > > Something like the following (draft) should work:
> > > 
> > > diff --git a/package/meson/cross-compilation.conf.in b/package/meson/cross-compilation.conf.in
> > > index 4056c2b2f4..7cd372128e 100644
> > > --- a/package/meson/cross-compilation.conf.in
> > > +++ b/package/meson/cross-compilation.conf.in
> > > @@ -9,6 +9,7 @@ cpp = '@TARGET_CROSS@g++'
> > >  ar = '@TARGET_CROSS@ar'
> > >  strip = '@TARGET_CROSS@strip'
> > >  pkgconfig = '@HOST_DIR@/usr/bin/pkg-config'
> > > +@PKG_TARGET_BINARIES@
> > >  
> > >  [properties]
> > >  needs_exe_wrapper = true
> > > diff --git a/package/meson/meson.mk b/package/meson/meson.mk
> > > index 70128f6bad..e550c80c9d 100644
> > > --- a/package/meson/meson.mk
> > > +++ b/package/meson/meson.mk
> > > @@ -60,6 +60,7 @@ define HOST_MESON_INSTALL_CROSS_CONF
> > >             -e "s%@TARGET_CFLAGS@%$(HOST_MESON_SED_CFLAGS)%g" \
> > >             -e "s%@TARGET_LDFLAGS@%$(HOST_MESON_SED_LDFLAGS)%g" \
> > >             -e "s%@TARGET_CXXFLAGS@%$(HOST_MESON_SED_CXXFLAGS)%g" \
> > > +           -e "s%@PKG_TARGET_BINARIES@%%g" \
> > >             -e "s%@PKG_TARGET_CFLAGS@%%g" \
> > >             -e "s%@PKG_TARGET_LDFLAGS@%%g" \
> > >             -e "s%@PKG_TARGET_CXXFLAGS@%%g" \
> > > diff --git a/package/pkg-meson.mk b/package/pkg-meson.mk
> > > index 9974b1e513..93df43fe3e 100644
> > > --- a/package/pkg-meson.mk
> > > +++ b/package/pkg-meson.mk
> > > @@ -74,6 +74,7 @@ define $(2)_CONFIGURE_CMDS
> > >             -e "s%@TARGET_CFLAGS@%$$(HOST_MESON_SED_CFLAGS)%g" \
> > >             -e "s%@TARGET_LDFLAGS@%$$(HOST_MESON_SED_LDFLAGS)%g" \
> > >             -e "s%@TARGET_CXXFLAGS@%$$(HOST_MESON_SED_CXXFLAGS)%g" \
> > > +           -e "s%@PKG_TARGET_BINARIES@%$$($$(PKG)_MESON_BINARIES)%g" \
> > >             -e "s%@PKG_TARGET_CFLAGS@%$$($$(PKG)_MESON_SED_CFLAGS)%g" \
> > >             -e "s%@PKG_TARGET_LDFLAGS@%$$($$(PKG)_MESON_SED_LDFLAGS)%g" \
> > >             -e "s%@PKG_TARGET_CXXFLAGS@%$$($$(PKG)_MESON_SED_CXXFLAGS)%g" \
> > > 
> > > 
> > > and with: 
> > > 
> > > MPD_MESON_BINARIES = libgcrypt-config = '$(STAGING_DIR)/usr/bin/libgcrypt-config'
> > 
> > I've just tested your draft. This still inserts libgcrypt-config in the
> > global cross-compilation.conf.
> 
> Are you sure? The
> 
> +           -e "s%@PKG_TARGET_BINARIES@%%g"
> 
> in package/meson/meson.mk should not add anything to the global file...

You're right! I missed that line, sorry.

> 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?

Best regards
Jörg Krause
Arnout Vandecappelle May 1, 2019, 11:13 a.m. UTC | #9
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


 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).

- meson infra builds in PKG_SRCDIR/build. That really should be PKG_BUILDDIR,
with a default of $(2)_BUILDDIR ?= $$($(2)_SRCDIR)/build.

- 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).


 Regards,
 Arnout
Peter Seiderer May 1, 2019, 7:04 p.m. UTC | #10
Hello Arnout,

On Wed, 1 May 2019 13:13:03 +0200, Arnout Vandecappelle <arnout@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), does the printf approach fix the newline problem for more than one
entry?

> 
> 
>  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...

> 
> - 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?

Regards,
Peter
  
> 
> 
>  Regards,
>  Arnout
Peter Seiderer May 1, 2019, 7:23 p.m. UTC | #11
Hello Arnout, Jörg,

On Wed, 1 May 2019 13:13:03 +0200, Arnout Vandecappelle <arnout@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.
> > 


> > 
> > .. 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?  

The version with added '\n', like:

PKG_TARGET_BINARIES = \
 	libgcrypt-config = '...' \
 	\nllvm-config = '...'

works for the sed variant but not for the given printf one...

Regards,
Peter

> 
>  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  
> 
> 
>  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).
> 
> - meson infra builds in PKG_SRCDIR/build. That really should be PKG_BUILDDIR,
> with a default of $(2)_BUILDDIR ?= $$($(2)_SRCDIR)/build.
> 
> - 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).
> 
> 
>  Regards,
>  Arnout
Thomas Petazzoni May 1, 2019, 7:36 p.m. UTC | #12
Hello,

On Wed, 1 May 2019 13:13:03 +0200
Arnout Vandecappelle <arnout@mind.be> wrote:

> - 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).

I'd say it depends the $(@D) of which step. Indeed, in the (admittedly
long term) perspective of per-package out-of-tree build, the source
tree would be shared between the host and target builds of a given
package, and this cross-compilation.conf file would only make sense for
the target variant of the package, and therefore it should be in the
build directory of the target variant.

So, if this file is generated during the "configure" step, we are good,
because $(@D) will point to the build directory. If it's generated in
an earlier step, $(@D) points to the source directory (with per-package
out-of-tree build implemented, of course).

Best regards,

Thomas
Arnout Vandecappelle May 2, 2019, 12:17 p.m. UTC | #13
On 01/05/2019 21:04, Peter Seiderer wrote:
> Hello Arnout,
> 
> On Wed, 1 May 2019 13:13:03 +0200, Arnout Vandecappelle <arnout@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

> , 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
Arnout Vandecappelle May 2, 2019, 12:20 p.m. UTC | #14
On 01/05/2019 21:36, Thomas Petazzoni wrote:
> Hello,
> 
> On Wed, 1 May 2019 13:13:03 +0200
> Arnout Vandecappelle <arnout@mind.be> wrote:
> 
>> - 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).
> 
> I'd say it depends the $(@D) of which step. Indeed, in the (admittedly
> long term) perspective of per-package out-of-tree build, the source
> tree would be shared between the host and target builds of a given
> package, and this cross-compilation.conf file would only make sense for
> the target variant of the package, and therefore it should be in the
> build directory of the target variant.
> 
> So, if this file is generated during the "configure" step, we are good,
> because $(@D) will point to the build directory. If it's generated in
> an earlier step, $(@D) points to the source directory (with per-package
> out-of-tree build implemented, of course).

 Similarly like for $(2) vs. $(PKG), I think we should have a "default" for how
to address "the directory where stuff happens". We currently use $(@D) in many
places, but perhaps it's better to turn that into $(FOO_BUILDDIR).

 Regards,
 Arnout
Peter Seiderer May 2, 2019, 8:02 p.m. UTC | #15
Hello Arnout,

On Thu, 2 May 2019 14:17:45 +0200, Arnout Vandecappelle <arnout@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@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@busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
Arnout Vandecappelle May 3, 2019, 9:21 a.m. UTC | #16
On 02/05/2019 22:02, Peter Seiderer wrote:
> Hello Arnout,
> 
> On Thu, 2 May 2019 14:17:45 +0200, Arnout Vandecappelle <arnout@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@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]

 Oh yes, that's because of the newlines in the definition of PRINTF. `make`
replaces backslash-newline-space-space-space with a single space. Since there
are three backslash-newlines in that macro, you get three spaces.

 However, the definition of PERCENT and QUOTE is actually not needed, since
neither of those are special from `make`. So you could instead define the macro as:

        printf '$(subst $(sep),\n,$(subst %,%%,$(subst ','\'',$(subst
\,\\,$(1)))))\n'

 Syntax highlighting in vim is completely screwed up then, but it's the end of
the file so too bad :-)

 If you think that that is still too long, you could define it in two steps:

shell-quote = '$(subst ','\'',$(subst \,\\,$(1)))'
define PRINTF
	printf $(subst $(sep),\n,$(subst %,%%,$(call shell-quote,$(1)$(sep))))
endef

But I'm not convinced that that is nicer.

 Oh, and all of that is untested of course.

 Regards,
 Arnout


> 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@busybox.net
>> http://lists.busybox.net/mailman/listinfo/buildroot
>
Jörg Krause May 23, 2019, 10:51 p.m. UTC | #17
Hi all,

thank you all for your ideas. Please take a look at my proposal
below...

On Thu, 2019-05-02 at 14:17 +0200, Arnout Vandecappelle wrote:
> 
> On 01/05/2019 21:04, Peter Seiderer wrote:
> > Hello Arnout,
> > 
> > On Wed, 1 May 2019 13:13:03 +0200, Arnout Vandecappelle <arnout@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
> 
> > , 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 :-)

The package using the meson infrastructure defines:

   define libfoo_MESON_CROSS_CONF_BINARIES
   libgcrypt-config = '$(STAGING_DIR)/usr/bin/libgcrypt-config'
   llvm-config = '$(STAGING_DIR)/usr/bin/llvm-config'
   endef

pkg-meson.mk is using PRINTF to a temporary file and sed is using this
file as input for appending to the [binaries section]:

   $Q$$(if $$($$(PKG)_MESON_CROSS_CONF_BINARIES), \
   	$$(call PRINTF,$$($$(PKG)_MESON_CROSS_CONF_BINARIES))) \
   	> $$($$(PKG)_SRCDIR)/build/cross-binaries.tmp
   sed -i "s/^[ \t]*//" $$($$(PKG)_SRCDIR)/build/cross-binaries.tmp
   sed -e "s%@TARGET_CROSS@%$$(TARGET_CROSS)%g" \
       ...
       -e  "/\[binaries\]/r $$($$(PKG)_SRCDIR)/build/cross-binaries.tmp" \
       package/meson/cross-compilation.conf.in \
       > $$($$(PKG)_SRCDIR)/build/cross-compilation.conf
   rm -f $$($$(PKG)_SRCDIR)/build/cross-binaries.tmp

Best regards
Jörg Krause
Arnout Vandecappelle May 24, 2019, 8:18 a.m. UTC | #18
On 24/05/2019 00:51, Jörg Krause wrote:
> Hi all,
> 
> thank you all for your ideas. Please take a look at my proposal
> below...
> 
> On Thu, 2019-05-02 at 14:17 +0200, Arnout Vandecappelle wrote:
>>
>> On 01/05/2019 21:04, Peter Seiderer wrote:
>>> Hello Arnout,
>>>
>>> On Wed, 1 May 2019 13:13:03 +0200, Arnout Vandecappelle <arnout@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

 Is there any reason why this proposal doesn't work? AFAIU, it should be no
problem to repeat the '[binaries]' part several times, right?

 I'm insisting on this since I expect that we'll need to override something else
at some point as well.

>>> , 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 :-)
> 
> The package using the meson infrastructure defines:
> 
>    define libfoo_MESON_CROSS_CONF_BINARIES
>    libgcrypt-config = '$(STAGING_DIR)/usr/bin/libgcrypt-config'
>    llvm-config = '$(STAGING_DIR)/usr/bin/llvm-config'
>    endef
> 
> pkg-meson.mk is using PRINTF to a temporary file and sed is using this
> file as input for appending to the [binaries section]:
> 
>    $Q$$(if $$($$(PKG)_MESON_CROSS_CONF_BINARIES), \
>    	$$(call PRINTF,$$($$(PKG)_MESON_CROSS_CONF_BINARIES))) \
>    	> $$($$(PKG)_SRCDIR)/build/cross-binaries.tmp
>    sed -i "s/^[ \t]*//" $$($$(PKG)_SRCDIR)/build/cross-binaries.tmp

 I would rather have the PRINTF macro to be fixed not to insert these tabs. It's
just an artefact of how make works, and can be fairly easily fixed, either by
reordering the newlines in the PRINTF definition, or by putting a $(strip)
around it (although the latter has potential side effect since it also replaces
all internal whitespace with a single space).


>    sed -e "s%@TARGET_CROSS@%$$(TARGET_CROSS)%g" \
>        ...
>        -e  "/\[binaries\]/r $$($$(PKG)_SRCDIR)/build/cross-binaries.tmp" \

 Not many people understand the r command which makes this hard to read, but
it's acceptable for me.

>        package/meson/cross-compilation.conf.in \
>        > $$($$(PKG)_SRCDIR)/build/cross-compilation.conf
>    rm -f $$($$(PKG)_SRCDIR)/build/cross-binaries.tmp


 Maybe, however, we should drop the cross-compilation.conf.in and generate
everything with PRINTF (assuming that PRINTF gets fixed first, of course):

define meson_cross_compilation_conf_template
# Note: Buildroot's and Meson's terminologies differ about the meaning
# of 'build', 'host' and 'target':
# - Buildroot's 'host' is Meson's 'build'
# - Buildroot's 'target' is Meson's 'host'

[binaries]
c = '$(TARGET_CROSS)gcc'
cpp = '$(TARGET_CROSS)g++'
ar = '$(TARGET_CROSS)ar'
strip = '$(TARGET_CROSS)strip'
pkgconfig = '$(HOST_DIR)/usr/bin/pkg-config'
$($(PKG)_MESON_CROSS_CONF_BINARIES)

[properties]
needs_exe_wrapper = true
...
endef


	$(call PRINTF,$(meson_cross_compilation_conf_template)) \
		> $$($$(PKG)_SRCDIR)/build/cross-compilation.conf


(Note: even with the above, I would prefer to have a $($(PKG)_MESON_CROSS_CONF)
that gets appended at the end and that has the [binaries] embedded in it; the
above is assuming that that doesn't work for some reason.)


 Regards,
 Arnout
Jörg Krause May 26, 2019, 9:17 a.m. UTC | #19
Hi,

On Fri, 2019-05-24 at 10:18 +0200, Arnout Vandecappelle wrote:
> 
> On 24/05/2019 00:51, Jörg Krause wrote:
> > Hi all,
> > 
> > thank you all for your ideas. Please take a look at my proposal
> > below...
> > 
> > On Thu, 2019-05-02 at 14:17 +0200, Arnout Vandecappelle wrote:
> > > On 01/05/2019 21:04, Peter Seiderer wrote:
> > > > Hello Arnout,
> > > > 
> > > > On Wed, 1 May 2019 13:13:03 +0200, Arnout Vandecappelle <arnout@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
> 
>  Is there any reason why this proposal doesn't work? AFAIU, it should be no
> problem to repeat the '[binaries]' part several times, right?

Meson does not accept the same section name more than once. It fails
with:

configparser.DuplicateSectionError: While reading from '/buildroot/output/build/mpd-0.21.9//build/cross-compilation.conf' [line 26]
: section 'binaries' already exists
FAILED: build.ninja

>  I'm insisting on this since I expect that we'll need to override something else
> at some point as well.
> 
> > > > , 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 :-)
> > 
> > The package using the meson infrastructure defines:
> > 
> >    define libfoo_MESON_CROSS_CONF_BINARIES
> >    libgcrypt-config = '$(STAGING_DIR)/usr/bin/libgcrypt-config'
> >    llvm-config = '$(STAGING_DIR)/usr/bin/llvm-config'
> >    endef
> > 
> > pkg-meson.mk is using PRINTF to a temporary file and sed is using this
> > file as input for appending to the [binaries section]:
> > 
> >    $Q$$(if $$($$(PKG)_MESON_CROSS_CONF_BINARIES), \
> >    	$$(call PRINTF,$$($$(PKG)_MESON_CROSS_CONF_BINARIES))) \
> >    	> $$($$(PKG)_SRCDIR)/build/cross-binaries.tmp
> >    sed -i "s/^[ \t]*//" $$($$(PKG)_SRCDIR)/build/cross-binaries.tmp
> 
>  I would rather have the PRINTF macro to be fixed not to insert these tabs. It's
> just an artefact of how make works, and can be fairly easily fixed, either by
> reordering the newlines in the PRINTF definition, or by putting a $(strip)
> around it (although the latter has potential side effect since it also replaces
> all internal whitespace with a single space).

I see! So, this should be fixed first.

> >    sed -e "s%@TARGET_CROSS@%$$(TARGET_CROSS)%g" \
> >        ...
> >        -e  "/\[binaries\]/r $$($$(PKG)_SRCDIR)/build/cross-binaries.tmp" \
> 
>  Not many people understand the r command which makes this hard to read, but
> it's acceptable for me.
> 
> >        package/meson/cross-compilation.conf.in \
> >        > $$($$(PKG)_SRCDIR)/build/cross-compilation.conf
> >    rm -f $$($$(PKG)_SRCDIR)/build/cross-binaries.tmp
> 
>  Maybe, however, we should drop the cross-compilation.conf.in and generate
> everything with PRINTF (assuming that PRINTF gets fixed first, of course):
> 
> define meson_cross_compilation_conf_template
> # Note: Buildroot's and Meson's terminologies differ about the meaning
> # of 'build', 'host' and 'target':
> # - Buildroot's 'host' is Meson's 'build'
> # - Buildroot's 'target' is Meson's 'host'
> 
> [binaries]
> c = '$(TARGET_CROSS)gcc'
> cpp = '$(TARGET_CROSS)g++'
> ar = '$(TARGET_CROSS)ar'
> strip = '$(TARGET_CROSS)strip'
> pkgconfig = '$(HOST_DIR)/usr/bin/pkg-config'
> $($(PKG)_MESON_CROSS_CONF_BINARIES)
> 
> [properties]
> needs_exe_wrapper = true
> ...
> endef
> 
> 
> 	$(call PRINTF,$(meson_cross_compilation_conf_template)) \
> 		> $$($$(PKG)_SRCDIR)/build/cross-compilation.conf
> 
> 
> (Note: even with the above, I would prefer to have a $($(PKG)_MESON_CROSS_CONF)
> that gets appended at the end and that has the [binaries] embedded in it; the
> above is assuming that that doesn't work for some reason.)

As Meson does not accept duplicated sections, $($(PKG)_MESON_CROSS_CONF
isn't an option. So, what does others think about:

a) using seds 'r' command?
b) drop the cross-compilation.conf.in and generate everything with
PRINTF?
c) Something else

Best regards
Jörg Krause

Patch
diff mbox series

diff --git a/package/meson/cross-compilation.conf.in b/package/meson/cross-compilation.conf.in
index fc8e27f7eb..b68499a6fa 100644
--- a/package/meson/cross-compilation.conf.in
+++ b/package/meson/cross-compilation.conf.in
@@ -9,6 +9,7 @@  cpp = '@TARGET_CROSS@g++'
 ar = '@TARGET_CROSS@ar'
 strip = '@TARGET_CROSS@strip'
 pkgconfig = '@HOST_DIR@/usr/bin/pkg-config'
+libgcrypt-config = '@STAGING_DIR@/usr/bin/libgcrypt-config'
 
 [properties]
 needs_exe_wrapper = true
diff --git a/package/meson/meson.mk b/package/meson/meson.mk
index 49e27f5527..113ff058f7 100644
--- a/package/meson/meson.mk
+++ b/package/meson/meson.mk
@@ -61,6 +61,7 @@  define HOST_MESON_INSTALL_CROSS_CONF
 	    -e "s%@TARGET_LDFLAGS@%$(HOST_MESON_SED_LDFLAGS)%g" \
 	    -e "s%@TARGET_CXXFLAGS@%$(HOST_MESON_SED_CXXFLAGS)%g" \
 	    -e "s%@HOST_DIR@%$(HOST_DIR)%g" \
+	    -e "s%@STAGING_DIR@%$(STAGING_DIR)%g" \
 	    $(HOST_MESON_PKGDIR)/cross-compilation.conf.in \
 	    > $(HOST_DIR)/etc/meson/cross-compilation.conf
 endef
diff --git a/package/pkg-meson.mk b/package/pkg-meson.mk
index 886fcf7205..6ec45b8b82 100644
--- a/package/pkg-meson.mk
+++ b/package/pkg-meson.mk
@@ -71,6 +71,7 @@  define $(2)_CONFIGURE_CMDS
 	    -e "s%@TARGET_LDFLAGS@%$$(HOST_MESON_SED_LDFLAGS)%g" \
 	    -e "s%@TARGET_CXXFLAGS@%$$(HOST_MESON_SED_CXXFLAGS)%g" \
 	    -e "s%@HOST_DIR@%$$(HOST_DIR)%g" \
+	    -e "s%@STAGING_DIR@%$$(STAGING_DIR)%g" \
 	    package/meson/cross-compilation.conf.in \
 	    > $$($$(PKG)_SRCDIR)/build/cross-compilation.conf
 	PATH=$$(BR_PATH) $$($$(PKG)_CONF_ENV) $$(MESON) \