On Fri, Feb 20, 2026 at 11:06:50PM +0000, Jonathan Wakely wrote: > 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
Looking now ... > > > 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? There's likely no good reason at all. My opinion (in general) is that mingw packages should be as close as possible -- in version & features -- to the regular Fedora packages, unless there is some exception reason for the difference. Windows is perfectly able to deal with multi-threaded code so there seems no reason to build the single-threaded version. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html -- _______________________________________________ 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
