Neal Gompa schrieb:
On Mon, Dec 9, 2019 at 7:21 AM Ludwig Nussel
wrote: Trying to figure out a way to use multibuild for mingw packages. The challenge there is that almost all packages need to be built for 32bit as well as 64bit Windows. So currently we have mingw32-foo and mingw64-foo packages. With exactly identical spec files except for s/mingw64/mingw32/ and vice versa. So sounds like a job for multibuild with flavors mingw32 and mingw64 to produce those packages from a common mingw-foo package. Now there are also packages that have multiple spec files though like gcc and pkgconf. Looks like that case was somehow forseen for multibuild as there are 'flavor' and 'package' tags. In the end both are treated the same though and end up as @BUILD_FLAVOR@ in spec files.
Are there any plans to change that? So one could write something like
<multibuild> <flavor>mingw64</flavor> <flavor>mingw32</flavor> <package>mingw-gcc</package> <package>mingw-cross-gcc</package> <package>mingw-cross-gcc-bootstrap</package> </multibuild>
to produce six packages?
Short of that would it work to have both links and multibuild? Ie links according to spec file names and only mingw flavors?
Why not just define the flavors in the spec itself? It seems crazy to try to use features like multibuild for this.
It's not difficult, see: https://src.fedoraproject.org/rpms/mingw-openal-soft/blob/master/f/mingw-ope...
Alternatively, something like what we do for Python and Ruby builds could do the trick here (macros that expand to flavors).
I am aware of those methods. Looks like it is a matter of choosing your favorite way of getting tortured. The price of those is a lot of (black) magic with macros. Tricky to implement and hard to debug. Compared to that, multibuild looks rather straight forward to me. That's why I'm exploring it first. Requires some clarification of where multibuild leads to though. Dominique also filed an issue for that: https://github.com/openSUSE/open-build-service/issues/8847 When thinking about it I wonder if a _multibuild file is needed at all. The spec file selection could be solved with classical links just fine. Maybe with some more code in OBS to create the requires packages automatically on request accept, like external scripts do (or did?) for staging. The flavors with the @BUILD_FLAVOR@ substitution feels like it should be done in a more rpmish way. Thinking of extending bcond, eg assuming we have %bcond_with bootstrap %bcond_with small %bcond_with full [...] %if %{with bootstrap} foo %else bar %endif One could come up with a macro to replace the %bcond_with lines, let's say %{bcond_xor bootstrap small full} So that bcond_xor would have to make sure one of the options is actually selected and fail rpmbuild if not. OBS would then have to parse the %bcond_xor macro in the spec to generate those virtual packages with colon separated flavor we know from multibuild today. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org