| View previous topic :: View next topic |
| Author |
Message |
Oddly
n00b
Joined: 20 Jun 2024
Posts: 3
|
 Posted: Thu Jun 20, 2024 10:18 pm Post subject: Ebuild writing - how to properly install files |
 |
|
I have been trying to write this ebuild for BespokeSynth. It now compiles, though I do need to clean up dependencies some more. What I am struggling to figure out though, is how to have it install properly.
The instructions for the build itself happily say that a release build is produced within the build directory:
https://github.com/BespokeSynth/BespokeSynth
So far I've tried a couple of things which are summed up as follows:
| Code: | src_install() {
# Attempting to copy the binary from build directory
dobin "${WORKDIR}/BespokeSynth-${PV}_build/Source/BespokeSynth_artefacts/RelWithDebInfo/BespokeSynth"
# Attempting to copy the rest of the build dir
dodir /usr/share/bespokesyth/
cp -R "${WORKDIR}/BespokeSynth-${PV}_build/Source/BespokeSynth_artefacts/RelWithDebInfo" "${D}/" || die "Installation failed when copying files"
# When using cmake's default, the script just tries to install into the /tmp dir. This raises a whole lot of QA warnings as expected.
cmake_src_install
}
|
The ebuild I have so far can be found on Github
Thanks in advance! |
|
| Back to top |
|
 |
