Re: FW: [Mingw-msys] How do I recreate the MSYS distribution?
- Date: Wed, 24 Oct 2007 19:06:31 +0100
- From: Keith Marshall <keithmarshall@xxxxxxxxxxxxxxxxxxxxx>
- Subject: Re: [Mingw-msys] Default install location for CMake
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.
------------------------------------------------------------------------- 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
- RE: FW: [Mingw-msys] How do I recreate the MSYS distribution?
- From: Julien Lecomte
- RE: FW: [Mingw-msys] How do I recreate the MSYS distribution?
- Prev by Date: Re: [Mingw-msys] How do I recreate the MSYS distribution?
- Next by Date: Re: FW: [Mingw-msys] How do I recreate the MSYS distribution?
- Previous by thread: RE: FW: [Mingw-msys] How do I recreate the MSYS distribution?
- Next by thread: Re: FW: [Mingw-msys] How do I recreate the MSYS distribution?