On Tuesday 20 July 2010 17:35:57 Fredric Johansson wrote:
> On Tue, Jul 20, 2010 at 5:11 PM, Charles Wilson
> <cwilso11@...> wrote:
> > On 7/20/2010 7:48 AM, Earnie wrote:
> >> WTH did you not just help with the installer that is being
> >> developed officially instead of yet another one off? If you have
> >> time to code your own you surely have time to help with mingw-get.
> > That not fair, Earnie.
No, it is not fair. However...
> > The reason the OP -- or anybody else --
> > hasn't helped with mingw-get, is because NO ONE can help with
> > mingw-get. Unless something has changed, Keith still is not ready
> > to accept outside patches (he actually said that, on this list, at
> > some point in the past and AFAIK that still stands).
I said that at the time when John E. had volunteered to develop
mingw-get; he had stated that he felt that he needed to do some more
work on the CVS sources, to get them to a fit state for others to be
able to interpret, before they could likely contribute effectively.
Since I have taken the lead on the development, this is no longer the
case, but I guess I neglected to revoke the prior statement; if anyone
does feel they would like to help, I will gratefully accept patches.
> > Hell, I pay pretty close attention, and it still took me three
> > read-thrus and four attempts to use mingw-get correctly.
Which tells me that the release notes I've provided don't really provide
sufficient explanation. That's an area where I really could use some
help; what may seem crystal clear to me, as developer, may not be so
meaningful to users, who are less familiar with the code.
> I can only agree with this. It didn't have any help option when I
> tried it and looking online for how to use it is a no go for an
Adding a help option is on my TO DO list; it isn't my primary focus at
the moment, but I think it must be considered a prerequisite for moving
from alpha to beta release status.
> > Plus, mingw-get can't be used to install msys yet.
As of Monday this week, it can install "msys-tiny" -- a working bash
shell environment, with a carefully selected subset of GNU coreutils --
but that still falls some way short of what most users will expect of
"msys-base". Getting from "msys-tiny" to "msys-base" is a relatively
simple matter of validating, testing and uploading (to FRS) additional
XML distribution manifests, which Chuck has already provided, but even
that takes some time and effort; it doesn't happen overnight.
> > However, if somebody wanted to install just MinGW, then mingw-get
> > CAN be used for that purpose. What's missing is:
> > 1) An installer-for-the-installer. Yes, people could
> > a) d/l
> > http://sourceforge.net/downloads/mingw/Automated%20MinGW%20Installe
> > b) unzip it
> > c) read the release notes and realize they must copy
> > INSTALLER_DIR/var/lib/mingw-get/data/defaults.xml
> > to INSTALLER_DIR/var/lib/mingw-get/data/profile.xml
> > and, perhaps, open it in a text editor and modify the
> > contents in order to choose where they want to actually install
> > MinGW itself
> > d) run INSTALLER_DIR/bin/mingw-get with the appropriate
> > arguments
> > But that's really asking a lot. Folks want a download-and-run,
> > point-n-click installer -- at least, at first, to get them up and
> > running.
> I agree here too.
> But even if a user tries mingw-get and get it to work it still only
> delivers gcc 3.4.5 instead of 4.x unless I have missed something.
You haven't missed anything. I've started preparing XML manifests to
move towards GCC-4.5 delivery, but once again, these require finite
time to complete; they aren't yet ready, even to a point where they
could be considered viable as a replacement for the GCC-3.4.5 versions
which are currently provided.
> I looked at the NSIS installer long ago so I don't remember how hard
> it would have been to modify the installer to install 4.x as only
> option or as an either 4.x or 3.4.5 installer. A few hours work to
> keep the users content until mingw-get is done.
Well, I looked into the viability of this when we split mingwrt into
separate -dll and -dev components. That ostensibly trivial change took
us from MinGW-5.1.4 through MinGW-5.1.5, (which turned out to be VERY
unreliable), to MinGW-5.1.6. The effort required to achieve even that
minor change was sufficient to convince me that NSIS has no future as a
delivery agent for MinGW; if I never have to look into NSIS scripting
again, it will be too soon.
> > So, we *could* generate a very simple InnoSetup or NSIS installer
> > that does the four steps above, and modifies the
> > INSTALLER_DIR/var/lib/mingw-get/data/profile.xml as appropriate
> > based on a wizard page in the installer.
We could, but...
> > This is probably a Saturday afternoon project.
...for someone other than me. (And someone who is willing to commit to
maintaining it, for the foreseeable future -- simply contributing and
walking away, as the contributor of MinGW-5.1.x did, isn't going to win
> > 2) Documentation, documentation, documentation. The steps above
> > should be validated/verified and docu'ed somewhere PROMINENTLY on
> > the wiki.
Yes, this is necessary. It is something that the users really can help
with; if it is left to me alone, it will likely take some time, and may
end up being too terse to be genuinely useful.
> > And we should put the click-once installer from step #1
> > as the main d/l on the mingw sf page.
Yes, we should -- when someone cares to contribute it.
> > But all of THAT presupposes that mingw-get moves to at least beta
> > stage. People are scared of alphas.
I could call it beta-1 tomorrow; the functionality already delivered is
probably robust enough to merit that, but it would be incomplete. I
think that change of designation should be deferred until:
* a "help" option is provided.
* a mechanism for listing available packages, (those available to
install, and those already installed), has been implemented.
and perhaps, but maybe not necessarily:
* the ability to remove installed packages has been added.