On Fri, 20 Feb 2026 at 23:02, Jonathan Wakely <[email protected]> wrote:
>
> On Fri, 20 Feb 2026 at 22:57, Jonathan Wakely <[email protected]> wrote:
> >
> > On Fri, 20 Feb 2026 at 22:01, Jonathan Wakely <[email protected]> wrote:
> > >
> > > On Fri, 20 Feb 2026 at 21:56, Jonathan Wakely <[email protected]> wrote:
> > > >
> > > > On Fri, 20 Feb 2026 at 21:36, Richard W.M. Jones <[email protected]> 
> > > > wrote:
> > > > >
> > > > > On Fri, Feb 20, 2026 at 09:26:29PM +0000, Jonathan Wakely wrote:
> > > > > > On Fri, 20 Feb 2026 at 21:08, Richard W.M. Jones 
> > > > > > <[email protected]> wrote:
> > > > > > >
> > > > > > > On Fri, Feb 20, 2026 at 02:24:57PM -0500, Neal Gompa wrote:
> > > > > > > > I could try to look into updating this, but I'll need some help 
> > > > > > > > to
> > > > > > > > figure out how to get all the revdeps rebuilt and such. Do we 
> > > > > > > > want to
> > > > > > > > try to merge this into the main boost spec? Or keep it separate?
> > > > > > >
> > > > > > > It'd be ideal to merge it since it reduces long term maintenance, 
> > > > > > > but
> > > > > > > that's going to require both the cooperation and the 
> > > > > > > understanding of
> > > > > > > Fedora's boost maintainer.
> > > > > >
> > > > > > What's the context here? Merge what?
> > > > >
> > > > > At the moment, nothing more than discussion.
> > > > >
> > > > > For some packages we've combined the mingw-* [Windows] package with
> > > > > the main package (so the mingw-* package is built as a subpackage from
> > > > > the same sources).  An example is worth a 1000 words, so:
> > > > >
> > > > > https://src.fedoraproject.org/rpms/gnutls/blob/rawhide/f/gnutls.spec
> > > > > (look for the 'with mingw' sections).
> > > > >
> > > > > Advantages are that the packages always stay in sync, and there's
> > > > > less maintenance (at least, in total).
> > > > >
> > > > > Disadvantages is this puts extra burden on the main maintainer.  For
> > > > > some packages it might be a very great extra burden, for others not so
> > > > > much.  It also makes the spec file a lot more complicated.
> > > > >
> > > > > Since the mingw-boost package has fallen some way behind the main
> > > > > package, that's what we were discussing.
> > > >
> > > > I see, thanks.
> > > >
> > > > I have no objection in principle, but the boost package is a major
> > > > pain that always requires considerable TLC every time we update it.
> > > > The upstream project only supports building with Boost's own 'b2'
> > > > build system, which I cannot describe using polite words.
> > > >
> > > > The mingw-boost.spec file looks much simpler, as it doesn't build the
> > > > MPI parts (which need to be built twice, once for openmpi and once for
> > > > MPICH). But that means that none of the commands in the %build section
> > > > are common to the ones in boost.spec. Merging it in would probably
> > > > result in the entire %build section being %if ... %else ... %endif
> > > > where the normal build and the mingw build are entirely separate. And
> > > > the same for %install. I'm not sure how much benefit that would
> > > > actually bring. At least the list of patches and %prep would be
> > > > common, but maybe not much else? The %files look completely disjoint.
> > >
> > > And the main package builds several dozen subpackages
> > > (boost-filesystem, boost-thread, boost-devel, ...) whereas the
> > > mingw-boost.spec just builds four subpackages, with no overlap.
> > >
> > > So it really does look like there would be two entirely separate spec
> > > files intermingled into one file, with large %if blocks everywhere,
> > > and approximately 100 lines that are common to both builds.
> > > boost.spec is over 1300 lines (excluding the %changelog) and it looks
> > > like another 500 or so would be added from mingw-boost.spec, so we'd
> > > have about 2000 lines in total, with only 5% shared by the two worlds.
> >
> > Actually, it might not be tooooo painful:
> > https://src.fedoraproject.org/fork/jwakely/rpms/boost/diff/rawhide..mingw
> >
> > One of the mingw-specific patches no longer applies to boost-1.90.0
> > (and would completely break the min-mingw native package builds
> > anyway) so that needs addressing by somebody.
> >
> > I've only tested 'fedpkg prep' so far, so I have no idea if the rest
> > of it works.
>
> The %files will obviously fail, because the list of libs in
> boost-1.90.0 is very different. But is there any reason that the mingw
> %files don't just use wildcards? It looks like that would be vastly
> simpler. I've pushed a second commit to the branch that does that.

Is there a good reason that the mingw packages build both
single-threaded and multi-threaded variants of every boost lib? i.e.
using  threading=single,multi in the build options?

That doubles the size of the RPMs, and doubles the time for the build.
I think we stopped doing that for the native packages in 2013. Are
there advantages to the non-multithreaded libs for mingw?

-- 
_______________________________________________
mingw mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it: 
https://forge.fedoraproject.org/infra/tickets/issues/new

Reply via email to