On Tue, Jun 16, 2009 at 04:27:13PM +0200, Kevin Kofler wrote: > That sounds like a bad plan. The targets don't have any more in common than > they do with the native version. It makes sense to keep them in separate > SRPMs [..]
No, I disagree. Entering hypothetical territory, _if_ it turns out we are allowed to distribute the Mac OS X SDK :-) As a developers, I would want an environment where I can build my program for all four [inc. native] targets very easily. It would be simpler if, for example, the same, identical version of Gtk was on all four targets, because that would reduce any potential incompatibilities and differences in features. On the Fedora side of things, having one library build from a single SRPM into all targets reduces management overhead. For example, we only build each library once and we don't need to track differences in versions between SRPMs. Now in the original email I did point out cases where you would want separate SRPMs. Quoting myself: The only time I could see it making sense to build from different SRPMS would be if either (a) different people needed to manage the ports, or (b) for some reason we had to use a different upstream on one of the platforms. I think those are still the only valid exceptions. > [..] for the same reason it makes sense to keep them separate from the native > package. In the original proposal for the Fedora MinGW project, we discussed building mingw as sub-RPMs of the native RPMs. The reasons this was rejected was essentially point (a) above - ie. different people need to manage them. > I don't see a problem with building mingw64-* from mingw32-* SRPMs or the > opposite, as that's the same target OS, just on different hardware platforms, > but building darwinx-* from the same SRPM as mingw* sounds very artificial to > me. They're likely to need different patches, dependencies etc. Point taken, but I'd hope that we can push upstreams so that they accept any patches required to build on all platforms. A good thing about the Fedora MinGW project is that we have effectively provided a way for upstreams to routinely test and build their libraries for Windows, which many upstreams were never able to do before. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 75 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora _______________________________________________ fedora-mingw mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
