From: Keith M. <kei...@us...> - 2010-08-17 17:27:37
|
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 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 The only issue I foresee is for those users who blatantly refuse to follow advice, and insist on shoving mingw-get into "C:\Program Files"; they will likely experience problems due to the space in the path name, but this will be no different to the present experience of such users. Any strong objections to this minor change in the recommended standard for the MSYS installation path? -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2010-08-18 03:00:38
|
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 installation: / /mingw/msys/1.0/ Well, I THINK that would be ok, and not cause problems -- but I couldn't swear to it. Have you tested this arrangement? Rebuilt msys components using it? Built mingw packages using it? 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. But using the %R nomenclature, every mingw installation would have (a) its own co-installed mingw-get, and its own msys subdir. Maybe 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. > 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. > The only issue I foresee is for those users who blatantly refuse to > follow advice, and insist on shoving mingw-get into "C:\Program Files"; > they will likely experience problems due to the space in the path name, > but this will be no different to the present experience of such users. > > 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. -- Chuck |
From: Earnie <ea...@us...> - 2010-08-18 13:57:37
|
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 installation: > > / > /mingw/msys/1.0/ > > Well, I THINK that would be ok, and not cause problems -- but I couldn't > swear to it. Have you tested this arrangement? Rebuilt msys components > using it? Built mingw packages using it? > Shouldn't be a problem. The shared spaces are named based on a hash of the path to msys-1.0.dll. MSYS doesn't care that it resides in c:/msys/1.0. I tested building both MSYS and MinGW packages with MSYS in different paths with multiple instances of MSYS running. > 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. > Well, their version is mostly a packaging difference with all-in-one features that mingw-64 wants as standard and maintained by one person. > 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. > > But using the %R nomenclature, every mingw installation would have (a) > its own co-installed mingw-get, and its own msys subdir. Maybe 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. > And it works well this way. >> 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. > I like this feature. It will help the user but will mingw-get raise warnings if the directory contains a space? >> The only issue I foresee is for those users who blatantly refuse to >> follow advice, and insist on shoving mingw-get into "C:\Program Files"; >> they will likely experience problems due to the space in the path name, >> but this will be no different to the present experience of such users. >> Right, IMO, mingw-get should raise a dialogue box warning with an OK to continue or CANCEL. >> 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. > As stated, I've tested MSYS with multiple directories. Earnie |
From: Keith M. <kei...@us...> - 2010-08-24 06:50:49
|
On Wednesday 18 August 2010 14:57:24 Earnie wrote: >>> 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. > > I like this feature. It will help the user but will mingw-get raise > warnings if the directory contains a space? The current CLI version won't, but it is a feature I have considered adding, before we get to beta. >>> The only issue I foresee is for those users who blatantly refuse >>> to follow advice, and insist on shoving mingw-get into "C:\Program >>> Files"; they will likely experience problems due to the space in >>> the path name, but this will be no different to the present >>> experience of such users. > > Right, IMO, mingw-get should raise a dialogue box warning with an OK > to continue or CANCEL. Such a dialogue box seems reasonable for the GUI variant; for the CLI, I'd prefer to just bail out, with a suitable diagnostic, but provide a (deliberately unwieldy) option, to let intransigent users override the abort, and continue regardless. -- Regards, Keith. |
From: Keith M. <kei...@us...> - 2010-08-18 19:17:31
|
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 > installation: > > / > /mingw/msys/1.0/ True, but... > 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. > Maybe > 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 installation records. > > 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. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2010-08-21 05:04:42
|
On 8/18/2010 3:17 PM, Keith Marshall wrote: > Sure, and the more of us testing it up-front, in varying use cases, the > better it will be. I've tested this configuration, as follows: (a) used mingw-get-alpha-2 to install mingw and msys-base, plus (b) copied in all the "non-finalized" msys-*.xml and mingw32-*.xml manifests, modified {msys|mingw32}-package-list.xml to activate them all, and then used mingw-get to install *everything*. (*) (c) using this installation, under the msys-dvlpr personality, I rebuilt msys-make-3.81-2, and ported msys-make-3.82-1 successfully. (**) (d) I didn't try to rebuild any *mingw* packages, because all of mine assume gcc-4.x but mingw-get doesn't know how to install that yet. So it would be a off-point ("testing the mingw-get-generated installation with %R/msys/1.0") to manually remove gcc3 and manually install gcc4... (*) This flushed out a number of typos in the non-finalized manifests. I fixed those, but didn't refine the affected manifests any further than the bare minimum necessary for this test. Note that because some of the mingw32-* packages require libgcc_s_dw2-1.dll, but that is available only with mingw-gcc-4.x, AND there is no entry in the current mingw32-base manifest for those versions, SO I had to temporarily comment out that requirement from some of the other mingw32-* manifests. I did not check in these temporary modifications. (**) I would have done more exhaustive testing, but porting Cesar's case-preserving patch, and the old cygwin patch, up to 3.82 -- and then fixing some thinko's wrt HAVE_DOS_PATHS that the upstream guys wandered into -- was rather challenging, and sucked up all the time I had allocated. And then some. -- Chuck |
From: Keith M. <kei...@us...> - 2010-08-24 06:51:00
|
On Saturday 21 August 2010 06:04:25 Charles Wilson wrote: > > Sure, and the more of us testing it up-front, in varying use cases, > > the better it will be. > > I've tested this configuration, [using %R to map sysroot prefix], > as follows: > > (a) used mingw-get-alpha-2 to install mingw and msys-base, plus > > (b) copied in all the "non-finalized" msys-*.xml and mingw32-*.xml > manifests, modified {msys|mingw32}-package-list.xml to activate them > all, and then used mingw-get to install *everything*. Thanks, Chuck. So, if I've understood correctly, you now have an installation where the sysroot prefix is defined by %R, i.e.: <sysroot subsystem="mingw32" path="%R" /> <sysroot subsystem="MSYS" path="%R/msys/1.0" /> > (c) using this installation, under the msys-dvlpr personality, I > rebuilt msys-make-3.81-2, and ported msys-make-3.82-1 successfully. This is promising news... > (d) I didn't try to rebuild any *mingw* packages, because all of mine > assume gcc-4.x but mingw-get doesn't know how to install that yet. So > it would be a off-point ("testing the mingw-get-generated > installation with %R/msys/1.0") to manually remove gcc3 and manually > install gcc4... I've done some preliminary tinkering with mingw32 manifests, with a view to accommodating *both* GCC-3 and GCC-4 installation, but I haven't yet come far enough to make them usable, and I am unlikely to have time to look at it again, much before mid-October. Notwithstanding, I'd like to push out mingw-get-alpha-3, to catch up with a few bug fixes, before the time I currently have available dries up completely; I'd like to include the adjustment to defaults.xml, (to map the default prefix from %R), as part of that release. (I haven't had time to perform exhaustive testing, but I have been using a mingw32 installation based on the existing GCC-3 package sets, installed by mingw-get-alpha-2 with %R as sysroot, and I haven't experienced any problem in routine use, so I am confident it is ready for a more public trial). -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2010-08-24 12:36:08
|
On 8/23/2010 11:05 AM, Keith Marshall wrote: > On Saturday 21 August 2010 06:04:25 Charles Wilson wrote: >> I've tested this configuration, [using %R to map sysroot prefix], > So, if I've understood correctly, you now have an installation where > the sysroot prefix is defined by %R, i.e.: > > <sysroot subsystem="mingw32" path="%R" /> > <sysroot subsystem="MSYS" path="%R/msys/1.0" /> Correct. >> (c) using this installation, under the msys-dvlpr personality, I >> rebuilt msys-make-3.81-2, and ported msys-make-3.82-1 successfully. > > This is promising news... Yep, it all seems to work. > I've done some preliminary tinkering with mingw32 manifests, with a > view to accommodating *both* GCC-3 and GCC-4 installation, but I haven't > yet come far enough to make them usable, What are the issues? Isn't this just a tuit problem for you|Cesar, or are there some technical difficulties? > and I am unlikely to have time > to look at it again, much before mid-October. Urgh. I had wondered why the pace of msys-*.xml updates had slowed. Would it help if I made the more mechanical changes (adding the vertical space, removing old versions, moving the license|source entries "up front", etc) and checked them in? > Notwithstanding, I'd like to push out mingw-get-alpha-3, to catch up > with a few bug fixes, before the time I currently have available dries > up completely; That would be good. > I'd like to include the adjustment to defaults.xml, (to > map the default prefix from %R), as part of that release. That would appear to be okay, based on my testing. > (I haven't > had time to perform exhaustive testing, but I have been using a mingw32 > installation based on the existing GCC-3 package sets, installed by > mingw-get-alpha-2 with %R as sysroot, and I haven't experienced any > problem in routine use, so I am confident it is ready for a more > public trial). Ack. -- Chuck |