All,
this email will summarize my recent flurry of bugs, all coming from the
attempt to use the cross-compilation and Wine environments together.
The reason for this attempt is that I had to *develop* a port, not just
to compile it; therefore I had to test it. The fact that my particular
package runs itself at make time, so that (at the moment) it needs Wine
to compile, is secondary and would confuse the matter.
Secondarily, I wanted to make sure that the compilation works not just
for me, but also for people running native Windows, hence my installing
MSYS under Wine. While not something that I want to do day-to-day, this
is important to support MinGW as well as possible, and I wanted to reuse
as much of the Fedora cross-compilation install in order to achieve it.
Now, I can say my attempt succeeded but only after working around what
seemed to me like bugs. Maybe they are, maybe not; so, let's look at them.
513819: this is just the fact mingw's sys-root is *not* exported to
Wine. Nothing else, nothing more. It is totally unrelated from the
fact that Autoconf thinks it's not cross-compiling anymore. The
question is one, we can frame it in two ways:
1) Do we want this? If not, why?
2) Or as a meta-question: What relationship do we want
between Wine and the cross-compilation environment?
Isolation or cooperation? (Of course having one require
the other is a no-no).
A side note: one reason to do this, is to have a place to install
updates that would propagate automatically to all users' ~/.wine
directories. Again, maybe it's a good reason---maybe not.
513824: definitely a hack, but one that we cannot skip if we want the
cross-compilation environment to cooperate Wine. It is extremely stupid
to use touch instead of open, but glib does it; bummer. Fixing it
upstream will require years to propagate to packages. There are more
ways to fix this:
1) provide a minimal touch binary in mingw32-glib.
The problem is where to place it so that the Wine filesystem
sees it. Placing it in /mingw requires forward thinking
(because MSYS 1.0.11 can be installed in /mingw and we want
to avoid conflict with MSYS's touch.exe) and it would require
agreeing on fixing 513819 would be a good start, even though
probably it would not work for people that already have a
.wine in their home directories.
2) provide a minimal touch binary with Wine. Kind of sucks,
again because of people that already have a .wine in their
home directories. It also feels terribly out-of-place.
3) package MSYS and make mingw32-glib depend on it.
Overkill for people that do not require wine, but maybe
the simplest alternative.
4) find a way to define a config.site file (coordinating
with the Fedora setup.rpm maintainers) and disable glibtest
for MinGW (but also gtktest, etc.).
513825: I think there is consensus that mingw32-pkg-config should be
renamed or at least both names should be provided. The other
discussions in the bug are about:
1) mingw32-configure and mingw32-make. This can be ignored
as long as we agree that "./configure --host=i686-pc-mingw32 &&
make" should be a valid way to compile mingw32 packages.
2) Problems in the default RPM macros. This can be skipped,
except maybe for making -mms-bitfields the default in the
compiler. I can bring this upstream.
513825, reprise. There is another aspect of this bug. When Wine is
installed, Autoconf executes run-time testcases. This can be seen as a
bug, but it is also a feature---and for three reasons.
First, in most cases run-time testcases choose a conservative answer
when cross-compiling, so that allowing them would make for slimmer or
more efficient binaries.
Second, some run-time testcases may detect problems in usage or in the
existing installation, as is the case with the glib testcase in
bug 513825.
Third, they remove the need (for the casual user of the cross-compiler,
not for the packager) to define a config.cache or config.site file
in case the package does not support cross-compilation.
The question is obvious:
So, is it a bug or a feature?
513826: This is currently just an aesthetic problem, but if we decide to
export the sys-root to Wine it becomes worse, because then it would be
very very hard to install pkgconfig under Wine. I think that there is
no reason to make it so hard. Installing MinGW and MSYS themselves
under Wine is extremely easy, it works, and there are use cases for
doing it, even though it may seem a weird thing to do. If you want to
free developers from using Windows, allowing them to use MSYS is a good
thing.
That said, this bug requires touching all packages and the packaging
guidelines. So, it's something that maybe you would like to have, but
it's nevertheless likely to be postponed indefinitely. I would
understand that.
That's it; thanks for reading all this.
Paolo
_______________________________________________
fedora-mingw mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
