[gentoo-dev] dosym function in binary package ebuilds

[Fabulous Zhang Zheng]

Good evening, dear list

Most binary package ebuilds have such a *dosym* statement in src_install(),
take net-im/signal-desktop-bin as an example:

dosym ../../opt/Signal/${MY_PN} /usr/bin/${MY_PN} (where the variable
is signal-desktop)

*dosym* creates a symlink of the binary under opt at /usr/bin/ according to
devmanaul.

I'm confused about the "../../", since S="${workdir}",  the correct way
seems to be "dosym  ./opt/Signal/xxx/usr/bin/xxx"

It's much appreciated if anyone could help   ; )


└── signal-desktop-bin-5.50.0
├── distdir
│   └── signal-desktop_5.50.0_amd64.deb ->
/var/cache/distfiles/signal-desktop_5.50.0_amd64.deb
├── files -> /var/db/repos/gentoo/net-im/signal-desktop-bin/files
├── homedir
├── temp
│   ├── build.log
│   ├── eclass-debug.log
│   ├── environment
│   └── logging
└── work
├── opt
└── usr

Re: [gentoo-dev] dosym function in binary package ebuilds

[Fabulous Zhang Zheng]

Dear Alexey,

thanks a lot for your reply, now I get it.

The path in 1st argument is relative to 2nd argument, and what I thought
before was that it's relative to S="${workdir}".

Best wishes



Alexey Zapparov  于2022年7月23日周六 04:50写道：

> `dosym target link_name` creates a symlink. Under the hood it calls `ln`.
> First argument may be either absolute path or relative to link_name.
> Conventionally relative targets are used.
>
> On Fri, 22 Jul 2022, 16:56 Fabulous Zhang Zheng, <
> zheng1181822...@gmail.com> wrote:
>
>> Good evening, dear list
>>
>> Most binary package ebuilds have such a *dosym* statement in
>> src_install(), take net-im/signal-desktop-bin as an example:
>>
>> dosym ../../opt/Signal/${MY_PN} /usr/bin/${MY_PN} (where the variable
>> is signal-desktop)
>>
>> *dosym* creates a symlink of the binary under opt at /usr/bin/ according
>> to devmanaul.
>>
>> I'm confused about the "../../", since S="${workdir}",  the correct way
>> seems to be "dosym  ./opt/Signal/xxx/usr/bin/xxx"
>>
>> It's much appreciated if anyone could help   ; )
>>
>>
>> └── signal-desktop-bin-5.50.0
>> ├── distdir
>> │   └── signal-desktop_5.50.0_amd64.deb ->
>> /var/cache/distfiles/signal-desktop_5.50.0_amd64.deb
>> ├── files -> /var/db/repos/gentoo/net-im/signal-desktop-bin/files
>> ├── homedir
>> ├── temp
>> │   ├── build.log
>> │   ├── eclass-debug.log
>> │   ├── environment
>> │   └── logging
>> └── work
>> ├── opt
>> └── usr
>>
>>

[gentoo-dev] USE=ninja to compile by ninja, otherwise by make

[Fabulous Zhang Zheng]

Dear everyone,


While gentoo-devhelp is a better place for questions, it's been inactive
for years so I sent an email here. Apologies if this is solely for gentoo
developers.

I'm writing an ebuild of ddnet,  a cmake
argument of which is "-GNinja" controlling the build system to be ninja or
make.  Naturally I decided to add a USE flag "ninja"

Part of my src_configure function is as below:

local mycmakeargs=(
..
-DVULKAN=$(usex vulkan ON OFF)
)
use ninja && mycmakeargs+=( -GNinja )
cmake_src_configure

What confuses me is that portage seems to always use ninja to build, for
htop always indicates user portage is running ( ninja -v -j5 ), whenever
USE=ninja is enabled or disabled.

After trying to read cmake.eclass source code, I think separately denoting
ninja/make in src_compile and src_install might be possible. But
cmake_build still automatically detects the build type so I am confused.

My drafted ebuild file is attached below. It will be much appreciated if
anyone could help  :)


Best regards.


ddnet-16.2.2.ebuild
Description: Binary data

Re: [gentoo-dev] USE=ninja to compile by ninja, otherwise by make

[Fabulous Zhang Zheng]

Thanks for your reply

 于2022年7月30日周六 01:09写道：

> On Sat, 30 Jul 2022 00:38:54 +0800
> Fabulous Zhang Zheng  wrote:
>
> > Dear everyone,
> >
> >
> > While gentoo-devhelp is a better place for questions, it's been inactive
> > for years so I sent an email here. Apologies if this is solely for gentoo
> > developers.
>
> There's #gentoo-dev-help
>
> >
> > After trying to read cmake.eclass source code, I think separately
> denoting
> > ninja/make in src_compile and src_install might be possible. But
> > cmake_build still automatically detects the build type so I am confused.
> >
>
> Take a look at CMAKE_MAKEFILE_GENERATOR variable used in cmake.eclass.
> You want to change this from the default to emake if you want to use
> make instead of ninja.
>
>
> I noticed this variable before but it must be set before inherit.
If I try something like:

 if ! use ninja; then
CMAKE_MAKEFILE_GENERATOR=emake
fi
inherit cmake xdg ninja-utils

pkgcheck will say report error:
external commands disallowed during metadata regen: 'use ninja'

Best regards

Re: [gentoo-dev] USE=ninja to compile by ninja, otherwise by make

[Fabulous Zhang Zheng]

Sorry for bothering.

Fabulous Zhang Zheng  于2022年7月30日周六 01:31写道：

> Thanks for your reply
>
>  于2022年7月30日周六 01:09写道：
>
>> On Sat, 30 Jul 2022 00:38:54 +0800
>> Fabulous Zhang Zheng  wrote:
>>
>> > Dear everyone,
>> >
>> >
>> > While gentoo-devhelp is a better place for questions, it's been inactive
>> > for years so I sent an email here. Apologies if this is solely for
>> gentoo
>> > developers.
>>
>> There's #gentoo-dev-help
>>
>> >
>> > After trying to read cmake.eclass source code, I think separately
>> denoting
>> > ninja/make in src_compile and src_install might be possible. But
>> > cmake_build still automatically detects the build type so I am confused.
>> >
>>
>> Take a look at CMAKE_MAKEFILE_GENERATOR variable used in cmake.eclass.
>> You want to change this from the default to emake if you want to use
>> make instead of ninja.
>>
>>
>> I noticed this variable before but it must be set before inherit.
> If I try something like:
>
>  if ! use ninja; then
> CMAKE_MAKEFILE_GENERATOR=emake
> fi
> inherit cmake xdg ninja-utils
>
> pkgcheck will say report error:
> external commands disallowed during metadata regen: 'use ninja'
>
> Best regards
>

I asked this question in #gentoo-dev-help.

According to @iamben and @floppy, using the default ninja is best supported,
emake would only be preferred if the package fails with ninja.

And apologies again, for bothering with this list,
I was not aware of the IRC.

Best regards