Re: FW: [Mingw-msys] How do I recreate the MSYS distribution?
On Thu, 2007-10-25 at 04:59 -0300, Gonzalo Garramuño wrote:
> Besides finding where /usr/local resides as a windows path (which is
> easy), many commands of cmake can locate libraries or other files
> (similar to autoconf commands), so a full support of cmake under MSYS
> needs to eventually really learn about all of the mingw/msys
MinGW mount points? There is no such thing. MSYS mount points, ok.
There are only two which are guaranteed to exist: / and /usr, and both
refer to the same native Woe32 location--the MSYS installation root. In
practice, when the MSYS user also uses MinGW, a third will be defined,
to map /mingw to the MinGW installation root. Users may also choose to
define additional ones, for their own convenience.
One notable exception to the above: for each mapped Woe32 drive, MSYS
will automatically create a /<driveletter> mount point.
None of these mapped drive mount points, nor the / or /usr mount points
are normally enumerated in /etc/fstab; all other mount points, including
the usual /mingw, are classified as "user defined", and therefore must
be enumerated in /etc/fstab.
> From Bill's pov, this can present some long term headaches.
> For cmake to know msys mountpoints, there are now 4 proposed
> - link against a msys library. This is Bill's preferred approach.
It certainly wouldn't be mine. As MinGW/MSYS developers, we prefer to
keep as much as possible in the native Woe32 space; building as an MSYS
special component is normally a last resort.
> This causes the headache of now having 3 different cmake versions on
> windows (cygwin, msys and win32 native). I'm somewhat opposed to this
> as I think a single cmake should be able to output files for all
> variations under windows unless a proprietary library (read: windows)
> is the issue. The big benefit is that cmake will not care how msys
> resolves paths now or in the future.
However, it does require you to use the special "MSYS System Builder"
tools to build it, and may break if we change the API in the future; the
"pwd -W" feature of our bash implementation is more likely to be assured
of a stable future.
> - parse /etc/fstab. Potentially could have some issues with some
> mountpoints not listed, it seems.
Not a viable option, IMO. Normally, only the user defined mount points
are listed; the automatic mounts are typically omitted.
> - Use the output of "mount". No problems.
Except that you have to parse it, pick out the mount point fields, find
the longest initial sub-string match to the path of interest, then piece
it all back together again; all of this is already done for you, if you
> - Use sh -e "cd path; pwd -W". No problems, but somewhat slow.
...this. Hardly any slower than forking mount.exe, capturing and then
parsing its output; the overhead will be similar in both cases. This is
a naive implementation however, (and note that it must be "sh -c ...",
not "sh -e ..."), and yes, there will be a greater overhead for the
shell script based variant of this, which I recommended; this is by far
the most robust implementation, and IMO, the extra overhead is well
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