On 26/08/2010 16:59, Charles Wilson wrote:
> On 8/26/2010 11:19 AM, Keith Marshall wrote:
>> On 26/08/2010, Earnie<earnie-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@...> wrote:
>> [re: provision of a GUI installer for MinGW]
>>> I don't know how Keith feels about this but from my POV if you maintain
>>> it we can allow you to upload to the project for download. But I want
>>> Keith's opinion first.
>> I'm perfectly amenable to hosting any *appropriate* package, which any user
>> cares to contribute, *provided* the contributor also offers a committment to
>> maintain that package throughout its useful lifetime.
> I expect the useful lifetime of ANY such GUI installer, *other* than an
> actual GUI version of mingw-get that uses the mingw-get backend library
> directly, to be very short.
>
>> My biggest concern, with *any* of these so-called wizard style GUI installer
>> frameworks, is that they lack scalability. There is considerably more to
>> MinGW than just GCC-4, (or GCC-3). Will any user, contributing such an
>> installer, do so in a format which can deliver *every* package available
>> from MinGW?
> I'm not as concerned about these issues, *in the short term*, because I
> think we're only discussing a stop-gap, until (a) mingw-get CUI and
> back-end library is more-or-less finalized, and (b) mingw-get GUI is
> alpha'ed. After that, deep-six all of these temporary measures.
>
> But, the simple fact is, we do need SOMETHING very simple that people
> can d/l and run, without editing xml files or running command line tools
> -- for two reasons. First, because it appears obvious, our user base
> simply will not use the CUI mingw-get in all of its configurable glory,
> at least not until some bare minimum environment is installed. They
> might then be convinced to use it to ADD to their existing install
> (especially once something like 'mingw-get --list-[un]installed' and
> other database query options are available [2]).
>
> Second, since (a) and (b) above are not going to happen until at least
> after October, that's a long time to wait with many dissatisfied users.
> The best of both worlds would be for our stop-gap measures to ALSO serve
> a second purpose: increase the testing base of mingw-get itself. That's
> why I proposed a simple GUI wrapper whose job is to:
>
> 1) install mingw-get in the user-selected location
> (note: using the %R mechanism, we don't even need to modify
> the profile.xml)
>
> 2) execute mingw-get itself with the desired arguments, driven
> by gui selections. For this stop-gap, I propose something VERY
> simple, without a lot of flexibility. Notwithstanding the
> capabilities of mingw-get to (once Cesar is done) install either
> gcc3 or gcc4, the stop-gap GUI installer will be only able to
> install one: gcc4-latest [1]. But, the user can select which
> major languages to install:
>
> MinGW GCC Version 4 C compiler: always installed
> MinGW GCC Version 4 C++ compiler: optional
> MinGW GCC Version 4 Fortran compiler: optional
> MinGW GCC Version 4 Objective C compiler: optional
> MinGW GCC Version 4 Ada compiler: optional
> MinGW Make: optional
> MSYS Base Package: optional
>
> Note that MSYS is not very granular. You either don't install it,
> or you get the entire msys-base meta package. Nothing in between,
> and no GUI mechanism to add other elements.
>
> So, if all elements are selected, the GUI would invoke mingw-get as:
> 'mingw-get gcc g++ gfortran objc ada make msys-base'
> and report status back to the user. It could then create a desktop
> shortcut for msys if it was installed, and update the system $PATH (most
> GUI installer toolkits allow this sort of thing fairly easily).
>
> And that's it. No other flexibility for this *stop gap* GUI installer.
> If users want to customize beyond that, well: they now have a fully
> configured mingw-get and can run that. But this should be enough to get
> them *basically* up and running.
>
> And because the above proposal is very simple, it's not a huge
> investment and can be deep-sixed without any heartburn once it is no
> longer needed. Furthermore, it serves to get the mingw-get CUI and
> backend library tested -- behind the scenes -- by a much larger user
> base. It would also be very simple to update if new versions of
> mingw-get CUI are released prior to (b) above -- but because it uses
> mingw-get, it needs NO updating if the elements (GCC, msys-base) are
> updated.
>
>
> [1] Fine, maybe we could also provide a second, completely separate
> "stop-gap" GUI installer, just like the first one, but that only
> installs mingw-gcc3-latest. I do NOT want to add the flexibility to a
> single GUI installer -- in this stop-gap iteration -- to "pick" either
> gcc3 or gcc4 (or worse, that allows the user to accidentally attempt to
> install both). KISS.
Chuck
Massive amount of good sense in this proposal! Exactly what is needed.
One minor suggestion to correct a frustrating shortcoming of the old
installer: add GDB as an option. IMO a toolchain without a debugger is a
bit like a car with optional steering wheel...
BTW: On the KISS theme, is there any evidence that Fortran, Ada and
Objective-C merit inclusion? From SF download stats, c = 14,427
downloads (in last ???), c++ = 12,422, fortran = 3,204, ada = 2,438,
objc = 2,995. Ada, fortran and objc would all seem to be minority sports?
Peter
|
