From: Aaron W. L. <aar...@aa...> - 2009-04-18 21:49:30
|
I would like the project administrators to be involved in this discussion. We need to reach a consensus on a philosophical and policy issue. The most important issue here is about what MinGW should be, going forward: a) remain minimal, with only a small set of packages for the toolchain and make b) expand to include many general-purpose packages and a system of prerequisites, in a similar manner to what Cygwin does. Note that I am not talking about MSYS here. MSYS is separate and its use is optional, and I think we would like it to remain that way. See below. Charles Wilson wrote: > Aaron W. LaFramboise wrote: >> Some possible changes: >> 1) Runtime DLLs could be split out of the gcc-xxx-bin packages into a >> gcc-xxx-dll package. This doubles the number of packages, as each >> language has one or more DLLs. > > Yes, but it should be done. That way our users can distribute a > pre-compiled program that requires (e.g.) libgcc_s_1.dll without also > having to tell /their/ users to download and install all of gcc; just > gcc-runtime-*-dll (or whatever). OK, but I will also need some broad consensus from others on mingw-dvlpr that this is the right thing to do. That is, that is, that getting an installation with all of the languages should require downloading 17 packages, not including binutils or libraries. > But...if we provide ONE separate -- and necessarily required -- dll > package, what is the rationale for shortcutting the others? The only reason I have is reduction in the number of packages and overall confusion of the manual installation process. Look at <http://www.mingw.org/wiki/HOWTO_Install_the_MinGW_GCC_Compiler_Suite>, with relatively simple manual install instructions. With all of these prerequisites, the procedure will become harder to explain and harder to understand. Please understand I'm not trying to avoid work. I'm only trying to keep this package from being difficult to install, and follow MinGW precedent and policy as I understand it. > Better to get all of the > surprises out of the way up front. I agree. Whatever arrangement we're going to come up with, I think it is best we decide on it now, at least as a matter of philosophy and policy. > Note #1: if we want to have gcc-core be a monolithic download with no > other requirements, then we should have all gcc executables link > statically against their dependencies. The advantage of linking > dynamically to those dependencies is it allows independent updates > without relinking It will be a very rare case that a bug in a GCC prerequisite will also cause a bug in the bundled version of GCC. > Note #2: Why did you need to roll your own libiconv DLL? Was there > something wrong with the existing > libiconv-1.11-1-bin.tar.bz2 > libiconv-1.11-1-dll.tar.bz2 > packages? As you mentioned elsewhere in your email, these are part of MSYS, which requires that MSYS is installed and being used to run GCC for GCC to work. One of these very few opinions that I have on any of this packaging stuff is that the MinGW tool chain should not depend on MSYS. I realize the 1.11 releases are old; if you really need 1.12 I > can respin those (and repackage according to the new conventions) for > you soonest... Actually, 1.13 was released last month so I could roll > that one for you instead, if you like. (There's one wrinkle here; > contact me offlist, Aaron). > > > HOWEVER: I still have a question about the appropriate path for > pre-compiled "native" (e.g. not MSYS) packages. Exactly. We've always had all native MinGW packages (non-MSYS) based in /mingw, with no dependencies outside of /mingw, and I think we should have a very good reason to change this. > So, I lean towards repackaging > > autoconf-4-1-bin.tar.bz2 > autoconf2.1-2.13-3-bin.tar.bz2 > autoconf2.5-2.61-1-bin.tar.bz2 > automake-3-1-bin.tar.bz2 > automake1.10-1.10-1-bin.tar.bz2 > automake1.9-1.9.6-2-bin.tar.bz2 > gettext-0.16.1-1-bin.tar.bz2 > gettext-0.16.1-1-dll.tar.bz2 > libiconv-1.11-1-bin.tar.bz2 > libiconv-1.11-1-dll.tar.bz2 > libtool1.5-1.5.25a-1-bin.tar.bz2 > libtool1.5-1.5.25a-1-dll.tar.bz2 > > to install into /mingw (and use the new naming scheme, and updating to > latest in each case, including libtool-2.2.x). My understanding is that you're proposing moving the autotools from MSYS to MinGW. A problem here is that these packages are dependent on MSYS, since they require a Bourne shell. |