Re: [Mingw-msys] Default install location for CMake

[Keith Marshall <keithmarshall@xxxxxxxxxxxxxxxxxxxxx>]

On Tue, 2007-10-23 at 10:33 -0400, Bill Hoffman wrote:
> I am a developer of CMake www.cmake.org.   CMake is a build tool that 
> works sort of like autotools, but does not require a shell.  CMake has
> support for MSYS and MinGW.  There have been several discussions on
> the CMake mailing list in the past, and there is one now about the
> correct default install location for CMake to use on MSYS.

I presume you mean this one:
http://www.cmake.org/pipermail/cmake/2007-October/017010.html

> My original position was that msys is not cygwin, and that projects
> that are built in the msys environment should not extend msys.

No, and neither can they; for that you need to be in the msysDVLPR
environment.  The MSYS environment is for building native Woe32
programs, from source which expects a POSIXy build system.

> 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.

> Basically, assume that applications that are being built are native 
> windows applications, and they are to be installed where other native 
> windows stuff is installed.

Which is where, exactly?  My answer to this is that it is anywhere that
the end user chooses.  On my Woe32 box, the "Program Files" directory is
reserved for all the broken proprietary crap, which I almost never use.
Everything which I do use on a daily basis, and which I've installed
myself goes elsewhere; if it's a native command line tool, then I will
always be starting it from an MSYS shell, (I refuse to use cmd.exe,
which is way too limited in capability), and my preferred installation
directory is the /usr/local I've set up under MSYS, (but mapped from
outside the MSYS tree itself).

> However, there have been some requests that CMake use /usr/local as a 
> default install location on msys.  I have some issues with this, as 
> CMake will have to figure out where /usr/local really is on the
> windows file system, but that can be done.

Yes, it really isn't too difficult.

> CMake is a native windows application and does not link to the msys
> run time,

So, every path name passed to it as a command line argument, or within
the environment, will be automatically transformed to native format,
before Cmake ever sees it; the only way it will ever see a POSIX style
MSYS virtual path name is if you compile it into the Cmake binary, or
read it from a configuration file, in this form.

> so to figure out where /usr/local is it would have to parse the fstab.

No.  You don't want to do that.  In the first place, if you mean read
the /etc/fstab file, how are you going to find it?  Even if you could
find it, it is unlikely to specify a mapping for /usr/local, or even
either / or /usr anyway; MSYS maps these latter two automatically, and
doesn't normally include them in /etc/fstab; indeed it doesn't even
need /etc/fstab to exist.

On the other hand, if you mean parse the output from the MSYS mount.exe
command, then that would be a clumsy way indeed, to locate the required
path.  The best way is to use the built-in commands of the MSYS shell
itself, to tell you what you need to know.  A naive approach, from
within C/C++ code, would be to capture the standard output from:--

  _spawnlp(_P_WAIT, "sh.exe", "sh", "-c", "'cd /usr/local && pwd -W'", NULL);

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).

A more robust technique is used by the MSYS_AC_CANONICAL_PATH macro, for
use with autoconf, which I published on this list some two years ago.
I've adapted that into the attached shell script implementation, which
may be installed into the MSYS /bin directory, as say /bin/syspath, and
substituted for the 'cd /usr/local && pwd -W' in the above, which then
becomes:--

  _spawnlp(_P_WAIT, "sh.exe", "sh", "-c", "'syspath /usr/local'", NULL)

which still requires the MSYS sh.exe to be the first found in the PATH,
but removes the requirement for /usr/local to refer to an existing
directory; (indeed, it will equally well resolve the path name for a
file, from MSYS virtual POSIX form, to Woe32 native equivalent).

Note that in each of the above examples, an equivalent CreateProcess()
call, and a wait, may be substituted for the _spawnlp(); in either case
care is needed with quoting of the command to be executed by sh.exe.

> 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.

> 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.

IMO, the choice is not yours to make; you should support whatever each
project maintainer wants for his own package defaults.  I have never
used Cmake, (and I will never even consider it, if it forces me to
deliver packages which install to "Program Files" by default).  You
should facilitate whatever the users of your product require, in a
flexible manner, and ultimately, you must provide an infrastructure
which allows them to extend similar flexibility to their end users.  It
doesn't have to be /usr/local, or anything else; it does need to be
flexible.  Autoconf achieves this by setting an initial default, guided
by GCS, of /usr/local, but package maintainers using autoconf may change
that, by using AC_PREFIX_DEFAULT for their own projects, and end users
have the final say, with --prefix=/wherever/I/want/it, when they run
configure; to me, that seems a reasonable paradigm to mimic.

Regards,
Keith.

Attachment: syspath.sh
Description: application/shellscript

-------------------------------------------------------------------------
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