From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 2919141EA1 for ; Wed, 15 Mar 2023 17:43:40 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 247D940A7A; Wed, 15 Mar 2023 17:43:40 +0100 (CET) Received: from mail-oi1-f175.google.com (mail-oi1-f175.google.com [209.85.167.175]) by mails.dpdk.org (Postfix) with ESMTP id 622B840141 for ; Wed, 15 Mar 2023 17:43:38 +0100 (CET) Received: by mail-oi1-f175.google.com with SMTP id bp19so14609237oib.4 for ; Wed, 15 Mar 2023 09:43:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1678898617; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=eqjdPGHB7eyDDLLlGZbJbplry79k4JA+4FboE/U/Rxc=; b=Vn7S1/7x4k8BJESaZIL+ucRChkOVABbkran0fNVTvr5ZH4ixYrjEXg6/O2AIJZeYEb f+onP9kP9hAItG6RnAmLKW/iYoxVPvhrHCBSdfy1FVqttjCvkJKKyYchhkaYccpLOoae yQKGpE8/R4xQ4Jf56/Ch1nbKwv03ydAp5k6m8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678898617; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=eqjdPGHB7eyDDLLlGZbJbplry79k4JA+4FboE/U/Rxc=; b=p6B/MaSzg+OO15EFFX9HzELVjPVobmZvNwW3SpvQ/q+iiNJcyDDa0NO+WcyD9R1iNY ctAgjeVdIIKIteDvUNiriZabLb8cUsiLROdOpJoJ41F/H5uugFksUUEyTLZdhtVATKt+ o6GQnd8JF0yrY5FJbfnBAiQkpDhiX2iXbK+ZqBsLZZpT/Su1SGZqk9gdk7obbAgYIEps pnW8OtP4FChZCGMItZCnpKarRbKDt5+r7Y52zoo3Ct6GVeVFHDZHXO7j53u3lre2EV3e WddXXvv8gcTpOffSL1R/XecV5LLKoefXJ6ptXsLO8FnwnmUvvS72rrRCdev3YYCqcHDJ tE5g== X-Gm-Message-State: AO0yUKVvWLdA9ruEFAXPgZtRnxMqRLVaOpcT/ALcj1TdfMqFb36gPgMu 0nZVu/UaNxNnK6Gi/Ln0DbJevkyJj1QIh7sui/jrfg== X-Google-Smtp-Source: AK7set+u78CZ+J8VBGF2jPBiEYLxEoqMBqnR6ReTFNH2ZSlo/8h/LT1qv/9fQELxl+eAkAC2CckQ35y098Qc1HY1GBU= X-Received: by 2002:a05:6808:57:b0:384:2b09:45f7 with SMTP id v23-20020a056808005700b003842b0945f7mr1045042oic.4.1678898617490; Wed, 15 Mar 2023 09:43:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Patrick Robb Date: Wed, 15 Mar 2023 12:43:26 -0400 Message-ID: Subject: Re: Meson buildtype for ci jobs? To: David Marchand Cc: ci@dpdk.org, Aaron Conole , Bruce Richardson , Thomas Monjalon Content-Type: multipart/alternative; boundary="000000000000b5b8f305f6f30b4b" X-BeenThere: ci@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK CI discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ci-bounces@dpdk.org --000000000000b5b8f305f6f30b4b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > On Wed, Mar 15, 2023 at 4:52=E2=80=AFPM Patrick Robb = wrote: > > Are you sure about the default value? > > Afaics, meson selects by default a "release" buildtype (and I think I > always saw this value in the past). > I have this with meson 1.0. > > $ meson setup qsdlgfh > ... > $ meson configure qsdlgfh | grep buildtype > buildtype release > [plain, debug, debugoptimized, Build type to use > > Thanks, you're right - I missed this in the meson.build file. So the default is release, which is what we run at the lab since we never pass a custom buildtype option in at meson setup. > > > > The reason I'm writing this email is that I'm wondering whether the > buildtype decision made by those who wrote .ci/linux-build.sh for GHA was > intentional and important. I know many of the people who have commits on > that script follow this mailing list. Obviously if it's in some way more > appropriate for CI purposes to run meson setup in this way, I'm happy to > make that change at the lab and in the process that would free up bringin= g > Alpine compile testing online. But, if not, then I think it's most > appropriate to consider compile on Alpine as broken and avoid bringing > coverage for Alpine online until that issue is resolved. > > The reason why we went with debugoptimized was primarly for the ABI > checks, as by default, the debug symbols were missing (which would > match with a "release" default buildtype). > See 777014e56d07 ("devtools: add ABI checks"). > Gotcha. Thanks that makes sense. Well, I guess what I had (unknowingly) done initially with our Alpine container at the lab was a release build, but I'll do a release build on GHA to sanity check again anyways, which will presumably fail. So, I guess the conclusion is if it doesn't build with the default buildtype set by meson.build, it's broken and we will not bring Alpine compile coverage online right now. Thanks, let me know if you think I'm missing anything here! -Patrick On Wed, Mar 15, 2023 at 12:08=E2=80=AFPM David Marchand wrote: > On Wed, Mar 15, 2023 at 4:52=E2=80=AFPM Patrick Robb = wrote: > > > > Hello all, > > > > The lab recently received a request to re-enable Alpine compile jobs, > which have been disabled for almost a year. In dry running the compile jo= b, > I noticed that it was failing. At the same time, David Marchand did an > Alpine compile with Github Actions which was successful. It seems the > source of the different behavior is the meson buildtype being used - the > build script used by GHA sets meson buildtype to debugoptimized, whereas > the script used by the community lab runs with buildtype debug (the meson > default). I did my own Github Actions runs (with both buildtype options) = to > sanity check: > https://github.com/PatrickRobbIOL/dpdk/actions/runs/4427160204/jobs/77643= 68640 > > Are you sure about the default value? > > Afaics, meson selects by default a "release" buildtype (and I think I > always saw this value in the past). > I have this with meson 1.0. > > $ meson setup qsdlgfh > ... > $ meson configure qsdlgfh | grep buildtype > buildtype release > [plain, debug, debugoptimized, Build type to use > > > > > The reason I'm writing this email is that I'm wondering whether the > buildtype decision made by those who wrote .ci/linux-build.sh for GHA was > intentional and important. I know many of the people who have commits on > that script follow this mailing list. Obviously if it's in some way more > appropriate for CI purposes to run meson setup in this way, I'm happy to > make that change at the lab and in the process that would free up bringin= g > Alpine compile testing online. But, if not, then I think it's most > appropriate to consider compile on Alpine as broken and avoid bringing > coverage for Alpine online until that issue is resolved. > > The reason why we went with debugoptimized was primarly for the ABI > checks, as by default, the debug symbols were missing (which would > match with a "release" default buildtype). > See 777014e56d07 ("devtools: add ABI checks"). > > > -- > David Marchand > > --=20 Patrick Robb Technical Service Manager UNH InterOperability Laboratory 21 Madbury Rd, Suite 100, Durham, NH 03824 www.iol.unh.edu --000000000000b5b8f305f6f30b4b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Mar 15, 2023 at 4:52= =E2=80=AFPM Patrick Robb <probb@iol.unh.edu> wrote:

Are you sure about = the default value?

Afaics, meson selects by default a "release&= quot; buildtype (and I think I
always saw this value in the past).
I = have this with meson 1.0.

