On Wednesday 18 August 2010 04:00:14 Charles Wilson wrote:
> On 8/17/2010 11:53 AM, Keith Marshall wrote:
> > For the next mingw-get release, I'm considering setting
> > defaults.xml up with installation paths:
> > <sysroot subsystem="mingw32" path="%R" />
> > <sysroot subsystem="MSYS" path="%R/msys/1.0" />
> > where the %R macro will expand to the effective root directory path
> > of the mingw-get installation itself. Thus, if the user follows
> > our advice and unzips mingw-get into C:\MinGW, then mingw32
> > applications will be installed into C:\MinGW, (as is our current
> > recommendation), while MSYS will be installed into
> > C:\MinGW\msys\1.0, (a minor departure from our current
> > recommendation, but still acceptable IMO), without requiring any
> > user intervention to set up profile.xml
> Hmm. So there will be two different posix paths for the msys
> Well, I THINK that would be ok, and not cause problems -- but I
> couldn't swear to it.
...this is no different from the loopback mount concept, common on *nix,
and which we already emulate with /usr --> /, (so in fact, we would
have *three* POSIX paths for the MSYS root); other than a few requests
from naive users, who seem to think they might gain some advantage from
segregating / and /usr, and abusing their conventional purposes, do we
have any problems attributable to this existing loopback?
> Have you tested this arrangement?
Not exhaustively, but it is how I've set things up on the new Vista box
I have been given at work, a fortnight ago, and it has worked well for
me so far.
> Rebuilt msys components using it?
No, neither will I, because that's outside of my workplace remit, and I
don't use Windows otherwise; that's why I'm asking here, rather than
just doing it: to give you guys an advance opportunity to check its
viability for your workflows.
> Built mingw packages using it?
Not yet, but I will likely have a go at building groff, before long,
because that's one package I do need to use at work.
> Assuming there are no issues, I think its a good idea when mingw-get
> is used for its default, intended purpose: installing mingw and msys.
> Random thoughts:
> However, the design of mingw-get is deliberately generic; suppose the
> mingw64 guys wanted to use our installer. I think them doing that
> would be a good idea; it would cut down on duplication of
> maintainence of the msys stuff (they have their own version; it'd be
> better if that effort was redirected here IMO) -- and perhaps also
> encourage them to assist with ongoing development of mingw-get, which
> would be welcome. See, in this vision, they would ship a profile.xml
> that pointed to their mingw64-32bit or mingw64-64bit compiler, but
> also to OUR msys.
> Now, if *I* were doing it, I'd want ONE msys installation shared
> between all of my mingw.org (4.4.x, 4.5.x, 4.6.x...) installations
> and all of my mingw64.sf installations. I'd monkey with /etc/fstab
> to "switch" between the gcc's. But then, I'm weird.
Then I guess most of us are :-) I used to do much the same, on my old
Win2K box, (which went away, when I acquired the Vista box). But, here
we are getting into advanced usage; I'd expect you to adapt profile.xml
to accommodate your preferred configuration(s), (using the alternative
system-map concept, when I eventually provide a mechanism for using any
map other than the default).
> But using the %R nomenclature, every mingw installation would have
> (a) its own co-installed mingw-get, and its own msys subdir.
At present, irrespective of whether we use %R or explicit nomenclature,
each separate mingw-get installation can support at most one sysroot
path for each managed subsystem; eventually, alternate system-maps
could circumvent that limitation.
> that's actually what most users would prefer; they could then launch
> the "mingw64-64bit msys shell" and a separate "mingw.org msys shell"
> simultaneously. Since msys is nice and minimal, the duplication is
> not a huge concern -- and the mingw-gets should help keep everything
> (separately) up to date.
That's certainly a plausible scenario, but even today, it would be
possible to install two separate mingw-gets, perhaps with distinct
sysroots for mingw32, while sharing a common MSYS installation, (or
vice-versa). It would be undesirable, however, because it would be
impossible to synchronise state between two separate sets of
> > Alternatively, for a user who unzips mingw-get to d:\foo, mingw32
> > applications will be installed in d:\foo, and MSYS in
> > d:\foo\msys\1.0, again without any user intervention to set up
> > profile.xml
> Right. That's a huge benefit. Simpler is good.
Yes, and it would be a benefit realised primarily by those who don't
want to be bothered with editing profile.xml, and are happy to accept
defaults which are based solely on their initial choice of installation
directory for mingw-get itself. Users with more advanced needs would
still have the option to edit profile.xml, and specify any explicit
paths they might prefer.
> > Any strong objections to this minor change in the recommended
> > standard for the MSYS installation path?
> Not as long as this configuration has been tested in some reasonable
> use cases.
Sure, and the more of us testing it up-front, in varying use cases, the
better it will be.