On 27/02/13 00:05, Earnie Boyd wrote:
> On Tue, Feb 26, 2013 at 4:19 PM, Keith Marshall wrote:
>> Huh? There is no such thing as a default subsystem for mingw-get.
>> There is a default system-map, defined in profile.xml; it identifies the
>> subsystems which are to be managed. There is absolutely no reason why
>> those shouldn't include both mingw32 and mingw64 concurrently, with
>> separate and independent sysroot paths specified for each.
> Well, there certainly appears to be!
Appearances can be deceptive...
> If I choose gcc it defaults to mingw32 as it appears to the end
> user. And looking a profile.xml doesn't give me any hint as to how
> mingw32 is the default by appearance.
It gives you no hint, because your assumption is incorrect; there is no
default subsystem, (neither mingw32, nor any other).
> But currently it defaults to mingw32 as it appears to the user. How
> is that determined?
It doesn't *default* to *anything*; it honours the explicitly defined
alias, at the *package* specification level, which stipulates:
<package name="mingw32-gcc" alias="gcc ...">
and thus *explicitly instructs* mingw-get to interpret the package name
"gcc" as a reference to "mingw32-gcc". This is controlled by a package
maintainer; it certainly isn't the result of any heuristic assumption,
made by mingw-get, because mingw-get doesn't make such assumptions.
> Well, then let us discuss end user experience as it relates to
> installing software where MinGW.org is providing both 32bit and 64bit
> versions of software. Surely if the user is using a 64bit version of
> mingw-get he'll want it to appear to default to mingw64 instead of
Then we stop using the alias feature, in our package specifications, and
force users to be more verbosely specific when selecting packages. I
had reservations when I added aliases, (as an experiment), because they
could be easily abused; Chuck persuaded me to keep them.