On 24/02/15 01:52, David Macek wrote: > On 23. 2. 2015 16:23, Allan McRae wrote: >> I need case two explained to me more. Why are you not using two PKGBUILDs? > > Basically, the situation with "mingw" packages (which contain native Windows > programs, while "msys2" packaged programs run on a POSIX emulation layer) is > kind of like multilib, but 32 bits are equally important as 64 bits. In > interest of de-duplication, there is always only one PKGBUILD per package, > for both mingw32 and mingw64. > > More detailed explanation: As you may know, 64-bit Windows are capable of > running 32-bit software by default, and a lot of existing software has not > been ported to 64 bits. For msys2, users are expected to install the variant > with same amount of bits as the host Windows and packages are chosen > according to the `arch` field. But since it's desirable to allow users to > install both bitness variants of mingw packages, these have `arch=any` and > are differentiated by a prefix in package name. As there is no correct or > default amount of bits, both package variants are built with the same > PKGBUILD using several envvars to switch between the variants. In order to > promote always building both variants, the makepkg-mingw wrapper invokes the > two builds in succession by default. > > I hope my explanation helps. > > Note that although I'm interested in a better way to organize these things, > it's unlikely anything will change in foreseeable future (probably not until > 32-bit Windows dies out). >
I dislike the idea of a non-empty $pkgdir at the start of packaging so am not convinced about this yet. Why would you not change where the $pkgdir symlink points as part of your script that does the needed changes and builds all the package variants? Allan
