From: Keith M. <kei...@us...> - 2010-08-25 14:43:35
|
On 25/08/2010, Earnie <ea...@us...> wrote: > We can update the mingw.ini file that controls the current installer but > we need someone to maintain it. Maintaining it would require watching > for updates to packages, modifying the mingw.ini file and submitting the > changes to CVS. IIRC, that will not help. The current mingw.ini file relates to the package payload for GCC-3, as managed by MinGW-5.1.6. The knowledge of which packages are required, (quite distinct from which versions of those packages to deliver), is hard coded into mingw-5.1.6.exe; (mingw.ini only identifies the latest available versions of those pre-specified packages). The package architecture for GCC-4 is *very* different from that of GCC-3; specifying the GCC-4 package set in mingw.ini will serve only to break MinGW-5.1.6 -- utterly. It is this lack of adaptability, and scalability, which led to my original decision to abandon NSIS installers forever; (the exercise of adding the -dev/-dll combination for mingwrt, in place of the older single tarball, was just too painful -- it went from a working MinGW-5.1.4 to a comprehensively broken 5.1.5, before eventually getting it right for 5.1.6. This is an exercise in futility, which I have no intention of repeating. -- Regards, Keith. |
From: Jasper H. <jas...@gm...> - 2010-08-25 14:57:25
|
On Wed, Aug 25, 2010 at 3:46 PM, Keith Marshall wrote: Ah, there's your original reply, just a bit delayed... > IIRC, that will not help. The current mingw.ini file relates to the > package payload for GCC-3, as managed by MinGW-5.1.6. The knowledge of > which packages are required, (quite distinct from which versions of those > packages to deliver), is hard coded into mingw-5.1.6.exe; (mingw.ini only > identifies the latest available versions of those pre-specified packages). I see. So what about a simple installer based on a manual install which is archived and will be unarchived into a specified folder when run? (or perhaps just the archive itself without an installer) I would be willing to make it, if you are willing to support it. The only catch is that it's a pain to maintain it, so I will try do so when I happen to have time, but without making any promises or stating that I will continue to do so. I don't know how the mingw team developers feel about this, but I think even a slightly outdated installer is better than no installer at all. Jasper |
From: Earnie <ea...@us...> - 2010-08-25 15:20:20
|
Jasper Horn wrote: > On Wed, Aug 25, 2010 at 3:46 PM, Keith Marshall wrote: > > Ah, there's your original reply, just a bit delayed... > >> IIRC, that will not help. The current mingw.ini file relates to the >> package payload for GCC-3, as managed by MinGW-5.1.6. The knowledge of >> which packages are required, (quite distinct from which versions of those >> packages to deliver), is hard coded into mingw-5.1.6.exe; (mingw.ini only >> identifies the latest available versions of those pre-specified packages). > > I see. So what about a simple installer based on a manual install > which is archived and will be unarchived into a specified folder when > run? (or perhaps just the archive itself without an installer) > > I would be willing to make it, if you are willing to support it. The > only catch is that it's a pain to maintain it, so I will try do so > when I happen to have time, but without making any promises or stating > that I will continue to do so. I don't know how the mingw team > developers feel about this, but I think even a slightly outdated > installer is better than no installer at all. > That is no different than we have now. It would just be with new files that become outdated. The lack of (or absence of) maintainers is what has us in the sour pickle juice. So if you can't maintain it then we can't offer it because our time is just as limited as yours. -- Earnie -- http://www.for-my-kids.com P.S. A tip of the hat and a round of cheers with raised glass to KHMan for his acknowledgment and respect of our time. |
From: Jasper H. <jas...@gm...> - 2010-08-25 15:35:44
|
Earnie wrote: > That is no different than we have now. It may be no different to you, but I think it would be different to a large number of users. > It would just be with new files > that become outdated. The lack of (or absence of) maintainers is what > has us in the sour pickle juice. Yes, I understand how that's problematic. I would just like to provide some installer until mingw-get is able to pick up the task. As I said, I would prefer a slightly outdated installer of a hugely outdated one, but I can understand if that simply does not weigh up to the downside of having a non-maintained installer. Jasper |
From: a <mar...@go...> - 2010-08-25 16:40:46
|
Just as a side question: Does there exist a compiled installer of a newer version of GCC? For my current MinGW install I downloaded a .zip file from "somewhere" which had all (known) packages included. Sadly this is an a bit older version (but younger than GCC3). All I needed to do was unzip and to set the path variable. I tried to "build" the same zip file with newest version of GCC, but i couldn't get the individual parts working. I would like to help create this all in one exe, which is much simpler than any installer. To install: #1 unzip this file at your favourite location (without spaces) #2 add c:\mingw\bin, or your favourite location to the set variable #3... #4 unzip this helloworld.{c,cpp,java,..), and test the compiler. to uninstall: #1 delete the files #2 remove the path variable to minGW. Excuse my poor english. Markus. ----- Original Message ----- From: "Jasper Horn" <jas...@gm...> To: "Please only reply to" <min...@li...> Sent: Wednesday, August 25, 2010 5:35 PM Subject: Re: [Mingw-users] Updating the Installer (was: Stop on first error?) Earnie wrote: > That is no different than we have now. It may be no different to you, but I think it would be different to a large number of users. > It would just be with new files > that become outdated. The lack of (or absence of) maintainers is what > has us in the sour pickle juice. Yes, I understand how that's problematic. I would just like to provide some installer until mingw-get is able to pick up the task. As I said, I would prefer a slightly outdated installer of a hugely outdated one, but I can understand if that simply does not weigh up to the downside of having a non-maintained installer. Jasper ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d _______________________________________________ MinGW-users mailing list Min...@li... This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists. We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. _______________________________________________ You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users |
From: Earnie <ea...@us...> - 2010-08-25 15:07:36
|
Keith Marshall wrote: > On 25/08/2010, Earnie<ea...@us...> wrote: >> We can update the mingw.ini file that controls the current installer but >> we need someone to maintain it. Maintaining it would require watching >> for updates to packages, modifying the mingw.ini file and submitting the >> changes to CVS. > > IIRC, that will not help. The current mingw.ini file relates to the > package payload for GCC-3, as managed by MinGW-5.1.6. The knowledge of > which packages are required, (quite distinct from which versions of those > packages to deliver), is hard coded into mingw-5.1.6.exe; (mingw.ini only > identifies the latest available versions of those pre-specified packages). > I'll have to check it. I thought that updating the mingw.ini file was all that was needed and just adding unique identifying strings in for the packages. I thought that [current], [previous] and [candidate] were the only things required to remain consistent. > The package architecture for GCC-4 is *very* different from that of GCC-3; > specifying the GCC-4 package set in mingw.ini will serve only to break > MinGW-5.1.6 -- utterly. It is this lack of adaptability, and scalability, > which led to my original decision to abandon NSIS installers forever; (the > exercise of adding the -dev/-dll combination for mingwrt, in place of the > older single tarball, was just too painful -- it went from a working > MinGW-5.1.4 to a comprehensively broken 5.1.5, before eventually getting > it right for 5.1.6. This is an exercise in futility, which I have no > intention of repeating. > As an example in the [current] we have a package for runtime and a package for runtimeDLL. But for [previous] we have only runtime since the runtimeDLL package didn't exist. Did we need to modify the installer to add the runtimeDLL? I don't think so. -- Earnie -- http://www.for-my-kids.com |
From: Jasper H. <jas...@gm...> - 2010-08-25 15:24:34
|
Earnie wrote: > I'll have to check it. I thought that updating the mingw.ini file was > all that was needed and just adding unique identifying strings in for > the packages. I thought that [current], [previous] and [candidate] were > the only things required to remain consistent. Even if so, you will have to do a new NSIS-compile of the installer as the current installer doesn't support lzma, so just updating the .ini won't be enough in any case. Jasper |
From: Peter R. <p.r...@sh...> - 2010-08-25 15:28:59
|
On 25/08/2010 16:24, Jasper Horn wrote: > Earnie wrote: >> I'll have to check it. I thought that updating the mingw.ini file was >> all that was needed and just adding unique identifying strings in for >> the packages. I thought that [current], [previous] and [candidate] were >> the only things required to remain consistent. > Even if so, you will have to do a new NSIS-compile of the installer as > the current installer doesn't support lzma, so just updating the .ini > won't be enough in any case. > I'd have to check the code but off the top of my head, I think the existing installer does support lzma. I seem to remember a line in the code that specifies that... Peter |
From: Jasper H. <jas...@gm...> - 2010-08-25 15:42:58
|
Peter Rockett wrote: > I'd have to check the code but off the top of my head, I think the existing > installer does support lzma. I seem to remember a line in the code that > specifies that... That's possible, but my point was that it was not possible by just changing the mingw.ini file, which considerably increases the effort involved for whoever is doing this (unless he or she already has all the NSIS files set up). Jasper |
From: Peter R. <p.r...@sh...> - 2010-08-26 09:56:23
|
>> Earnie wrote: >>> I'll have to check it. I thought that updating the mingw.ini file was >>> all that was needed and just adding unique identifying strings in for >>> the packages. I thought that [current], [previous] and [candidate] >>> were >>> the only things required to remain consistent. >> Even if so, you will have to do a new NSIS-compile of the installer as >> the current installer doesn't support lzma, so just updating the .ini >> won't be enough in any case. >> > I'd have to check the code but off the top of my head, I think the > existing installer does support lzma. I seem to remember a line in the > code that specifies that... > > Peter I notice that the MinGW GUI installer has been removed from the SF site! Was this precipitated by yesterday's discussion of GUI vs. CLI installers? (I have a copy of the source files any way because I was going to look at them. ) Peter |
From: Earnie <ea...@us...> - 2010-08-26 11:14:48
|
Peter Rockett wrote: > >>> Earnie wrote: >>>> I'll have to check it. I thought that updating the mingw.ini file was >>>> all that was needed and just adding unique identifying strings in for >>>> the packages. I thought that [current], [previous] and [candidate] >>>> were >>>> the only things required to remain consistent. >>> Even if so, you will have to do a new NSIS-compile of the installer as >>> the current installer doesn't support lzma, so just updating the .ini >>> won't be enough in any case. >>> >> I'd have to check the code but off the top of my head, I think the >> existing installer does support lzma. I seem to remember a line in the >> code that specifies that... >> >> Peter > > I notice that the MinGW GUI installer has been removed from the SF site! > Was this precipitated by yesterday's discussion of GUI vs. CLI installers? > I do not know, I thought about hiding the package, but it was time for it to go away. > (I have a copy of the source files any way because I was going to look > at them. ) Feel free to keep doing so. But in light of Cesar's announcement will it be necessary? -- Earnie -- http://www.for-my-kids.com |
From: Peter R. <p.r...@sh...> - 2010-08-26 11:29:52
|
> Feel free to keep doing so. But in light of Cesar's announcement will it be necessary? > Possibly yes! Signed: GUI boy |
From: Earnie <ea...@us...> - 2010-08-26 11:44:52
|
Peter Rockett wrote: > >> Feel free to keep doing so. But in light of Cesar's announcement will it be necessary? >> > > Possibly yes! > 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. -- Earnie -- http://www.for-my-kids.com |
From: Peter R. <p.r...@sh...> - 2010-08-26 12:09:14
|
> Peter Rockett wrote: >>> Feel free to keep doing so. But in light of Cesar's announcement will it be necessary? >>> >> Possibly yes! >> > 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 have spent the morning looking at this and I think I am working around to the view that the existing NSIS code is a nightmare! I will probably offend the original author but IMHO the code has all the hallmarks of being chopped around during various revisions without the necessary restructuring needed to make it maintainable + the coding style is an anathema to me: loads of gotos despite NSIS providing structured things like if-then-else. Also, the NSIS scripting language only allows global variables and it's a case playing hunt the initialisation! IMHO this code is unmaintainable - it did its job in its day but most code reaches its sell-by date, I guess - so I agree with the decision to kill it off. Pity as I was hoping it would be a quick means of getting a GUI installer (for us thoughtless, CLI-hating types). Alas not. It would need a major rewrite IMO. Plan B: Since mingw-get appears to be making progress, a GUI installer spawning this would seem the best option. Also, need to reassess Nullsoft vs. InnoSetup. I am not impressed with the documentation with NSIS. Don't know if InnoSetup is any better? Peter |
From: Charles W. <cwi...@us...> - 2010-08-26 13:15:52
|
On 8/26/2010 8:09 AM, Peter Rockett wrote: > Plan B: Since mingw-get appears to be making progress, a GUI installer > spawning this would seem the best option. Also, need to reassess > Nullsoft vs. InnoSetup. I am not impressed with the documentation with > NSIS. Don't know if InnoSetup is any better? I think InnoSetup is both better, and better documented, than NSIS. I've used InnoSetup recently on the real job, so that might just be familiarity bias. YMMV. -- Chuck |
From: Earnie <ea...@us...> - 2010-08-26 14:59:17
|
Peter Rockett wrote: > > Plan B: Since mingw-get appears to be making progress, a GUI installer > spawning this would seem the best option. Also, need to reassess > Nullsoft vs. InnoSetup. I am not impressed with the documentation with > NSIS. Don't know if InnoSetup is any better? > And WIX may be better for this instance since it has an XML parser, is open source and is maintained by Microsoft. I've used both NSIS and InnoSetup and don't have a strong preference for either one. I think I remember NSIS as having a stronger following and better support for SF downloads. -- Earnie -- http://www.for-my-kids.com |
From: Charles W. <cwi...@us...> - 2010-08-26 15:23:53
|
On 8/26/2010 10:59 AM, Earnie wrote: > I think I > remember NSIS as having ... better support for SF > downloads. > Maybe so, but in this case we wouldn't actually be downloading anything via the *installer*. mingw-get would be bundled in the installer itself, and then mingw-get would be used to download everything else from sf. -- Chuck |
From: Keith M. <kei...@us...> - 2010-08-26 15:20:03
|
On 26/08/2010, Earnie <ea...@us...> 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 do *not* want a repetition of the current situation with MinGW-5.x, (where the original contributor walked away from it, almost as soon as the first update became necessary). If that happens again, I will bury the offending package without compunction. 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? Including optional add-ons? And, respecting the dependencies which each has on others? While retaining the flexibility and scalability to add new, perhaps previously unknown packages to the distributable inventory at short notice? That's the promise of mingw-get, (and from a download and install perspective it *already* delivers reasonably well); it is comparitively much easier to write a few lines of XML to describe a new package to mingw-get, than to recode an NSIS type installer script. -- Regards, Keith. |
From: Keith M. <kei...@us...> - 2010-08-26 12:24:08
|
>> I notice that the MinGW GUI installer has been removed from the SF site! To be strictly accurate, it has been hidden; SF content is NEVER removed. >> Was this precipitated by yesterday's discussion of GUI vs. CLI installers? > > I do not know, I thought about hiding the package, but it was time for > it to go away. I've been thinking about it for a while, but yes, yesterday's discussion was the clincher; I'd had enough of users telling me that *I* must update this package, which I'd previously declared "unmaintained", with no prospect for future updates, (in the absence of a volunteer maintainer). I really don't want continual bug reports relating to this dead package; I *do* want people to start using mingw-get, and to report issues with it. >> (I have a copy of the source files any way because I was going to look >> at them. ) They are still available in CVS, and will remain so indefinitely. > Feel free to keep doing so. But in light of Cesar's announcement will > it be necessary? Personally, I think not. I'd much rather see effort expended on bringing mingw-get up to par, in shortest possible time, (whether that be developer effort in formulating the XML, or user effort to help debug it). -- Regards, Keith. |
From: Keith M. <kei...@us...> - 2010-08-25 15:26:30
|
On 25/08/2010, Earnie <ea...@us...> wrote: > As an example in the [current] we have a package for runtime and a > package for runtimeDLL. But for [previous] we have only runtime since > the runtimeDLL package didn't exist. Did we need to modify the > installer to add the runtimeDLL? I don't think so. Yes, we did; (I *know* so, because I did it). It was a nightmare of an exercise, and I got it wrong first time, (although only by repeating an error already present, which for some reason didn't cause MinGW-5.1.4 to fail, but did break 5.1.5). -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2010-08-26 15:59:12
|
On 8/26/2010 11:19 AM, Keith Marshall wrote: > On 26/08/2010, Earnie<ear...@pu...> 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. [2] Maybe a nice project for somebody not-Keith would be rpm-like "-q" options: mingw-get -q -i gcc (print the <description> tag) mingw-get -q -l gcc (print the file manifest) mingw-get -q -f C:/some/file (print the package that provides) PS. Does mingw-get know how to unpack the problematic GNU tar archives Cesar mentioned, yet? -- Chuck |
From: Peter R. <p.r...@sh...> - 2010-08-26 16:43:23
|
On 26/08/2010 16:59, Charles Wilson wrote: > On 8/26/2010 11:19 AM, Keith Marshall wrote: >> On 26/08/2010, Earnie<ear...@pu...> 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 |
From: Dennis W. <den...@go...> - 2010-08-27 09:10:14
|
2010/8/26 Peter Rockett > 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? Granted, if regarded in isolation Fortran/Ada/ObjC downloads only range between 1/5 and 1/6 of the C downloads, so one might consider them as minorities (pretty big ones, though). Assuming, however, that many people download their pet-minority-language compiler together with at least the C compiler, those ratios shift somewhat (if *everybody* did so, 8K out of the 14K C downloads would stem from that minority). Yes, I use one of those minority languages. I stoppped using mingw because it required too much effort from me, but I will seriously reconsider that once mingw-get is out (@mingw-get dev's: sounds very promising so far, please keep up!) |
From: Peter R. <p.r...@sh...> - 2010-08-27 09:24:39
|
> 2010/8/26 Peter Rockett >> 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? > Granted, if regarded in isolation Fortran/Ada/ObjC downloads only > range between 1/5 and 1/6 of the C downloads, so one might consider > them as minorities (pretty big ones, though). > Assuming, however, that many people download their > pet-minority-language compiler together with at least the C compiler, > those ratios shift somewhat (if *everybody* did so, 8K out of the 14K > C downloads would stem from that minority). > Fair point! I was overlooking the fact that Ada et al. sit on top of the gcc core. The implication is that a lot of people are downloading C++ together with a minority language. (I forgot Pascal!) Peter |
From: Niklas H. <nik...@ti...> - 2010-08-27 10:31:12
|
Dennis Wassel wrote: > 2010/8/26 Peter Rockett >> 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? > > Granted, if regarded in isolation Fortran/Ada/ObjC downloads only > range between 1/5 and 1/6 of the C downloads, so one might consider > them as minorities (pretty big ones, though). > Assuming, however, that many people download their > pet-minority-language compiler together with at least the C compiler, > those ratios shift somewhat (if *everybody* did so, 8K out of the 14K > C downloads would stem from that minority). One reason for "minority-language" users to install the C compiler, in addition to their favourite language, is that it is often necessary to write C-code wrappers in order to call library functions that depend heavily on C #include files and macros in their interfaces. > Yes, I use one of those minority languages. So do I (Ada), and I use Ada with MinGW. I look forward to mingw-get, hoping it will make it easier to keep my MinGW installation up to date. -- Niklas Holsti Tidorum Ltd |