Hi, Volker Grabsch wrote:
However, your idea was my first thought. But it is naive, and leads to bigger problems. Please take a look into the other threads about gnuwin32. Here's a short summary:
1) Debian isn't intended to produce cross compile libraries and/or compilers. Even as separate packages there is a good chance the majority of Debian developers don't want them beeing included into Debian.
Indeed, but your proposal does not solve that.What would be a real solution is to treat Win32 as a separate architecture, for which packages are always cross-compiled (at least in the beginning). People wishing to use the packages would use dpkg-cross to generate packages they can install on their development systems, and the packages would only be listed in the package list for the win32 arch, so no overhead for the ordinary user.
2) Convincing each Debian maintainer of these libs to include an extra binary target will be very hard, and the project as a whole may fail if only one of them doesn't like it.
Indeed, and this would only be a stopgap solution, but it's better than duplicating source packages.
3) It's much work for a Debian maintainer to keep track with the mingw32 builds. Some packages are prepared to produce lots of binaries compiled with different ./configure options. But most of them aren't, so it'll compilicate their debian/rules. Also, all these libs would need a build-dependency on the mingw32 package.
Indeed. I think in the long run a separate architecture would be preferable.
4) Versions: It's much better when the packages use the same version the GnuWin32 project uses. For instance, a Windows user will be able to get the DLLs (and other runtime stuff) from there, and is able to run my cross compiled EXE.
True; however especially the libraries you are talking about (libz, libpng, ...) had security issues in the past which required a bugfix release. Having to apply the fix to two different versions doubles the work of the security team.
In the long run, a lot of free software projects strive for their own obsolescence. If a porting patch is accepted by the upstream developers, and there are a few test cases in place to catch regressions, all that remains to be done is to protect the project from optimizations from excited Gentoo people. :-)
However, if there are differences between GnuWin32 and the Debian cross compiled packages, one may have to ship own DLL files of that library along with the program which is not desirable.
On Windows, you already are in DLL hell, so shipping all DLLs you need and installing them in your program directory is a wise thing to do.
5) Remember: You want to cross compile. So the Debian cross compiling should stay as close as possible to the packages one would normally use with MinGW under Windows.
True. The long term solution -- new architecture -- does that.
6) It add in general more work to more persons, than to simply use the GnuWin32 source packages as "upstream source". The GnuWin32 people *are* already a kind of "distribution" ... compared to Debian they are organized quite simple, but they already *do* have some kind of "package formats" and "package maintainers".
I figured we could just assimilate them. :-)
Why should I ask 10 or 20 busy Debian maintainer to duplicate work that is already done by the GnuWin32 project?
Because it is, in the long run, duplication of work already, and both projects could benefit from synergy (I feel dirty for saying that word now) effects.
If the patches are so intrusive that they break "regular" builds then they are not fit for production use IMO.
This is really the minor problem. But even if there were such patches, what about packages that compile *only* in MinGW? What's about packages which use the win32 API and never *intended* to be portable? Such libraries may be interesting, too.
Indeed, and nothing stops you from supplying those, as they are not in Debian already.
Simon
Attachment:
signature.asc
Description: OpenPGP digital signature