From: Bin Meng <bin.meng@windriver.com>
At present the prerequisite packages for 64-bit and 32-bit builds
are slightly different. Let's use the same packages for both.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
---
.gitlab-ci.d/windows.yml | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/.gitlab-ci.d/windows.yml b/.gitlab-ci.d/windows.yml
index 86a4339c48..fffb202658 100644
--- a/.gitlab-ci.d/windows.yml
+++ b/.gitlab-ci.d/windows.yml
@@ -40,11 +40,15 @@ msys2-64bit:
mingw-w64-x86_64-gcc
mingw-w64-x86_64-glib2
mingw-w64-x86_64-gnutls
+ mingw-w64-x86_64-gtk3
+ mingw-w64-x86_64-libgcrypt
+ mingw-w64-x86_64-libjpeg-turbo
mingw-w64-x86_64-libnfs
mingw-w64-x86_64-libpng
mingw-w64-x86_64-libssh
mingw-w64-x86_64-libtasn1
mingw-w64-x86_64-libusb
+ mingw-w64-x86_64-lzo2
mingw-w64-x86_64-nettle
mingw-w64-x86_64-ninja
mingw-w64-x86_64-pixman
@@ -77,16 +81,22 @@ msys2-32bit:
mingw-w64-i686-gtk3
mingw-w64-i686-libgcrypt
mingw-w64-i686-libjpeg-turbo
+ mingw-w64-i686-libnfs
+ mingw-w64-i686-libpng
mingw-w64-i686-libssh
mingw-w64-i686-libtasn1
mingw-w64-i686-libusb
mingw-w64-i686-lzo2
+ mingw-w64-i686-nettle
mingw-w64-i686-ninja
mingw-w64-i686-pixman
mingw-w64-i686-pkgconf
mingw-w64-i686-python
+ mingw-w64-i686-SDL2
+ mingw-w64-i686-SDL2_image
mingw-w64-i686-snappy
- mingw-w64-i686-usbredir "
+ mingw-w64-i686-usbredir
+ mingw-w64-i686-zstd "
- $env:CHERE_INVOKING = 'yes' # Preserve the current working directory
- $env:MSYSTEM = 'MINGW32' # Start a 32-bit MinG environment
- $env:MSYS = 'winsymlinks:native' # Enable native Windows symlink
--
2.34.1
On 08/09/2022 15.28, Bin Meng wrote: > From: Bin Meng <bin.meng@windriver.com> > > At present the prerequisite packages for 64-bit and 32-bit builds > are slightly different. Let's use the same packages for both. Not sure whether that's a good idea ... I did that on purpose to save some few time during compilation (since the Windows jobs are running very long already) ... did you check whether it makes a difference in the run time now? Thomas
On Sat, Sep 10, 2022 at 12:32 AM Thomas Huth <thuth@redhat.com> wrote: > > On 08/09/2022 15.28, Bin Meng wrote: > > From: Bin Meng <bin.meng@windriver.com> > > > > At present the prerequisite packages for 64-bit and 32-bit builds > > are slightly different. Let's use the same packages for both. > > Not sure whether that's a good idea ... I did that on purpose to save some > few time during compilation (since the Windows jobs are running very long > already) ... did you check whether it makes a difference in the run time now? > Not much difference on the build time. Actually I found after we switched to single thread build the time did not increase too. One side note regarding the gitlab shared runner: It seems the shared runner Windows VM is quite slow. Is it possible to get a faster VM externally? Regards, Bin
Hi Thomas, On Sat, Sep 10, 2022 at 8:32 AM Bin Meng <bmeng.cn@gmail.com> wrote: > > On Sat, Sep 10, 2022 at 12:32 AM Thomas Huth <thuth@redhat.com> wrote: > > > > On 08/09/2022 15.28, Bin Meng wrote: > > > From: Bin Meng <bin.meng@windriver.com> > > > > > > At present the prerequisite packages for 64-bit and 32-bit builds > > > are slightly different. Let's use the same packages for both. > > > > Not sure whether that's a good idea ... I did that on purpose to save some > > few time during compilation (since the Windows jobs are running very long > > already) ... did you check whether it makes a difference in the run time now? > > > > Not much difference on the build time. Actually I found after we > switched to single thread build the time did not increase too. > > One side note regarding the gitlab shared runner: > > It seems the shared runner Windows VM is quite slow. Is it possible to > get a faster VM externally? Any further comment for this patch? Regards, Bin
Hi Thomas, On Sat, Sep 24, 2022 at 5:20 PM Bin Meng <bmeng.cn@gmail.com> wrote: > > Hi Thomas, > > On Sat, Sep 10, 2022 at 8:32 AM Bin Meng <bmeng.cn@gmail.com> wrote: > > > > On Sat, Sep 10, 2022 at 12:32 AM Thomas Huth <thuth@redhat.com> wrote: > > > > > > On 08/09/2022 15.28, Bin Meng wrote: > > > > From: Bin Meng <bin.meng@windriver.com> > > > > > > > > At present the prerequisite packages for 64-bit and 32-bit builds > > > > are slightly different. Let's use the same packages for both. > > > > > > Not sure whether that's a good idea ... I did that on purpose to save some > > > few time during compilation (since the Windows jobs are running very long > > > already) ... did you check whether it makes a difference in the run time now? > > > > > > > Not much difference on the build time. Actually I found after we > > switched to single thread build the time did not increase too. > > > > One side note regarding the gitlab shared runner: > > > > It seems the shared runner Windows VM is quite slow. Is it possible to > > get a faster VM externally? > > Any further comment for this patch? > Ping? Regards, Bin
On 29/10/2022 15.06, Bin Meng wrote: > Hi Thomas, > > On Sat, Sep 24, 2022 at 5:20 PM Bin Meng <bmeng.cn@gmail.com> wrote: >> >> Hi Thomas, >> >> On Sat, Sep 10, 2022 at 8:32 AM Bin Meng <bmeng.cn@gmail.com> wrote: >>> >>> On Sat, Sep 10, 2022 at 12:32 AM Thomas Huth <thuth@redhat.com> wrote: >>>> >>>> On 08/09/2022 15.28, Bin Meng wrote: >>>>> From: Bin Meng <bin.meng@windriver.com> >>>>> >>>>> At present the prerequisite packages for 64-bit and 32-bit builds >>>>> are slightly different. Let's use the same packages for both. >>>> >>>> Not sure whether that's a good idea ... I did that on purpose to save some >>>> few time during compilation (since the Windows jobs are running very long >>>> already) ... did you check whether it makes a difference in the run time now? >>>> >>> >>> Not much difference on the build time. Actually I found after we >>> switched to single thread build the time did not increase too. >>> >>> One side note regarding the gitlab shared runner: >>> >>> It seems the shared runner Windows VM is quite slow. Is it possible to >>> get a faster VM externally? >> >> Any further comment for this patch? >> > > Ping? As long as the Windows CI runners are still that slow, I'm still not convinced that it is a good idea to add more stuff here. Maybe to the 32-bit build, since it runs a bit faster, but I think we really should avoid to extend the 64-bit build. Thomas
Am 29.10.22 um 15:06 schrieb Bin Meng: > Hi Thomas, > > On Sat, Sep 24, 2022 at 5:20 PM Bin Meng <bmeng.cn@gmail.com> wrote: >> >> Hi Thomas, >> >> On Sat, Sep 10, 2022 at 8:32 AM Bin Meng <bmeng.cn@gmail.com> wrote: >>> >>> On Sat, Sep 10, 2022 at 12:32 AM Thomas Huth <thuth@redhat.com> wrote: >>>> >>>> On 08/09/2022 15.28, Bin Meng wrote: >>>>> From: Bin Meng <bin.meng@windriver.com> >>>>> >>>>> At present the prerequisite packages for 64-bit and 32-bit builds >>>>> are slightly different. Let's use the same packages for both. >>>> >>>> Not sure whether that's a good idea ... I did that on purpose to save some >>>> few time during compilation (since the Windows jobs are running very long >>>> already) ... did you check whether it makes a difference in the run time now? >>>> >>> >>> Not much difference on the build time. Actually I found after we >>> switched to single thread build the time did not increase too. >>> >>> One side note regarding the gitlab shared runner: >>> >>> It seems the shared runner Windows VM is quite slow. Is it possible to >>> get a faster VM externally? >> >> Any further comment for this patch? >> > > Ping? > > Regards, > Bin Adding more packages typically is a good idea because it allows compilation of more code features, so the coverage during the build is increased. But here we have 32 and 64 bit builds for Windows which are less different than on Linux because sizeof(long) is the same for both. Nevertheless patch 5 of the series shows an example where 32 bit builds produced a warning, but 64 bit builds did not. So covering as much code as possible (which requires installation of all required packages) can be useful for build tests. And of course it is also necessary if the generated binaries should support as many features as possible. On the other hand builds with a reduced number of packages can also be reasonable, not only because they need less resources (build time, energy), but also because they can uncover broken dependencies. And for some applications smaller binaries with less features can be sufficient. So there is no clear answer for me whether the packages for 32 and 64 bit should be synchronized or not. I think technically the patch is fine. We can postpone the decision because it is not urgent for the upcoming release. Stefan
How about using github actions, I tried before and it's running fast, there
is no resource restriction.
Just don't know how to trigger it through gitlab, if that's possible, then
it's would be good
On Sat, Sep 10, 2022 at 8:33 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> On Sat, Sep 10, 2022 at 12:32 AM Thomas Huth <thuth@redhat.com> wrote:
> >
> > On 08/09/2022 15.28, Bin Meng wrote:
> > > From: Bin Meng <bin.meng@windriver.com>
> > >
> > > At present the prerequisite packages for 64-bit and 32-bit builds
> > > are slightly different. Let's use the same packages for both.
> >
> > Not sure whether that's a good idea ... I did that on purpose to save
some
> > few time during compilation (since the Windows jobs are running very
long
> > already) ... did you check whether it makes a difference in the run
time now?
> >
>
> Not much difference on the build time. Actually I found after we
> switched to single thread build the time did not increase too.
>
> One side note regarding the gitlab shared runner:
>
> It seems the shared runner Windows VM is quite slow. Is it possible to
> get a faster VM externally?
>
> Regards,
> Bin
>
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
© 2016 - 2026 Red Hat, Inc.