| Message ID | 20191103060113.4884-1-heiko.thiery@gmail.com |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | [1/1] package/sysrepo: fix host/staging install steps | expand |
On Sun, 3 Nov 2019 07:01:14 +0100 Heiko Thiery <heiko.thiery@gmail.com> wrote: > From: Heiko Thiery <heiko.thiery@kontron.com> > > The sysrepoctl and sysrepocfg executables are used in install steps > of the package. Since there are hard-coded install pathes, > this leeds to wrong installation directories in host and staging > install steps. > > Only sysrepoctl and sysrepocfg executables are needed from host build. > So build and install only the executables in this step. So far, ok. > The staging step only needs to install the library with the > corresponding files like the headers and the pkg-config. I don't understand this however. Is there a problem with keeping a simple "make install" for the staging installation ? After all, for TARGET_DIR, you've kept the default "make install" behavior, so it should be fine for staging as well. Could you comment on this ? Also does this commit fix any autobuilder failure ? If it does, then please add a reference to it, like this: Fixes: http://autobuild.buildroot.net/results/bcd9bdd3bc83c1f2ab0b24348d51de27d88649b4/ Thanks, Thomas
Hi Thomas, Am Mo., 4. Nov. 2019 um 22:38 Uhr schrieb Thomas Petazzoni <thomas.petazzoni@bootlin.com>: > > On Sun, 3 Nov 2019 07:01:14 +0100 > Heiko Thiery <heiko.thiery@gmail.com> wrote: > > > From: Heiko Thiery <heiko.thiery@kontron.com> > > > > The sysrepoctl and sysrepocfg executables are used in install steps > > of the package. Since there are hard-coded install pathes, > > this leeds to wrong installation directories in host and staging > > install steps. > > > > Only sysrepoctl and sysrepocfg executables are needed from host build. > > So build and install only the executables in this step. > > So far, ok. > > > The staging step only needs to install the library with the > > corresponding files like the headers and the pkg-config. > > I don't understand this however. Is there a problem with keeping a > simple "make install" for the staging installation ? After all, for > TARGET_DIR, you've kept the default "make install" behavior, so it > should be fine for staging as well. Could you comment on this ? The problem comes from the hardcoded TARGET_DIR that is compiled-in the needed host tools (sysrepocfg, sysrepoctl) in the build host step. This value is used as target for this tools as well as search path for other dependencies. With this all install steps tries to install parts into that TARGET_DIR. I think it is not really clean that this happens. When I just do the part hat only the tools are build in the host step. Then the staging will fail because there are missing files that are expected to be located in the TARGET_DIR. The tools have the hardcoded search path set to the TARGET_DIR. I know this is tricky and it took some time for me to understand this. > Also does this commit fix any autobuilder failure ? If it does, then > please add a reference to it, like this: No. -- Heiko
On Tue, 5 Nov 2019 09:03:27 +0100 Heiko Thiery <heiko.thiery@gmail.com> wrote: > The problem comes from the hardcoded TARGET_DIR that is compiled-in the > needed host tools (sysrepocfg, sysrepoctl) in the build host step. > This value is used > as target for this tools as well as search path for other dependencies. > With this all install steps tries to install parts into that > TARGET_DIR. I think it is not > really clean that this happens. When I just do the part hat only the > tools are build in > the host step. Then the staging will fail because there are missing > files that are > expected to be located in the TARGET_DIR. The tools have the hardcoded search > path set to the TARGET_DIR. Hum, OK. Did you talk about this with the upstream project ? Your proposed solution is probably good as a workaround, but long term it would be nice to have the upstream sysrepo project support better cross-compilation, by solving those paths issues. Thanks, Thomas
> -----Ursprüngliche Nachricht----- > Von: Thomas Petazzoni [mailto:thomas.petazzoni@bootlin.com] > Gesendet: Dienstag, 5. November 2019 09:10 > An: Heiko Thiery > Cc: Heiko Thiery; buildroot@buildroot.org > Betreff: Re: [Buildroot] [PATCH 1/1] package/sysrepo: fix host/staging install > steps > > On Tue, 5 Nov 2019 09:03:27 +0100 > Heiko Thiery <heiko.thiery@gmail.com> wrote: > > > The problem comes from the hardcoded TARGET_DIR that is compiled-in > > the needed host tools (sysrepocfg, sysrepoctl) in the build host step. > > This value is used > > as target for this tools as well as search path for other dependencies. > > With this all install steps tries to install parts into that > > TARGET_DIR. I think it is not really clean that this happens. When I > > just do the part hat only the tools are build in the host step. Then > > the staging will fail because there are missing files that are > > expected to be located in the TARGET_DIR. The tools have the hardcoded > > search path set to the TARGET_DIR. > > Hum, OK. Did you talk about this with the upstream project ? > > Your proposed solution is probably good as a workaround, but long term it > would be nice to have the upstream sysrepo project support better cross- > compilation, by solving those paths issues. I agree. I tried this and it is still ongoing.
Hello Heiko, On Sun, 3 Nov 2019 07:01:14 +0100 Heiko Thiery <heiko.thiery@gmail.com> wrote: > From: Heiko Thiery <heiko.thiery@kontron.com> > > The sysrepoctl and sysrepocfg executables are used in install steps > of the package. Since there are hard-coded install pathes, > this leeds to wrong installation directories in host and staging > install steps. > > Only sysrepoctl and sysrepocfg executables are needed from host build. > So build and install only the executables in this step. > > The staging step only needs to install the library with the > corresponding files like the headers and the pkg-config. > > Signed-off-by: Heiko Thiery <heiko.thiery@kontron.com> > --- > package/sysrepo/sysrepo.mk | 36 ++++++++++++++++++++++++++---------- > 1 file changed, 26 insertions(+), 10 deletions(-) Do you have a minimal/simple defconfig that allows to reproduce the problem? When I build this simple configuration: BR2_arm=y BR2_TOOLCHAIN_EXTERNAL=y BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/toolchains/tarballs/br-arm-full-2019.05.1.tar.bz2" BR2_TOOLCHAIN_EXTERNAL_GCC_4_9=y BR2_TOOLCHAIN_EXTERNAL_HEADERS_4_14=y BR2_TOOLCHAIN_EXTERNAL_LOCALE=y # BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS_DEBUG is not set BR2_TOOLCHAIN_EXTERNAL_CXX=y BR2_INIT_NONE=y BR2_SYSTEM_BIN_SH_NONE=y # BR2_PACKAGE_BUSYBOX is not set BR2_PACKAGE_SYSREPO=y # BR2_TARGET_ROOTFS_TAR is not set It builds just fine, with no problem. What is the thing that triggers the issue ? Thanks, Thomas
Am Fr., 8. Nov. 2019 um 22:58 Uhr schrieb Thomas Petazzoni <thomas.petazzoni@bootlin.com>: > > Hello Heiko, > > On Sun, 3 Nov 2019 07:01:14 +0100 > Heiko Thiery <heiko.thiery@gmail.com> wrote: > > > From: Heiko Thiery <heiko.thiery@kontron.com> > > > > The sysrepoctl and sysrepocfg executables are used in install steps > > of the package. Since there are hard-coded install pathes, > > this leeds to wrong installation directories in host and staging > > install steps. > > > > Only sysrepoctl and sysrepocfg executables are needed from host build. > > So build and install only the executables in this step. > > > > The staging step only needs to install the library with the > > corresponding files like the headers and the pkg-config. > > > > Signed-off-by: Heiko Thiery <heiko.thiery@kontron.com> > > --- > > package/sysrepo/sysrepo.mk | 36 ++++++++++++++++++++++++++---------- > > 1 file changed, 26 insertions(+), 10 deletions(-) > > Do you have a minimal/simple defconfig that allows to reproduce the problem? > > When I build this simple configuration: > > BR2_arm=y > BR2_TOOLCHAIN_EXTERNAL=y > BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y > BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y > BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/toolchains/tarballs/br-arm-full-2019.05.1.tar.bz2" > BR2_TOOLCHAIN_EXTERNAL_GCC_4_9=y > BR2_TOOLCHAIN_EXTERNAL_HEADERS_4_14=y > BR2_TOOLCHAIN_EXTERNAL_LOCALE=y > # BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS_DEBUG is not set > BR2_TOOLCHAIN_EXTERNAL_CXX=y > BR2_INIT_NONE=y > BR2_SYSTEM_BIN_SH_NONE=y > # BR2_PACKAGE_BUSYBOX is not set > BR2_PACKAGE_SYSREPO=y > # BR2_TARGET_ROOTFS_TAR is not set > > It builds just fine, with no problem. What is the thing that triggers > the issue ? Your defconfig shows the problem not while building rather in the install step. the main problem is that the sysrepo cmake build system has a config option REPOSITORY_LOC. This folder is used to set the target of the sysrepo database. Since we want to create this database during the build in the target we have to set this variable to the target directory (currently still a bug in the last applied package). But when setting this directory to the target the host install step also installs stuff (yang models) in this directory. That means host install touches the target directory. I think this is not correct. Is there a way to check that the steps only installs/touchs files in the directories they are responsible? With this the problem above could be shown easier. -- Heiko
Hello Heiko, On Sun, 10 Nov 2019 17:00:14 +0100 Heiko Thiery <heiko.thiery@gmail.com> wrote: > > Do you have a minimal/simple defconfig that allows to reproduce the problem? > > > > When I build this simple configuration: > > > > BR2_arm=y > > BR2_TOOLCHAIN_EXTERNAL=y > > BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y > > BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y > > BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/toolchains/tarballs/br-arm-full-2019.05.1.tar.bz2" > > BR2_TOOLCHAIN_EXTERNAL_GCC_4_9=y > > BR2_TOOLCHAIN_EXTERNAL_HEADERS_4_14=y > > BR2_TOOLCHAIN_EXTERNAL_LOCALE=y > > # BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS_DEBUG is not set > > BR2_TOOLCHAIN_EXTERNAL_CXX=y > > BR2_INIT_NONE=y > > BR2_SYSTEM_BIN_SH_NONE=y > > # BR2_PACKAGE_BUSYBOX is not set > > BR2_PACKAGE_SYSREPO=y > > # BR2_TARGET_ROOTFS_TAR is not set > > > > It builds just fine, with no problem. What is the thing that triggers > > the issue ? > > Your defconfig shows the problem not while building rather in the install step. Hu? When I said "build", it of course means a Buildroot build, so it does both the build and installation of all packages. The autobuilder failures happens at Buildroot build time, and I was not able to reproduce it, and therefore not able to check that your patch solves it. > the main problem is that the sysrepo cmake build system has a config > option REPOSITORY_LOC. This folder is used to set the target of the > sysrepo database. Since we want to create this database during the > build in the target we have to set this variable to the target > directory (currently still a bug in the last applied package). But > when setting this directory to the target the host install step also > installs stuff (yang models) in this directory. That means host > install touches the target directory. I think this is not correct. True. > Is there a way to check that the steps only installs/touchs files in > the directories they are responsible? With this the problem above > could be shown easier. Not easily no, and there are some packages that violate this rule. While not nice, some packages are quite complicated and cannot be fixed. An example is the qt5base package, which mainly builds/installs Qt5 libraries for the target, but as a side effect also installs some host tools in $(HOST_DIR). Thomas
Hi, Am Mo., 11. Nov. 2019 um 14:53 Uhr schrieb Thomas Petazzoni <thomas.petazzoni@bootlin.com>: > > Hello Heiko, > > On Sun, 10 Nov 2019 17:00:14 +0100 > Heiko Thiery <heiko.thiery@gmail.com> wrote: > > > > Do you have a minimal/simple defconfig that allows to reproduce the problem? > > > > > > When I build this simple configuration: > > > > > > BR2_arm=y > > > BR2_TOOLCHAIN_EXTERNAL=y > > > BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y > > > BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y > > > BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/toolchains/tarballs/br-arm-full-2019.05.1.tar.bz2" > > > BR2_TOOLCHAIN_EXTERNAL_GCC_4_9=y > > > BR2_TOOLCHAIN_EXTERNAL_HEADERS_4_14=y > > > BR2_TOOLCHAIN_EXTERNAL_LOCALE=y > > > # BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS_DEBUG is not set > > > BR2_TOOLCHAIN_EXTERNAL_CXX=y > > > BR2_INIT_NONE=y > > > BR2_SYSTEM_BIN_SH_NONE=y > > > # BR2_PACKAGE_BUSYBOX is not set > > > BR2_PACKAGE_SYSREPO=y > > > # BR2_TARGET_ROOTFS_TAR is not set > > > > > > It builds just fine, with no problem. What is the thing that triggers > > > the issue ? > > > > Your defconfig shows the problem not while building rather in the install step. > > Hu? When I said "build", it of course means a Buildroot build, so it > does both the build and installation of all packages. > > The autobuilder failures happens at Buildroot build time, and I was not > able to reproduce it, and therefore not able to check that your patch > solves it. Hmm, now I'm a little bit confused. Do you mean with autobuilder failure the results of the buildroot CI? I think this issues was already solves with the patch provided by Fabrice Fontaine: http://lists.busybox.net/pipermail/buildroot/2019-October/265043.html http://lists.busybox.net/pipermail/buildroot/2019-October/265044.html And currently there should'nt be any autobuilder failures!? And this patch fixes some "new" issues with wrongly installed files in wrong locations. > > the main problem is that the sysrepo cmake build system has a config > > option REPOSITORY_LOC. This folder is used to set the target of the > > sysrepo database. Since we want to create this database during the > > build in the target we have to set this variable to the target > > directory (currently still a bug in the last applied package). But > > when setting this directory to the target the host install step also > > installs stuff (yang models) in this directory. That means host > > install touches the target directory. I think this is not correct. > > True. > > > Is there a way to check that the steps only installs/touchs files in > > the directories they are responsible? With this the problem above > > could be shown easier. > > Not easily no, and there are some packages that violate this rule. > While not nice, some packages are quite complicated and cannot be > fixed. An example is the qt5base package, which mainly builds/installs > Qt5 libraries for the target, but as a side effect also installs some > host tools in $(HOST_DIR). > > Thomas > -- > Thomas Petazzoni, CTO, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com -- Heiko
Hello, On Mon, 11 Nov 2019 15:07:31 +0100 Heiko Thiery <heiko.thiery@gmail.com> wrote: > > > Your defconfig shows the problem not while building rather in the install step. > > > > Hu? When I said "build", it of course means a Buildroot build, so it > > does both the build and installation of all packages. > > > > The autobuilder failures happens at Buildroot build time, and I was not > > able to reproduce it, and therefore not able to check that your patch > > solves it. > > Hmm, now I'm a little bit confused. Do you mean with autobuilder > failure the results of the buildroot CI? > I think this issues was already solves with the patch provided by > Fabrice Fontaine: > > http://lists.busybox.net/pipermail/buildroot/2019-October/265043.html > http://lists.busybox.net/pipermail/buildroot/2019-October/265044.html > > And currently there should'nt be any autobuilder failures!? Is your patch https://patchwork.ozlabs.org/patch/1188504/ fixing any autobuilder failure ? I was assuming it was there to fix the build issue at http://autobuild.buildroot.net/results/bcd/bcd9bdd3bc83c1f2ab0b24348d51de27d88649b4/build-end.log. http://lists.busybox.net/pipermail/buildroot/2019-October/265043.html fixes http://autobuild.buildroot.net/results/d80/d807f3dc922a61e099a66de3bc340c018a86e150/build-end.log, which is a different failure. http://lists.busybox.net/pipermail/buildroot/2019-October/265044.html fixes http://autobuild.buildroot.net/results/f0e/f0e4368977f257d76aedff335af3068deafaf28f/build-end.log which another different issue. > And this patch fixes some "new" issues with wrongly installed files in > wrong locations. Yes, which is exactly what is reported at http://autobuild.buildroot.net/results/bcd/bcd9bdd3bc83c1f2ab0b24348d51de27d88649b4/build-end.log, but I was not able to reproduce this failure with a simple configuration. Hence my question: do you have a simple configuration that reproduces the "wrongly installed files in wrong locations" issue ? Thomas
Am Mo., 11. Nov. 2019 um 15:27 Uhr schrieb Thomas Petazzoni <thomas.petazzoni@bootlin.com>: > > Hello, > > On Mon, 11 Nov 2019 15:07:31 +0100 > Heiko Thiery <heiko.thiery@gmail.com> wrote: > > > > > Your defconfig shows the problem not while building rather in the install step. > > > > > > Hu? When I said "build", it of course means a Buildroot build, so it > > > does both the build and installation of all packages. > > > > > > The autobuilder failures happens at Buildroot build time, and I was not > > > able to reproduce it, and therefore not able to check that your patch > > > solves it. > > > > Hmm, now I'm a little bit confused. Do you mean with autobuilder > > failure the results of the buildroot CI? > > I think this issues was already solves with the patch provided by > > Fabrice Fontaine: > > > > http://lists.busybox.net/pipermail/buildroot/2019-October/265043.html > > http://lists.busybox.net/pipermail/buildroot/2019-October/265044.html > > > > And currently there should'nt be any autobuilder failures!? > > Is your patch https://patchwork.ozlabs.org/patch/1188504/ fixing any > autobuilder failure ? I was assuming it was there to fix the build > issue at > http://autobuild.buildroot.net/results/bcd/bcd9bdd3bc83c1f2ab0b24348d51de27d88649b4/build-end.log. > > http://lists.busybox.net/pipermail/buildroot/2019-October/265043.html > fixes > http://autobuild.buildroot.net/results/d80/d807f3dc922a61e099a66de3bc340c018a86e150/build-end.log, > which is a different failure. > > http://lists.busybox.net/pipermail/buildroot/2019-October/265044.html > fixes > http://autobuild.buildroot.net/results/f0e/f0e4368977f257d76aedff335af3068deafaf28f/build-end.log > which another different issue. > > > And this patch fixes some "new" issues with wrongly installed files in > > wrong locations. > > Yes, which is exactly what is reported at > http://autobuild.buildroot.net/results/bcd/bcd9bdd3bc83c1f2ab0b24348d51de27d88649b4/build-end.log, > but I was not able to reproduce this failure with a simple configuration. > > Hence my question: do you have a simple configuration that reproduces > the "wrongly installed files in wrong locations" issue ? Ok .. I was not aware of that failure. Simple misunderstanding. I don't have a config for that. -- Heiko
On Mon, 11 Nov 2019 15:35:28 +0100 Heiko Thiery <heiko.thiery@gmail.com> wrote: > > Hence my question: do you have a simple configuration that reproduces > > the "wrongly installed files in wrong locations" issue ? > > Ok .. I was not aware of that failure. Simple misunderstanding. I > don't have a config for that. So how did you test your patch http://patchwork.ozlabs.org/patch/1188504/ ? Thomas
I used utils/test-pkg -p sysrepo -k and I have a board configuration where an image is created. Am Mo., 11. Nov. 2019 um 15:40 Uhr schrieb Thomas Petazzoni <thomas.petazzoni@bootlin.com>: > > On Mon, 11 Nov 2019 15:35:28 +0100 > Heiko Thiery <heiko.thiery@gmail.com> wrote: > > > > Hence my question: do you have a simple configuration that reproduces > > > the "wrongly installed files in wrong locations" issue ? > > > > Ok .. I was not aware of that failure. Simple misunderstanding. I > > don't have a config for that. > > So how did you test your patch http://patchwork.ozlabs.org/patch/1188504/ ? > > Thomas > -- > Thomas Petazzoni, CTO, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com
On Mon, 11 Nov 2019 15:43:20 +0100 Heiko Thiery <heiko.thiery@gmail.com> wrote: > I used utils/test-pkg -p sysrepo -k and I have a board configuration > where an image is created. But which *failure* is your patch fixing ? Thomas
Thomas Petazzoni <thomas.petazzoni@bootlin.com> schrieb am Mo., 11. Nov. 2019, 15:59: > On Mon, 11 Nov 2019 15:43:20 +0100 > Heiko Thiery <heiko.thiery@gmail.com> wrote: > > > I used utils/test-pkg -p sysrepo -k and I have a board configuration > > where an image is created. > > But which *failure* is your patch fixing ? > > Thomas > -- > Thomas Petazzoni, CTO, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.co <https://bootlin.com>m > Installing the sysrepo database to the target directory >
On Mon, 11 Nov 2019 16:04:15 +0100
Heiko Thiery <heiko.thiery@gmail.com> wrote:
> Installing the sysrepo database to the target directory
And how do you do that? When does it happen?
Thomas
Thomas Petazzoni <thomas.petazzoni@bootlin.com> schrieb am Mo., 11. Nov. 2019, 16:12: > On Mon, 11 Nov 2019 16:04:15 +0100 > Heiko Thiery <heiko.thiery@gmail.com> wrote: > > > Installing the sysrepo database to the target directory > > And how do you do that? When does it happen? > > Thomas > -- > Thomas Petazzoni, CTO, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com When setting the REPOSITORY_LOC=$(TARGET_DIR)/etc/sysrepo in the host confguration the syrepo database is created correctly in the install step into the target dir. But then in all install steps (host, staging and target) the files are created in the target dir. Therefore I do not allow to use the sysrepo buildsystem install in host and staging step. The files that are incluenced form this REPOSITORY_LOC setting will en in "etc/sysrepo/yang/" and "etc/sysrepo/data". -- Heiko
Am Mo., 11. Nov. 2019 um 20:22 Uhr schrieb Heiko Thiery <heiko.thiery@gmail.com>: > > > Thomas Petazzoni <thomas.petazzoni@bootlin.com> schrieb am Mo., 11. Nov. 2019, 16:12: >> >> On Mon, 11 Nov 2019 16:04:15 +0100 >> Heiko Thiery <heiko.thiery@gmail.com> wrote: >> >> > Installing the sysrepo database to the target directory >> >> And how do you do that? When does it happen? >> >> Thomas >> -- >> Thomas Petazzoni, CTO, Bootlin >> Embedded Linux and Kernel engineering >> https://bootlin.com > > > When setting the REPOSITORY_LOC=$(TARGET_DIR)/etc/sysrepo in the host confguration the syrepo database > is created correctly in the install step into the target dir. But then in all install steps (host, staging and target) the files > are created in the target dir. Therefore I do not allow to use the sysrepo buildsystem install in host and staging step. > The files that are incluenced form this REPOSITORY_LOC setting will en in "etc/sysrepo/yang/" and "etc/sysrepo/data". So if it is no problem that the host install and staging install copies files to the target directory the simplest solution is just to set the REPOSITORY_LOC=$(TARGET_DIR)/etc/sysrepo in the host configuration.
Hi Thomas, Am Di., 12. Nov. 2019 um 08:53 Uhr schrieb Heiko Thiery <heiko.thiery@gmail.com>: > > Am Mo., 11. Nov. 2019 um 20:22 Uhr schrieb Heiko Thiery > <heiko.thiery@gmail.com>: > > > > > > Thomas Petazzoni <thomas.petazzoni@bootlin.com> schrieb am Mo., 11. Nov. 2019, 16:12: > >> > >> On Mon, 11 Nov 2019 16:04:15 +0100 > >> Heiko Thiery <heiko.thiery@gmail.com> wrote: > >> > >> > Installing the sysrepo database to the target directory > >> > >> And how do you do that? When does it happen? > >> > >> Thomas > >> -- > >> Thomas Petazzoni, CTO, Bootlin > >> Embedded Linux and Kernel engineering > >> https://bootlin.com > > > > > > When setting the REPOSITORY_LOC=$(TARGET_DIR)/etc/sysrepo in the host confguration the syrepo database > > is created correctly in the install step into the target dir. But then in all install steps (host, staging and target) the files > > are created in the target dir. Therefore I do not allow to use the sysrepo buildsystem install in host and staging step. > > The files that are incluenced form this REPOSITORY_LOC setting will en in "etc/sysrepo/yang/" and "etc/sysrepo/data". > > So if it is no problem that the host install and staging install > copies files to the target directory the simplest solution is just > to set the REPOSITORY_LOC=$(TARGET_DIR)/etc/sysrepo in the host configuration. Is there a chance to get the patch into next? As I wrote in the last mail the minimum fix should be to set the REPOSITORY_LOC=$(TARGET_DIR)/etc/sysrepo for the host config. -- Heiko
Hi, Am So., 17. Nov. 2019 um 06:32 Uhr schrieb Heiko Thiery <heiko.thiery@gmail.com>: > > Hi Thomas, > > Am Di., 12. Nov. 2019 um 08:53 Uhr schrieb Heiko Thiery > <heiko.thiery@gmail.com>: > > > > Am Mo., 11. Nov. 2019 um 20:22 Uhr schrieb Heiko Thiery > > <heiko.thiery@gmail.com>: > > > > > > > > > Thomas Petazzoni <thomas.petazzoni@bootlin.com> schrieb am Mo., 11. Nov. 2019, 16:12: > > >> > > >> On Mon, 11 Nov 2019 16:04:15 +0100 > > >> Heiko Thiery <heiko.thiery@gmail.com> wrote: > > >> > > >> > Installing the sysrepo database to the target directory > > >> > > >> And how do you do that? When does it happen? > > >> > > >> Thomas > > >> -- > > >> Thomas Petazzoni, CTO, Bootlin > > >> Embedded Linux and Kernel engineering > > >> https://bootlin.com > > > > > > > > > When setting the REPOSITORY_LOC=$(TARGET_DIR)/etc/sysrepo in the host confguration the syrepo database > > > is created correctly in the install step into the target dir. But then in all install steps (host, staging and target) the files > > > are created in the target dir. Therefore I do not allow to use the sysrepo buildsystem install in host and staging step. > > > The files that are incluenced form this REPOSITORY_LOC setting will en in "etc/sysrepo/yang/" and "etc/sysrepo/data". > > > > So if it is no problem that the host install and staging install > > copies files to the target directory the simplest solution is just > > to set the REPOSITORY_LOC=$(TARGET_DIR)/etc/sysrepo in the host configuration. > > Is there a chance to get the patch into next? As I wrote in the last > mail the minimum fix should be to set the > REPOSITORY_LOC=$(TARGET_DIR)/etc/sysrepo for the host config. Is there something I can do to to revive this thread? Heiko
diff --git a/package/sysrepo/sysrepo.mk b/package/sysrepo/sysrepo.mk index 8676158a19..2d9d47c4f2 100644 --- a/package/sysrepo/sysrepo.mk +++ b/package/sysrepo/sysrepo.mk @@ -34,6 +34,18 @@ ifeq ($(BR2_TOOLCHAIN_HAS_LIBATOMIC),y) SYSREPO_CONF_OPTS += -DCMAKE_EXE_LINKER_FLAGS=-latomic endif +define SYSREPO_INSTALL_STAGING_CMDS + mkdir -p $(STAGING_DIR)/usr/lib $(STAGING_DIR)/usr/include/sysrepo + $(INSTALL) -m 0644 -D $(@D)/libsysrepo.pc \ + $(STAGING_DIR)/usr/lib/pkgconfig + $(INSTALL) -m 0644 -D $(@D)/src/libsysrepo.so* \ + $(STAGING_DIR)/usr/lib + $(INSTALL) -m 0644 -D $(@D)/inc/sysrepo.h \ + $(STAGING_DIR)/usr/include + $(INSTALL) -m 0644 -D $(@D)/inc/sysrepo/* \ + $(STAGING_DIR)/usr/include/sysrepo/ +endef + define SYSREPO_INSTALL_INIT_SYSV $(INSTALL) -m 755 -D package/sysrepo/S50sysrepod \ $(TARGET_DIR)/etc/init.d/S50sysrepod @@ -49,17 +61,21 @@ define SYSREPO_INSTALL_INIT_SYSTEMD $(TARGET_DIR)/etc/systemd/system/multi-user.target.wants endef +# Configure $(TARGET_DIR) pathes here because it is hardcoded in host +# executables that used later for target install step HOST_SYSREPO_CONF_OPTS = \ - -DGEN_PYTHON2_TESTS=OFF \ - -DENABLE_TESTS=OFF \ - -DGEN_CPP_BINDINGS=OFF \ - -DGEN_LANGUAGE_BINDINGS=OFF \ - -DGEN_PYTHON_BINDINGS=OFF \ - -DCALL_TARGET_BINS_DIRECTLY=OFF \ - -DBUILD_EXAMPLES=OFF \ - -DBUILD_CPP_EXAMPLES=OFF \ - -DREPOSITORY_LOC=$(HOST_DIR)/etc/sysrepo \ - -DSUBSCRIPTIONS_SOCKET_DIR=$(HOST_DIR)/var/run/sysrepo-subscriptions + -DREPOSITORY_LOC=$(TARGET_DIR)/etc/sysrepo \ + -DSUBSCRIPTIONS_SOCKET_DIR=$(TARGET_DIR)/var/run/sysrepo-subscriptions + +define HOST_SYSREPO_BUILD_CMDS + $(HOST_MAKE_ENV) $(MAKE) $(HOST_CONFIGURE_OPTS) -C $(@D) sysrepocfg + $(HOST_MAKE_ENV) $(MAKE) $(HOST_CONFIGURE_OPTS) -C $(@D) sysrepoctl +endef + +define HOST_SYSREPO_INSTALL_CMDS + $(INSTALL) -D -m 755 $(@D)/src/sysrepocfg $(HOST_DIR)/usr/bin/ + $(INSTALL) -D -m 755 $(@D)/src/sysrepoctl $(HOST_DIR)/usr/bin/ +endef $(eval $(cmake-package)) $(eval $(host-cmake-package))