On Tue, 2021-08-24 at 00:35 -0500, William Hubbs wrote:
> Use the compile and install subcommands of meson instead of calling
> ninja. This allows for the possibility of a different back end.
>
> Signed-off-by: William Hubbs
> ---
> eclass/meson.eclass | 24 +---
> 1 file cha
On 24/08/2021 07.35, William Hubbs wrote:
Use the compile and install subcommands of meson instead of calling
ninja. This allows for the possibility of a different back end.
Signed-off-by: William Hubbs
---
eclass/meson.eclass | 24 +---
1 file changed, 21 insertions(+),
> On Tue, 24 Aug 2021, WANG Xuerui wrote:
> It seems the discussion has gone quiet for a while now, so I take that
> we choose ARCH=loong over ARCH=loongarch according to GLEP 53?
LGTM
> If that doesn't receive much objection, I'll prepare and send the
> first few eclass patches soon.
We al
Hi Ulrich,
On 2021/8/24 16:46, Ulrich Mueller wrote:
>> On Tue, 24 Aug 2021, WANG Xuerui wrote:
>> It seems the discussion has gone quiet for a while now, so I take that
>> we choose ARCH=loong over ARCH=loongarch according to GLEP 53?
> LGTM
>
>> If that doesn't receive much objection, I'll
Hi All,
We run glibc based systems. No musl. But we don't use systemd.
As little as a year back we still ran into issues with systemd-udev
variant breaking systems, the fix of course was to nuke it and install
eudev. Are we certain there is nothing (eg, LVM integration was our
biggest problem
On 8/24/21 6:24 AM, Jaco Kroon wrote:
> Hi All,
>
> We run glibc based systems. No musl. But we don't use systemd.
>
> As little as a year back we still ran into issues with systemd-udev
> variant breaking systems, the fix of course was to nuke it and install
> eudev. Are we certain there is n
> On Tue, 24 Aug 2021, WANG Xuerui wrote:
> According to their earlier reservation[1] and actual vendor system
> behavior, there are 3 possible values:
> - loongarch64
> - loongarch32
> - loongarchx32
> Only the LP64 ABI is fully supported by the current upstream submission.
> The "loongarch
Use the compile and install subcommands of meson instead of calling
ninja. This allows for the possibility of a different back end.
Signed-off-by: William Hubbs
---
eclass/meson.eclass | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/eclass/meson.eclass
On Tue, Aug 24, 2021 at 3:59 AM Florian Schmaus wrote:
>
> On 24/08/2021 07.35, William Hubbs wrote:
> > Use the compile and install subcommands of meson instead of calling
> > ninja. This allows for the possibility of a different back end.
> >
> > Signed-off-by: William Hubbs
> > ---
> > eclas
On Tue, Aug 24, 2021 at 1:35 AM William Hubbs wrote:
>
> Use the compile and install subcommands of meson instead of calling
> ninja. This allows for the possibility of a different back end.
>
> Signed-off-by: William Hubbs
> ---
> eclass/meson.eclass | 24 +---
> 1 file chan
Use the compile and install subcommands of meson instead of calling
ninja. This allows for the possibility of a different back end.
Stop using the NINJAOPTS variable.
Signed-off-by: William Hubbs
---
eclass/meson.eclass | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
Use the compile and install subcommands of meson instead of calling
ninja. This allows for the possibility of a different back end.
Stop using the NINJAOPTS variable.
Add --num-processes to "meson test" call regardless of whether MAKEOPTS
is set since the default is 1 process.
Signed-off-by: Will
> On 24 Aug 2021, at 11:24, Jaco Kroon wrote:
>
> Hi All,
>
> We run glibc based systems. No musl. But we don't use systemd.
>
> As little as a year back we still ran into issues with systemd-udev
> variant breaking systems, the fix of course was to nuke it and install
> eudev. Are we cert
13 matches
Mail list logo