logrusx
Veteran
Joined: 22 Feb 2018
Posts: 1831
|
|
| Back to top |
|
|
fedeliallalinea
Administrator
Joined: 08 Mar 2003
Posts: 31048
Location: here
|
| Posted: Fri Jun 21, 2024 5:09 am Post subject: |
|
|
Can you post emerge output with wgetpaste?
_________________
Questions are guaranteed in life; Answers aren't. |
|
| Back to top |
|
|
Oddly
n00b
Joined: 20 Jun 2024
Posts: 3
|
| Posted: Fri Jun 21, 2024 10:09 am Post subject: |
|
|
Hi Georgi, thank for the quick answer.
I have been following the advice mentioned in the manual on src_install, specifically the first example for a trivial install.
Using insinto, I get the following ouput when doing **ebuild bespokesynth-1.2.1.ebuild install**: https://bpa.st/XYIA
| Code: |
src_install() {
# Copying the binary from build directory
dobin "${WORKDIR}/BespokeSynth-${PV}_build/Source/BespokeSynth_artefacts/RelWithDebInfo/BespokeSynth"
# Copy the rest of the build dir
dodir /usr/share/bespokesyth/
insinto /usr/share/bespokesynth
doins -r "${WORKDIR}/BespokeSynth-${PV}_build/Source/BespokeSynth_artefacts/RelWithDebInfo"
}
|
These two lines seem to hint that it still wants to install into the temporary build envirnoment. Is that normal in case of manually moving things around?
| Quote: |
>>> Install media-sound/bespokesynth-1.2.1 into /var/tmp/portage/media-sound/bespokesynth-1.2.1/image
>>> Completed installing media-sound/bespokesynth-1.2.1 into /var/tmp/portage/media-sound/bespokesynth-1.2.1/image
|
|
|
| Back to top |
|
|
logrusx
Veteran
Joined: 22 Feb 2018
Posts: 1831
|
| Posted: Fri Jun 21, 2024 10:22 am Post subject: |
|
|
| Oddly wrote: |
These two lines seem to hint that it still wants to install into the temporary build envirnoment. Is that normal in case of manually moving things around?
| Quote: |
>>> Install media-sound/bespokesynth-1.2.1 into /var/tmp/portage/media-sound/bespokesynth-1.2.1/image
>>> Completed installing media-sound/bespokesynth-1.2.1 into /var/tmp/portage/media-sound/bespokesynth-1.2.1/image
|
|
It's always first installed into image and then merged into the system. It's a separate phase - qmerge. Read man ebuild. Phases are listed and explained there. You can also emerge eclass-manpages. This way you could read cmake.class man page for example and see what it actually does and which phases it implements. Many eclasses implement only a single or a few phases, not all of them. I believe some don't implement anything at all but provide utility functions. If you inherit multiple eclasses, the default is from the last inherited eclass and if you want to execute others, you need to explicitly do so in you ebuild's corresponding phase. If you omit a phase in your ebuild, the default one is executed.
EDIT: I missed you were running ebuild install. This is what install phase does - install into a temporary location. To merge into the system you need to run ebuild qmerge. There's a merge phase which seems to be an aggregation of all the former phases.
You can also join #gentoo-dev-help on IRC and ask there.
Best Regards,
Georgi |
|
| Back to top |
|
|
Oddly
n00b
Joined: 20 Jun 2024
Posts: 3
|
| Posted: Fri Jun 21, 2024 5:01 pm Post subject: |
|
|
Thank you so far. I didn't know about the qmerge stage. I was following the guide in the devmanual: https://devmanual.gentoo.org/ebuild-writing/functions/index.html
It's phases seem to be a bit different. I suppose qmerge is happening between pgk_preinst and pkh_postinst?
It seems to be installing now, though I still have some debugging to do with misplacing libraries and what not. Thank you again for the help and the clear explanation. |
|
| Back to top |
|
|
logrusx
Veteran
Joined: 22 Feb 2018
Posts: 1831
|
| Posted: Fri Jun 21, 2024 6:09 pm Post subject: |
|
|
| Oddly wrote: | | I suppose qmerge is happening between pgk_preinst and pkh_postinst? |
Well, I might actually made that up. there wasn't that much information when I started. Thank you for the question, because I now realize I have put an equivalence sign between ebuild commands and phases, but those are not the same. Ebuild commands may invoke phases, but they are something more abstract I guess. Qmerge should be something in portage, not the ebuild. Preinst, postinst, I think those are before qmerge, because you can override them.
I'm not sure. Maybe ask on IRC, some of the devs are always there.
Best Regards,
Georgi |
|
| Back to top |
|
|
eschwartz
n00b
Joined: 29 Oct 2023
Posts: 70
|
| Posted: Fri Jun 21, 2024 8:18 pm Post subject: |
|
|
| Code: |
src_configure() {
local mycmakeargs=(
"-DBESPOKE_SYSTEM_PYBIND11=TRUE"
"-DBESPOKE_SYSTEM_JSONCPP=TRUE"
"-DCMAKE_BUILD_TYPE=Release"
"-DCMAKE_INSTALL_PREFIX=/usr/share"
|
Don't manually pass CMAKE_BUILD_TYPE. Is there a particular reason the gentoo default RelWithDebInfo is a problem? If so -- set it as a global ebuild variable, see https://devmanual.gentoo.org/eclass-reference/cmake.eclass/#lbAG for details.
Setting CMAKE_INSTALL_PREFIX is also quite wrong, since it will be set automatically to /usr and your alternative value means e.g. binaries will be installed to /usr/share/bin and /usr/share/lib64 and /usr/share/share if cmake_src_install gets used.
...
As noted by others,
| Quote: |
# When using cmake's default, the script just tries to install into the /tmp dir. This raises a whole lot of QA warnings as expected.
|
is probably an issue of misunderstanding how to fully install a package (this is why it's better to use "emerge" instead of "ebuild") so if there is an error encountered by actually fully installing the package, that would be good to know about. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20149
|
| Posted: Fri Jun 21, 2024 9:08 pm Post subject: |
|
|
| man ebuild: | qmerge This function installs all the files in the install directory to the live filesystem. The process works as follows: first, the
pkg_preinst() function (if specified) is run. Then, the files are merged into the live filesystem, and the installed files’
checksums are recorded in /var/db/pkg/${CATEGORY}/${PN}-${PVR}/CONTENTS. After all the files have been merged, the
pkg_postinst() function (if specified) is executed.
merge Normally, to merge an ebuild, you need to fetch, unpack, compile, install and qmerge. If you’re simply interested in merging the
ebuild, you can use this command, which will perform all these steps for you, stopping along the way if a particular step doesn’t
complete successfully. |
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
eschwartz
n00b
Joined: 29 Oct 2023
Posts: 70
|
| Posted: Fri Jun 21, 2024 9:19 pm Post subject: |
|
|
It is harder to mistakenly do the wrong thing, if you use the "emerge" command which installs dependencies and does a fresh "clean merge", so... yeah. 
Advanced low-level tooling should only be used if you are certain you know how it all works from top to bottom and even then I often still use emerge -p first to check that there's no missing dependencies. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20149
|
| Posted: Fri Jun 21, 2024 9:50 pm Post subject: |
|
|
When trying to create an ebuild, it seems reasonable to also learn how to use the build command.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
logrusx
Veteran
Joined: 22 Feb 2018
Posts: 1831
|
| Posted: Sat Jun 22, 2024 3:20 am Post subject: |
|
|
| eschwartz wrote: | It is harder to mistakenly do the wrong thing, if you use the "emerge" command which installs dependencies and does a fresh "clean merge", so... yeah. :)
Advanced low-level tooling should only be used if you are certain you know how it all works from top to bottom and even then I often still use emerge -p first to check that there's no missing dependencies. |
Imagine you were working on a chromium clone ebuild. How would you like it to use the emerge command?
Best Regards,
Georgi |
|
| Back to top |
|
|
|
Portage & Programming
