[1/1] package/sysrepo: fix host/staging install steps
diff mbox series

Message ID 20191103060113.4884-1-heiko.thiery@gmail.com
State New
Headers show
Series
  • [1/1] package/sysrepo: fix host/staging install steps
Related show

Commit Message

Heiko Thiery Nov. 3, 2019, 6:01 a.m. UTC
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(-)

Comments

Thomas Petazzoni Nov. 4, 2019, 9:38 p.m. UTC | #1
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
Heiko Thiery Nov. 5, 2019, 8:03 a.m. UTC | #2
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
Thomas Petazzoni Nov. 5, 2019, 8:09 a.m. UTC | #3
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
Heiko Thiery Nov. 5, 2019, 8:19 a.m. UTC | #4
> -----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.
Thomas Petazzoni Nov. 8, 2019, 9:58 p.m. UTC | #5
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
Heiko Thiery Nov. 10, 2019, 4 p.m. UTC | #6
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
Thomas Petazzoni Nov. 11, 2019, 1:53 p.m. UTC | #7
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
Heiko Thiery Nov. 11, 2019, 2:07 p.m. UTC | #8
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
Thomas Petazzoni Nov. 11, 2019, 2:27 p.m. UTC | #9
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
Heiko Thiery Nov. 11, 2019, 2:35 p.m. UTC | #10
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
Thomas Petazzoni Nov. 11, 2019, 2:40 p.m. UTC | #11
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
Heiko Thiery Nov. 11, 2019, 2:43 p.m. UTC | #12
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
Thomas Petazzoni Nov. 11, 2019, 2:59 p.m. UTC | #13
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
Heiko Thiery Nov. 11, 2019, 3:04 p.m. UTC | #14
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

>
Thomas Petazzoni Nov. 11, 2019, 3:12 p.m. UTC | #15
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
Heiko Thiery Nov. 11, 2019, 7:22 p.m. UTC | #16
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
Heiko Thiery Nov. 12, 2019, 7:53 a.m. UTC | #17
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.
Heiko Thiery Nov. 17, 2019, 5:32 a.m. UTC | #18
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

Patch
diff mbox series

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