RE: FW: [Mingw-msys] How do I recreate the MSYS distribution?
On Wed, 2007-10-24 at 14:55 -0400, Brandon Van Every wrote:
> On 10/24/07, Keith Marshall <keithmarshall@xxxxxxxxxxxxxxxxxxxxx> wrote:
> > On Tue, 2007-10-23 at 10:33 -0400, Bill Hoffman wrote:
> > > So, the default install location for CMake on msys is currently the
> > > "program files" directory as it is for the microsoft and borland
> > > compilers.
> > That seems a rather draconian restriction; the installation directory
> > can be anywhere the user wants it to be, and the standard supported by
> > MSYS is that each source package sets its own default.
> What restriction? He said "the default" install location is
> %ProgramFiles%. It is easy for the end user to specify something
> else. It isn't difficult for the project to specify something else.
Well, that isn't the impression I obtained, when I read through the
thread on the Cmake list; however, since I don't use Cmake, I'll take
your word for it.
> The question is, what should be the default when neither the user nor
> the project has specified anything? The choices are:
> - have a default install location
> - issue an error and don't allow any installation
> I don't see any advantage to the latter.
Neither do I.
> So we are merely discussing a default of %ProgramFiles%
> vs. /usr/local. Current thinking is that MSYS is for developing
> native Windows apps, therefore use %ProgramFiles%.
No MSYS developer is likely to recommend %ProgramFiles%; typically that
will resolve to something with spaces in the directory names, and we've
seen far too many problems which can be directly attributed to that
asinine practice, reported on our mailing lists and our bug trackers.
> > which relies not only on the MSYS sh.exe being the first sh.exe found in
> > the PATH, but also on /usr/local existing within the MSYS virtual file
> > system, (it doesn't, in a standard MSYS installation, unless the user
> > chooses to explicitly create it).
> Which also makes %ProgramFiles% the path of least resistance. It
> exists on any Windows system that isn't broken.
No. The path of least resistance for a typical MSYS installation, which
normally includes a parallel MinGW installation, is /mingw.
> > > The big question is should it be done? The strongest argument for
> > > using /usr/local as the install location, is that autotools based
> > > projects use /usr/local as the default install location.
> > It has nothing to do with the autotools, per se; the GNU Coding
> > Standards require it, and it is the default for many Open Source
> > projects, irrespective of whether they use autotools or not.
> Heh, following the GNU Coding Standards for native Windows development
> is like asking Microsoft to decide the fate of the Free Software
> Foundation. :-)
I'm not saying we should slavishly follow them; it's simply because MSYS
is good for porting projects which do follow them, that we see that as
the default in so many of the packages we work with.
(FTR, we do adopt the GCS style for our ChangeLogs, but little else).
> > > I would much appreciate the view point of an msys developer.
> > It depends which MSYS developer you ask. Some will say that the default
> > should be whatever /mingw maps to, and that seems to be the consensus of
> > opinion amongst the active developers; it is what we set as default, in
> > the supplementary source packages we provide, for building as native
> > programs, for use with MinGW or with MSYS. Personally, I prefer to use
> > /usr/local, reserving /mingw for the GCC tool chain only, and I override
> > the /mingw default, when I build such packages for my own use.
> Pollute C:\MinGW? Hadn't thought of that possibility.
It's not something I particularly like, which is why my own preference
is for /usr/local; it is, however, convenient for novice users, who will
normally have only a basic MSYS + MinGW installation--we know /mingw is
going to exist, and /mingw/bin will be in $PATH, so we exploit that in
our standard packages.
> Seems to assume that we're spitting out a Unixy pile of \bin \doc \man
> \lib directories and so forth.
Yes, most of the packages we offer are organised precisely this way.
> Native Windows developers don't do that. Everything for a given app
> belongs under 1 directory.
And each lives in splendid isolation, with no knowledge of other
installed apps, little if any co-operation between any two, and an
almighty mess of an overlong $PATH, to make it all hang together.
> There's no reason to put a native Windows app under C:\MinGW
> \MyAppDirectory, it's not going to get added into any paths under
No, it isn't; but if everything is accessed from /mingw/bin, or my
preferred /usr/local/bin, then there is no need for...
> If they want search paths to their app they're going to have to
> specify 'em manually. Doesn't matter whether they specify C:\MinGW
> \MyAppDirectory or C:\Program Files\MyAppDirectory.
...this sort of PATH proliferation. I'm not saying either approach is
right or wrong; they are simply different development models. MinGW is
"Minimalist GNU for Windows"; as such, it follows the Unixy GNU model,
and IMO tools intended to co-operate with MinGW or MSYS should follow
the same model.
> Meanwhile, the former pollutes /mingw ...
Which is why I personally prefer /usr/local.
> and the latter is canonical native Windows development, doesn't
> pollute anything.
But it does lead to PATH proliferation, which I intensely dislike.
> It's becoming clear to me that this debate is about Unixy tools.
> CMake is not about Unixy tools per se, it is about cross-platform
> development. I guess the remaining question is whether, in practice,
> just about every developer out there using MSYS is doing Unixy tools
I can't speak for the others, but my primary development platform is
GNU/Linux; I have absolutely no interest in developing exclusively for
Woe32. I use MinGW and MSYS as a vehicle for porting Unixy tools to
Woe32; if my employer didn't shortsightedly force me to use Woe32, I
wouldn't bother, for I use these Unixy tools almost exclusively, to
fulfil my job function.
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
Mingw-msys mailing list