Web lists-archives.com

Re: FW: [Mingw-msys] How do I recreate the MSYS distribution?




On Wed, 2007-10-24 at 18:56 -0400, Bill Hoffman wrote:
> Keith Marshall wrote:
> 
> >>> 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.
> 
> Just to be clear it is easy for both developers to change what the 
> default is for a package, and for end users to change the default if 
> they are building a package.

If that is so, why did the OP on your Cmake list make such a fuss?  Just
curious; I believe you, but it seems to me that this is a non-issue.

> The only questions here, is what should the default be for CMake when
> creating makefiles for msys.

What do you mean by "creating Makefiles for MSYS"?  As MSYS developers,
we don't want you to create Makefiles for MSYS, because we have no use
for them, and no one but an MSYS developer has any need for a Makefile
for MSYS.

If, OTOH, what you really mean is "what should the default be for a
Makefile for *MinGW*, suitable for use when building from the MSYS shell
environment?", then that's a different, but more reasonable question.
As a MinGW developer, my personal preference would be for /usr/local,
but the consensus view would be for /mingw.  From the perspective of a
GNU developer, targetting the Woe32 platform using the MinGW tools, the
preference is again sure to be /usr/local.

> My feeling from reading the web pages of msys leads me to think that
> the msys developers do not want msys to be something like cygwin ...

No, we don't.  Cygwin is about providing a fully functional POSIX
emulation layer for Woe32, with an ultimate goal of supporting POSIX
applications, using POSIX APIs, with zero source code changes.  MSYS is
about providing a Bourne shell compatible replacement for cmd.exe, and
the minimal set of additional tools required to facilitate porting of
applications which conform to the GNU Coding Standards.  It is *not*
about building native Woe32 applications, as Brandon mistakenly stated;
(he is confusing the roles of MinGW and MSYS).  It does *not* provide
any API, (beyond the limited API provided by bash for shell scripting).
It is about providing a replacement for the woefully deficient cmd.exe;
nothing more.

Of course, *users* of MSYS may choose to use it in whatever manner they
like.  They may well wish to build native Woe32 applications, but they
will need something more than just MSYS; for that we offer the GNU
Compiler Collection, in the form of MinGW.  However, there are other
perfectly legitimate uses, and ...

> where you build a bunch of posix applications that run out of msys
> directories.

...this is one of them.  With the proviso that those POSIX applications
must be ported to use native Woe32 APIs, since MSYS does not, and will
not provide any such thing as a POSIX API, this certainly does not
conflict in any way, with our objectives for MSYS.

> They want msys to be the minimal set of tools to allow the use of the 
> GNU tool chain.  However, it would seem that many projects that use msys 
> are using /usr/local as an install root.

Those that have their origins in GCS conforming sources, yes.  Those for
which we provide "mingwPORT"s favour /mingw, for reasons I've already
explained.

> Those projects are essentially extending the msys environment.

I disagree.  If I install, say, AFPL GhostScript, am I extending the
Windows environment?  Adding user supplied tools, in such a manner that
they may be run from my command line, is no different from installing
any regular application, which I can invoke from the Woe32 GUI.  This
simple action of installing extra user applications doesn't extend the
MSYS environment, in the sense you imply, i.e. adding features to MSYS
itself.  To do this, you have to be an MSYS developer, and you have to
use our "MSYS System Builder" tool kit, (a.k.a. msysDVLPR).

> With cygwin the answer is clear, applications should behave just like
> they do on linux (i.e. use /usr/local as the install root).  Those
> applications will also understand POSIX paths and mount points because
> they link to the cygwin runtime.  With MSYS, it is not so clear.

With MSYS, it is every bit as clear.  Any application which is installed
in /usr/local is expected to be a Woe32 *native* application.  It does
*not* need to understand MSYS POSIX paths, or MSYS mount points; indeed,
any application which does link to the MSYS runtime, to understand these
concepts, would be an MSYS component, (by definition), and it would be
wrong to install it anywhere other than /bin.  In MSYS, /usr/local is
for user added *native* Woe32 applications; we *encourage* users to add
their own programs there, or in /mingw; nothing which is added in either
of these locations becomes any part of MSYS itself.

> Let's say someone was going to write a makefile to compile a program 
> with msys not using autotools, what would be the recommended location 
> for the install prefix?

As a GNU developer, I'd say /usr/local.  As a MinGW developer, and MSYS
contributor, from my personal POV, I'd still say /usr/local.  As a MinGW
and MSYS Project Administrator, I'd have to bow to the current consensus
of opinion of my fellow developers, and say /mingw.

Oh, and just to complete the picture, as an MSYS "power user", I'd also
say /usr/local for choice, but, sympathetic to the "novice user", and to
the MinGW developer consensus viewpoint, I'd not object to /mingw. [1]

Regards,
Keith.

[1] Unofficially, I'd say "why not just do a `mkdir -p /usr/local', and
install there anyway"?  The consensus viewpoint has always puzzled me,
in this respect--I really don't like polluting the /mingw tree, with
non-MinGW user added applications, but I can understand and accept the
arguments in favour of doing it that way.


-------------------------------------------------------------------------
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
Mingw-msys@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/mingw-msys