Re: FW: [Mingw-msys] How do I recreate the MSYS distribution?
On Thu, 2007-10-25 at 09:31 -0400, Brandon Van Every wrote:
> Right, the question is whether people are meant to install "under
> MSYS" or *outside of* MSYS.
Wrong. The question is how do you want to use MSYS? If you are using
it as a cmd.exe replacement, which is its intended purpose, and you are
developing a *native* CLI tool, you *should* be installing it in the
directory mapped to either /usr/local or /mingw.
> A Windows native developer views MSYS as a throwaway. Once you've
> accomplished your build, you're not going to use MSYS at all.
Why? MSYS isn't a build tool; it is a cmd.exe replacement. If you
prefer it to cmd.exe, you use it; if you prefer cmd.exe, you use that,
and you don't need MSYS at all. However, you then have a much bigger
hill to climb, if the build system for your package needs to execute
Bourne shell scripts, because you then have to replace a significant
chunk of the build system.
>
> > For cmake to know msys mountpoints, there are now 4 proposed
> approaches:
> > - link against a msys library. This is Bill's preferred
> approach.
>
> The idea being that if you're plopping stuff into /usr/local, you're
> trying to create MSYS native build tools.
What sort of oxymoron is this? An application is either a native Woe32
application, or its an MSYS application; it cannot be both at once. If
its a native application, you put it in /usr/local; if its an MSYS
application, it must go in /bin.
> i.e. You're not doing Windows native development at all, you're doing
> things that will work *only* within MSYS.
Wrong again. If it's in /usr/local, it must be a native application; if
it's a native application, it will run just as well from cmd.exe, as it
will from MSYS. My own setup has MSYS in D:\usr\MSYS-1.0.11, and it
maps as a user defined mount point for D:\usr\local, on /usr/local; note
that this is *outside* the MSYS installation tree. All the programs in
this directory are accessible from MSYS; if I choose to use it, and I
add D:\usr\local\bin to a cmd.exe PATH, they also work just as well from
that.
Regards,
Keith.
-------------------------------------------------------------------------
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