| 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 | expand |
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
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
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
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
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
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
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 > >
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
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
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
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
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
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
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
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
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 >
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
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
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
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) \
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(+)