$ meson setup qsdlgfh
...
$ meson co= nfigure qsdlgfh | grep buildtype
=C2=A0 buildtype=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 release
[plain, = debug, debugoptimized,=C2=A0 =C2=A0Build type to use

=C2=A0
Thanks, you're right - I missed this in the meson.build file. So = the default is release, which is what we run at the lab since we never pass= a custom buildtype option in at meson setup.
=C2=A0
>
> The reason I'm writing this email = is that I'm wondering whether the buildtype decision made by those who = wrote .ci/linux-build.sh for GHA was intentional and important. I know many= of the people who have commits on that script follow this mailing list. Ob= viously if it's in some way more appropriate for CI purposes to run mes= on setup in this way, I'm happy to make that change at the lab and in t= he process that would free up bringing Alpine compile testing online. But, = if not, then I think it's most appropriate to consider compile on Alpin= e as broken and avoid bringing coverage for Alpine online until that issue = is resolved.

The reason why we went with debugoptimized was p= rimarly for the ABI
checks, as by default, the debug symbols were missin= g (which would
match with a "release" default buildtype).
S= ee 777014e56d07 ("devtools: add ABI checks").

Gotcha. Thanks that makes sense. Well, I guess what I had = (unknowingly) done initially with our Alpine container at the lab was a rel= ease build, but I'll do a release build on GHA to sanity check again an= yways, which will presumably fail.=C2=A0

So, I gue= ss the conclusion is if it doesn't build with the default buildtype set= by meson.build, it's broken and we will not bring Alpine compile cover= age online right now.=C2=A0

Thanks, let me know if= you think I'm missing anything here! -Patrick=C2=A0

On Wed, Mar 1= 5, 2023 at 12:08=E2=80=AFPM David Marchand <david.marchand@redhat.com> wrote:
On Wed, Mar 15, 2023 at 4:52=E2= =80=AFPM Patrick Robb <probb@iol.unh.edu> wrote:
>
> Hello all,
>
> The lab recently received a request to re-enable Alpine compile jobs, = which have been disabled for almost a year. In dry running the compile job,= I noticed that it was failing. At the same time, David Marchand did an Alp= ine compile with Github Actions which was successful. It seems the source o= f the different behavior is the meson buildtype being used - the build scri= pt used by GHA sets meson buildtype to debugoptimized, whereas the script u= sed by the community lab runs with buildtype debug (the meson default). I d= id my own Github Actions runs (with both buildtype options) to sanity check= : https://github.com/P= atrickRobbIOL/dpdk/actions/runs/4427160204/jobs/7764368640

Are you sure about the default value?

Afaics, meson selects by default a "release" buildtype (and I thi= nk I
always saw this value in the past).
I have this with meson 1.0.

$ meson setup qsdlgfh
...
$ meson configure qsdlgfh | grep buildtype
=C2=A0 buildtype=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 release
[plain, debug, debugoptimized,=C2=A0 =C2=A0Build type to use

>
> The reason I'm writing this email is that I'm wondering whethe= r the buildtype decision made by those who wrote .ci/linux-build.sh for GHA= was intentional and important. I know many of the people who have commits = on that script follow this mailing list. Obviously if it's in some way = more appropriate for CI purposes to run meson setup in this way, I'm ha= ppy to make that change at the lab and in the process that would free up br= inging Alpine compile testing online. But, if not, then I think it's mo= st appropriate to consider compile on Alpine as broken and avoid bringing c= overage for Alpine online until that issue is resolved.

The reason why we went with debugoptimized was primarly for the ABI
checks, as by default, the debug symbols were missing (which would
match with a "release" default buildtype).
See 777014e56d07 ("devtools: add ABI checks").


--
David Marchand



--

Patrick Robb

<= span style=3D"font-size:10pt;font-family:Arial;color:rgb(0,0,0);background-= color:transparent;vertical-align:baseline;white-space:pre-wrap">Technical S= ervice Manager

UNH InterOperability Laboratory

21 Madbury Rd, Suite 100, Durham, NH 03824

www.iol.unh.edu


--000000000000b5b8f305f6f30b4b--