Dnia wtorek, 4 kwiecień 2023 20:37:20 (+02:00), Jacek Caban via
Mingw-w64-public napisał(a):
> On 3/31/23 18:24, NightStrike wrote:
> >
> >
> > On Thu, Mar 30, 2023, 06:45 Jacek Caban via Mingw-w64-public wrote:
> >
> > On 3/20/23 16:44, مهدي شينون wrote:
> > > Hi everyone,
> > >
> > >
> > > Could you please consider migrating your project to another host
> > other
> > > than sourcefoge where people could file bugs, propose changes and
> > > discuss things (like GitHub ot GitLab).
> > >
> > > Using mailing-list for that is a way that's not suitable for young
> > > generation (including me).
> > >
> > > Many people try to report bugs or propose changes but ended up
> > ignored
> > > because of this insist on using this outdated technology!
> >
> >
> > We had similar talks in Wine for years and we finally decided
> > decided to
> > migrate to Gitlab last year. I think it was a good choice. We had it
> > running parallel to ML as an experiment first, here is the summary:
> >
> > https://www.winehq.org/pipermail/wine-devel/2022-June/220008.html
> >
> > I think most of it would apply to mingw-w64 as well. I'd like to
> > especially point CI: Gitlab makes it easy to set up CI and mingw-w64
> > could really use one. It's esp. nice for reviewers: by the time
> > you look
> > at the patch, you already know that it doesn't break the build.
> >
> >
> > The use of a hosted solution vs making lists for patches is orthogonal to
> > not using SF. We could use any of the many services SF offers, and I pushed
> > this hard over the years, but people like mailing list patches. Part of it
> > is old habits, part of it is accessibility. Patch commenting on a website
> > with markdown is neat and useful, but not very accessible.
>
>
> It's not website nor markdown that I care about (in fact, UI is not really
> Gitlab's strong side). Better git utilization is nice to have. It also makes
> CI easy to automate. Ideally CI would catch problems very early, with no need
> to bother reviewers.
>
>
> > As for CI, remember that to have effective CI for us requires building the
> > whole toolchain. We used to do this daily with a buildbot service set up by
> > Mook and me, served by ReactOS, and run on donated hardware. Mook left,
> > react stopped giving us the server, and donors stopped donating.
> >
> > I'm working with MJW to get a builder running on the SW BB. That should
> > take care of this requirement, but mind you that native builds can take
> > days to finish.
>
>
> It's sad that native builds take days to finish... Is there any hope that it
> will improve? Is it a matter of Cygwin/msys being slow? If yes, can it be
> optimized? If not...
>
Using niXman scripts GNU build takes with free GitHub builders it takes 4-6
hours per build (they run parallel though):
https://github.com/mati865/mingw-builds/actions/runs/4526815011
AFAICT a lot of this time is wasted by inefficiency fork emulation in Cygwin (I
don't blame them though) which is used by autotools a lot.
I cannot compare LLVM directly as I build it only locally (and I don't build
GNU toolchain locally) but it used to take about half of the time few years ago,
>
> Anyway, for pre-commit CI, we don't need a full toolchain bootstrap.
> Rebuilding mingw-w64 parts using precompiled toolchains alone would be nice.
> If we'd want to catch more problems, we could use that to also build things
> like libgcc, libstc++, compiler-rt, libc++ and maybe some more light but
> interesting external projects. Ideally using both GCC and LLVM precompiled
> toolchains.
>
>
> >
> > Wine uses self-hosted Gitlab instance, which solves the problem of
> > dependence on third party host. Having its own self-hosted
> > instance just
> > for mingw-w64 would probably be too much overhead for mingw-w64
> > project,
> > so if we decided to migrate, we'd need to pick one of externally
> > hosted
> > solutions.
> >
> >
> > BTW, SF mailing lists are especially not friendly for patches with
> > its
> > automatic footer messing inline patches and some attachments being
> > silently dropped, depending on their extensions.
> >
> >
> > That's configurable. If there's a mime type that needs adding, I can add it.
>
>
> How about allowing all MIME types? And for inline patches, can you disable
> all mail body modifications?
>
>
> >
> > As I pointed out previously, the use of auto tools by mingw-w64 doesn't
> > stop anyone from using whatever they want in their own project. If you're
> > building mingw-w64, you're building gcc anyway, so what difference does it
> > make? You need a GNU environment (that's the G in our name after all!), so
> > running a configure script isn't really an additional requirement. Whereas
> > cmake would absolutely be a new requirement.
>
>
> LLVM is well supported by mingw-w64 for years now (and doesn't take days to
> build). Cygwin/msys also don't fall into minimalist category, which takes 3
> of name letters (whatever that matters).
>
>
> Jacek
>
>
> _______________________________________________
> Mingw-w64-public mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
