From: Bill H. <bil...@ki...> - 2007-10-23 14:33:58
|
Hi Msys users, 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. My original position was that msys is not cygwin, and that projects that are built in the msys environment should not extend msys. So, the default install location for CMake on msys is currently the "program files" directory as it is for the microsoft and borland compilers. 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. 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. CMake is a native windows application and does not link to the msys run time, so to figure out where /usr/local is it would have to parse the fstab. 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. I would much appreciate the view point of an msys developer. Thanks. -Bill |
From: Greg C. <gch...@sb...> - 2007-10-23 15:44:33
|
On 2007-10-23 14:33Z, Bill Hoffman wrote: > > 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. CMake is a native windows > application and does not link to the msys run time, so to figure out > where /usr/local is it would have to parse the fstab. 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. Common advice on this list is to override 'prefix' with: ./configure --prefix=`cd /usr/local && pwd -W` which yields some string like this: C:/msys/1.0/usr/local See, for example, this detailed discussion: http://www.nabble.com/Re%3A-What%27s-a-%22MSYS-app%22--p12899758.html of the problem it solves, and of issues it may create. I'd suggest that CMake not do extra work to support a default that's likely to be overridden, especially because the most common idiom for overriding it isn't universally optimal. |
From: Keith M. <kei...@us...> - 2007-10-24 18:06:35
Attachments:
syspath.sh
|
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. |
From: Brandon V. E. <bva...@gm...> - 2007-10-24 18:55:50
|
On 10/24/07, Keith Marshall <kei...@us...> wrote: > On Tue, 2007-10-23 at 10:33 -0400, Bill Hoffman wrote: > > > 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. 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. The question is, what should be the default when neither the user nor the project has specified anything? The choices are: - have a default install location - issue an error and don't allow any installation I don't see any advantage to the latter. So we are merely discussing a default of %ProgramFiles% vs. /usr/local. Current thinking is that MSYS is for developing native Windows apps, therefore use %ProgramFiles%. > 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). Which also makes %ProgramFiles% the path of least resistance. It exists on any Windows system that isn't broken. > > 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. Heh, following the GNU Coding Standards for native Windows development is like asking Microsoft to decide the fate of the Free Software Foundation. :-) > > 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. Pollute C:\MinGW? Hadn't thought of that possibility. Seems to assume that we're spitting out a Unixy pile of \bin \doc \man \lib directories and so forth. Native Windows developers don't do that. Everything for a given app belongs under 1 directory. There's no reason to put a native Windows app under C:\MinGW\MyAppDirectory, it's not going to get added into any paths under MSYS. If they want search paths to their app they're going to have to specify 'em manually. Doesn't matter whether they specify C:\MinGW\MyAppDirectory or C:\Program Files\MyAppDirectory. Meanwhile, the former pollutes /mingw and the latter is canonical native Windows development, doesn't pollute anything. It's becoming clear to me that this debate is about Unixy tools. CMake is not about Unixy tools per se, it is about cross-platform development. I guess the remaining question is whether, in practice, just about every developer out there using MSYS is doing Unixy tools development. Cheers, Brandon Van Every |
From: Brandon V. E. <bva...@gm...> - 2007-10-24 19:07:37
|
On 10/24/07, Brandon Van Every <bva...@gm...> wrote: > > It's becoming clear to me that this debate is about Unixy tools. > CMake is not about Unixy tools per se, it is about cross-platform > development. I guess the remaining question is whether, in practice, > just about every developer out there using MSYS is doing Unixy tools > development. Ok, unless it can be demonstrated that almost everyone using MSYS is really a Unix tools developer, I say: - keep %ProgramFiles% as CMake's default install location - provide a SET_MSYS_INSTALL_PATH macro or some such. Something that correctly does all the magic Keith was talking about. If the specific project wants reliable specification of /usr/local, make it easy for them. Cheers, Brandon Van Every |
From: Keith M. <kei...@us...> - 2007-10-24 21:24:06
|
On Wed, 2007-10-24 at 14:55 -0400, Brandon Van Every wrote: > On 10/24/07, Keith Marshall <kei...@us...> wrote: > > On Tue, 2007-10-23 at 10:33 -0400, Bill Hoffman wrote: > > > > > 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. > > 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. > The question is, what should be the default when neither the user nor > the project has specified anything? The choices are: > > - have a default install location > - issue an error and don't allow any installation > > I don't see any advantage to the latter. Neither do I. > So we are merely discussing a default of %ProgramFiles% > vs. /usr/local. Current thinking is that MSYS is for developing > native Windows apps, therefore use %ProgramFiles%. No MSYS developer is likely to recommend %ProgramFiles%; typically that will resolve to something with spaces in the directory names, and we've seen far too many problems which can be directly attributed to that asinine practice, reported on our mailing lists and our bug trackers. > > 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). > > Which also makes %ProgramFiles% the path of least resistance. It > exists on any Windows system that isn't broken. No. The path of least resistance for a typical MSYS installation, which normally includes a parallel MinGW installation, is /mingw. > > > 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. > > Heh, following the GNU Coding Standards for native Windows development > is like asking Microsoft to decide the fate of the Free Software > Foundation. :-) I'm not saying we should slavishly follow them; it's simply because MSYS is good for porting projects which do follow them, that we see that as the default in so many of the packages we work with. (FTR, we do adopt the GCS style for our ChangeLogs, but little else). > > > 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. > > Pollute C:\MinGW? Hadn't thought of that possibility. It's not something I particularly like, which is why my own preference is for /usr/local; it is, however, convenient for novice users, who will normally have only a basic MSYS + MinGW installation--we know /mingw is going to exist, and /mingw/bin will be in $PATH, so we exploit that in our standard packages. > Seems to assume that we're spitting out a Unixy pile of \bin \doc \man > \lib directories and so forth. Yes, most of the packages we offer are organised precisely this way. > Native Windows developers don't do that. Everything for a given app > belongs under 1 directory. And each lives in splendid isolation, with no knowledge of other installed apps, little if any co-operation between any two, and an almighty mess of an overlong $PATH, to make it all hang together. Yuk!! > There's no reason to put a native Windows app under C:\MinGW > \MyAppDirectory, it's not going to get added into any paths under > MSYS. No, it isn't; but if everything is accessed from /mingw/bin, or my preferred /usr/local/bin, then there is no need for... > If they want search paths to their app they're going to have to > specify 'em manually. Doesn't matter whether they specify C:\MinGW > \MyAppDirectory or C:\Program Files\MyAppDirectory. ...this sort of PATH proliferation. I'm not saying either approach is right or wrong; they are simply different development models. MinGW is "Minimalist GNU for Windows"; as such, it follows the Unixy GNU model, and IMO tools intended to co-operate with MinGW or MSYS should follow the same model. > Meanwhile, the former pollutes /mingw ... Which is why I personally prefer /usr/local. > and the latter is canonical native Windows development, doesn't > pollute anything. But it does lead to PATH proliferation, which I intensely dislike. > It's becoming clear to me that this debate is about Unixy tools. > CMake is not about Unixy tools per se, it is about cross-platform > development. I guess the remaining question is whether, in practice, > just about every developer out there using MSYS is doing Unixy tools > development. I can't speak for the others, but my primary development platform is GNU/Linux; I have absolutely no interest in developing exclusively for Woe32. I use MinGW and MSYS as a vehicle for porting Unixy tools to Woe32; if my employer didn't shortsightedly force me to use Woe32, I wouldn't bother, for I use these Unixy tools almost exclusively, to fulfil my job function. Regards, Keith. |
From: Bill H. <bil...@ki...> - 2007-10-24 22:56:47
|
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. The only questions here, is what should the default be for CMake when creating makefiles for msys. 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 where you build a bunch of posix applications that run out of msys directories. 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 projects are essentially extending the msys environment. 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. 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? -Bill |
From: Keith M. <kei...@us...> - 2007-10-25 17:52:39
|
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. |
From: Bill H. <bil...@ki...> - 2007-11-01 20:13:51
|
OK, so it sounds like /usr/local is a good default for the CMake install prefix for the MSYS Makefile generator in CMake. Thanks for helping out! The trick now is to get CMake (a pure windows application), to know where /usr/local is on the disk. The approach for that seems to be to run the following commands: sh.exe -c 'cd /usr/local; pwd -W' if that fails then do this: sh.exe -c 'cd /usr; pwd -W' and tack on /local to the answer. I guess there is no equivalent of cygpath in msys that can be used. -Bill |
From: <gg...@ad...> - 2007-11-01 22:02:18
|
Bill Hoffman wrote: > OK, so it sounds like /usr/local is a good default for the CMake install > prefix for the MSYS Makefile generator in CMake. Thanks for helping out! > > The trick now is to get CMake (a pure windows application), to know > where /usr/local is on the disk. The approach for that seems to be to > run the following commands: > > sh.exe -c 'cd /usr/local; pwd -W' > if that fails then do this: > > sh.exe -c 'cd /usr; pwd -W' > and tack on /local to the answer. > > I guess there is no equivalent of cygpath in msys that can be used. > No cygpath. While some have recommended using sh -e "cd path; pwd -W", assuming you don't mind writing more code, personally I would rely on the output of mount.exe. By finding if /usr/local or /usr is there, you can locate the other paths. $ mount C:\DOCUME~1\gga\CONFIG~1\Temp on /tmp type user (binmode,noumount) c:\ActiveState\perl on /perl type user (binmode) c:\msys\1.0\mingw on /mingw type user (binmode) \\aura001\\bin on /gga/bin type user (binmode) C:\msys\1.0 on / type user (binmode,noumount) C:\msys\1.0 on /usr type user (binmode,noumount) a: on /a type user (binmode,noumount) c: on /c type user (binmode,noumount) d: on /d type user (binmode,noumount) e: on /e type user (binmode,noumount) z: on /z type user (binmode,noumount) The benefit of this is that you can run and parse this only once when cmake starts, cache it in a hash, and then any command that needs to find a path can locate the path by doing a case sensitive and case insensitive search through the hash (msys is case insensitive, but samba mounts might not be). This makes not only /usr/local work but it would then make supporting FIND_LIBRARY, FIND_PATH, etc. relatively easily and efficiently. You can also easily discard invalid paths early on without needing to run any external process. With sh -e, in the best scenario as it is with msys by default, you are always forking a new process for each path you want to check which would make FIND_LIBRARY and similar relatively slow as they often have to check 5 to 10 paths. In a worse case scenario, where sh.exe is not bash, you end up forking not one but three processes. By using sh.exe, cmake also cannot tell before hand if the path is going to be valid or not until the command fails. And when it fails, you might not know exactly why (is sh.exe or other command missing? is it temporary network trouble? An invalid path?) -- Gonzalo Garramuño gg...@ad... AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy |
From: Bill H. <bil...@ki...> - 2007-11-01 22:29:18
|
Gonzalo Garramuño wrote: > Bill Hoffman wrote: >> OK, so it sounds like /usr/local is a good default for the CMake install >> prefix for the MSYS Makefile generator in CMake. Thanks for helping out! >> >> The trick now is to get CMake (a pure windows application), to know >> where /usr/local is on the disk. The approach for that seems to be to >> run the following commands: >> >> sh.exe -c 'cd /usr/local; pwd -W' >> if that fails then do this: >> >> sh.exe -c 'cd /usr; pwd -W' >> and tack on /local to the answer. >> >> I guess there is no equivalent of cygpath in msys that can be used. >> > > No cygpath. > > While some have recommended using sh -e "cd path; pwd -W", assuming you > don't mind writing more code, personally I would rely on the output of > mount.exe. By finding if /usr/local or /usr is there, you can locate > the other paths. > > $ mount > C:\DOCUME~1\gga\CONFIG~1\Temp on /tmp type user (binmode,noumount) > c:\ActiveState\perl on /perl type user (binmode) > c:\msys\1.0\mingw on /mingw type user (binmode) > \\aura001\\bin on /gga/bin type user (binmode) > C:\msys\1.0 on / type user (binmode,noumount) > C:\msys\1.0 on /usr type user (binmode,noumount) > a: on /a type user (binmode,noumount) > c: on /c type user (binmode,noumount) > d: on /d type user (binmode,noumount) > e: on /e type user (binmode,noumount) > z: on /z type user (binmode,noumount) > > The benefit of this is that you can run and parse this only once when > cmake starts, cache it in a hash, and then any command that needs to > find a path can locate the path by doing a case sensitive and case > insensitive search through the hash (msys is case insensitive, but samba > mounts might not be). > > This makes not only /usr/local work but it would then make supporting > FIND_LIBRARY, FIND_PATH, etc. relatively easily and efficiently. You > can also easily discard invalid paths early on without needing to run > any external process. > > With sh -e, in the best scenario as it is with msys by default, you are > always forking a new process for each path you want to check which would > make FIND_LIBRARY and similar relatively slow as they often have to > check 5 to 10 paths. In a worse case scenario, where sh.exe is not > bash, you end up forking not one but three processes. > By using sh.exe, cmake also cannot tell before hand if the path is going > to be valid or not until the command fails. And when it fails, you > might not know exactly why (is sh.exe or other command missing? is it > temporary network trouble? An invalid path?) > > > So, this is heading where I did not want it go now.... CMake is a windows program, it should not have to parse mount tables and such. It is one thing to get a default for install, and another to get the FIND_* stuff to look in /usr/local... For all that to work and work easily, it seems like we should build CMake against the msys run time libraries. -Bill |
From: Greg C. <gch...@sb...> - 2007-11-01 23:39:49
|
On 2007-11-01 22:29Z, Bill Hoffman wrote: > > So, this is heading where I did not want it go now.... > > CMake is a windows program, it should not have to parse mount tables and > such. It is one thing to get a default for install, and another to get > the FIND_* stuff to look in /usr/local... > > For all that to work and work easily, it seems like we should build > CMake against the msys run time libraries. When deciding whether to build that way, consider whether this would be an issue for you: http://mingw.org/MinGWiki/index.php/Shells%2C%20terminals%20and%20MSYS | | It is very rare and uncommon to actually use MSYS to build MSYS apps, | and in fact to do this you have to install a special environment and use | a specially modified copy of gcc -- currently a very old 2.95 version. |
From: Bill H. <bil...@ki...> - 2007-11-01 23:58:35
|
Greg Chicares wrote: > On 2007-11-01 22:29Z, Bill Hoffman wrote: >> So, this is heading where I did not want it go now.... >> >> CMake is a windows program, it should not have to parse mount tables and >> such. It is one thing to get a default for install, and another to get >> the FIND_* stuff to look in /usr/local... >> >> For all that to work and work easily, it seems like we should build >> CMake against the msys run time libraries. > > When deciding whether to build that way, consider whether this > would be an issue for you: > > http://mingw.org/MinGWiki/index.php/Shells%2C%20terminals%20and%20MSYS > | > | It is very rare and uncommon to actually use MSYS to build MSYS apps, > | and in fact to do this you have to install a special environment and use > | a specially modified copy of gcc -- currently a very old 2.95 version. > It does sound like a pain, and not something I want to do. I will look into the mount table stuff. It does seem that I would be violating the spirit of msys which was my point from the start. However, maybe CMake is an exception to the rule, as it has to interact well with the msys compiler tool chain and pretty much function like a configure script would, but it has to do that without being a shell script like configure script. -Bill |
From: Cesar S. <ces...@gm...> - 2007-10-27 13:09:33
|
Bill Hoffman wrote: > > 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. The only questions here, is what should > the default be for CMake when creating makefiles for msys. > > 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 where you > build a bunch of posix applications that run out of msys directories. > 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 projects are essentially > extending the msys environment. 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. > > 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? > > -Bill > I would choose /usr/local, because it is the most flexible. With a simple edit of /etc/fstab, one could point /usr/local to be the same as c:\mingw, or even %ProgramFiles%/program_name. In that sense, by installing in /usr/local, I am not necessarily extending the MSYS environment in any way, as inferred. I personally use MSYS to help porting some free software applications I am interested in to Windows. Now, one of the great things about free software is code reuse. This means, however, that I have to compile and install some libraries the program depends upon, first. Call me lazy, but what I currently do is to install all dependencies (and the dependencies' dependencies) in one place, c:\mingw, so the compiler finds them easily, and so I don't have to keep updating PATH, CXXFLAGS, LDFLAGS and PKG_CONFIG_PATH, among others. In that way, what I am really want is to extend the MinGW gcc compiler in c:\mingw with these additional libraries, so I can build the main program in the first place. So, my preferred install location for libraries is c:\mingw. /usr/local is also acceptable, as long as it points to c:\mingw in /etc/fstab. For standalone applications, I don't use %ProgramFiles% at all, it gets too cluttered. I like to organize my installed applications like this: c:\programs\program_category\program_name Regards, Cesar |
From: Brandon V. E. <bva...@gm...> - 2007-10-27 06:04:11
|
On 10/26/07, Keith Marshall <kei...@us...> wrote: > On Thu, 2007-10-25 at 15:27 -0400, Brandon Van Every wrote: > > > MSYS isn't a build tool; it is a cmd.exe replacement. > > > > Build configuration is stated to be its raison d'etre. > > Agreed, this is badly worded; a case of trying to say too much in too > few words. It is, however, consistently and repeatedly worded in every place in the MSYS project. I agree that it "could be" worded otherwise, but do you speak for the MSYS project? If so, then you could change the text in all of those places for clarity. If not, perhaps you should discuss the MSYS mission statement with the other principal developers. I'm still interested in which kind of developer is dominant: - people who always work within the MSYS environment - people who do their builds and then leave the MSYS environment It would be nice to get more views on that from more MSYS developers. Cheers, Brandon Van Every |
From: Keith M. <kei...@us...> - 2007-10-27 22:41:32
|
On Sat, 2007-10-27 at 02:04 -0400, Brandon Van Every wrote: > On 10/26/07, Keith Marshall <kei...@us...> wrote: > > On Thu, 2007-10-25 at 15:27 -0400, Brandon Van Every wrote: > > > > MSYS isn't a build tool; it is a cmd.exe replacement. > > > > > > Build configuration is stated to be its raison d'etre. > > > > Agreed, this is badly worded; a case of trying to say too much in > > too few words. > > It is, however, consistently and repeatedly worded in every place in > the MSYS project. I agree that it "could be" worded otherwise, but do > you speak for the MSYS project? Yes. > If so, then you could change the text in all of those places for > clarity. I can, and I will. I posted the proposed alternative wording here, not merely for your benefit, but... > If not, perhaps you should discuss the MSYS mission statement with the > other principal developers. ...to allow these very people, together with those who do routinely *use* MSYS, an opportunity to comment, before I make the change. > I'm still interested in which kind of developer is dominant: > - people who always work within the MSYS environment > - people who do their builds and then leave the MSYS environment In this regard, I can speak only for myself. In my day job, I administer a production control system, where *none* of the servers or workstations are used for software development. All of these have MSYS installed, simply because of its vastly superiour shell scripting capabilities, when compared to the native offering; none but the workstation on my own desk has MinGW installed. > It would be nice to get more views on that from more MSYS developers. Sure, but I can't force them to speak up. However, I would expect the majority of subscribers to an MSYS specific list to actually use it on a fairly routine basis. Regards, Keith. |
From: Brendon C. <bc...@av...> - 2007-10-28 23:27:36
|
> I'm still interested in which kind of developer is dominant: > - people who always work within the MSYS environment > - people who do their builds and then leave the MSYS environment > > It would be nice to get more views on that from more MSYS developers. > I would probably want the default prefix to be: /usr/local and follow the standard UNIX directory structure: bin, lib, include ... I think that most of the people that will be making use of the makefiles generated by CMake in a MSYS/MinGW environment will generally be devs that are used to things going to /usr/local by default. No need to change what we expect. My understanding of CMake is that it attempts to use native tools for an environment and make things more like what is already expected for that environment... When creating software to distribute to your average windows user. I may use MSYS/MinGW to build it or i may use MSVC but they should not know or care about this. At that point I will create an installer that installs to Program Files. At the time of creating the binaries for this installer i will set the prefix as necessary or possibly the bindir, libdir etc so that i don't get the UNIX like directory structure. In essence my usual usage is to follow a UNIX like framework with stuff installed in /usr/local and when i make stuff for end users they will get something that looks like every other bit of windows software where /usr/local makes no sense and which usually involves more procedure than is provided by the usual ./configure && make && make install So my feel is that installing by default to program files is going to cause me to have to override this prefix the majority of the time (For personal use and development). Only the once off time of creating a binary distribution of my own software for non-dev users will i make use of the program files directory as a default. To summarize i am of the group of people: "who always work within the MSYS environment" but will occasionally want to create software for people who do not work within the MSYS environment. The common scenario i think of users for CMake in MSYS will be devs and so following the existing method used by autotools of default installing to /usr/local makes most sense to me. Hope that is helpful, Brendon. |
From: Suresh G. <sgo...@ya...> - 2007-10-24 22:48:57
|
This thread brought up the topic of Filesystem Hierarchy http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard It is not just Windows that puts different programs in their own directory -- Unix supports such a distribution under /opt. And GoboLinux, a type of Linux, uses /Programs/ http://en.wikipedia.org/wiki/GoboLinux And supposedly Mac OS X uses /Library and /Applications Part of the solution to the PATH prolifiration might be to add symlinks to a bin directory in the PATH (however, doubt if this will work on Windows). And, I believe, applications that live under "/opt" type locations know how to find what they need (such as configuration files) based on paths relative to where their executable is. --Suresh |
From: Bob P. <gra...@gm...> - 2007-10-25 11:58:28
|
On Wed, 24 Oct 2007 18:48:44 -0400, Suresh Govindachar <sgo...@ya...> wrote: > Part of the solution to the PATH prolifiration might be to > add symlinks to a bin directory in the PATH (however, doubt > if this will work on Windows). XP, and presumably Vista, do have symbolic links, they are called 'Junctions Points'. http://en.wikipedia.org/wiki/NTFS_junction_point |
From: Keith M. <kei...@us...> - 2007-10-25 17:53:14
|
On Wed, 2007-10-24 at 15:48 -0700, Suresh Govindachar wrote: > This thread brought up the topic of Filesystem Hierarchy > http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard > > It is not just Windows that puts different programs in their > own directory -- Unix supports such a distribution under > /opt. And GoboLinux, a type of Linux, uses /Programs/ > http://en.wikipedia.org/wiki/GoboLinux And supposedly > Mac OS X uses /Library and /Applications Sure. I'm well aware of this convention on UNIX/Linux; no experience on Mac-anything though. The difference is that, on *nix, it's done within an organised, well structured, clearly thought out hierarchy, unlike the disorganised hotch-potch of Woe32. In particular... > Part of the solution to the PATH prolifiration might be to > add symlinks to a bin directory in the PATH... ...this is standard practice. > ... (however, doubt if this will work on Windows). It will not. Not with MSYS, or native applications in general; Woe32 does not support symlinks. [1] > And, I believe, applications that live under "/opt" type > locations know how to find what they need (such as configuration > files) based on paths relative to where their executable is. This is fairly easy to achieve in Woe32 too, provided the installation hierarchy is well thought out. Unfortunately, many porters of Open Source packages overlook it. However, this isn't really the issue. If a package delivers tools, which are predominantly intended to be used from a CLI, then the top level binaries need to be accessible via the PATH. It doesn't matter whether the CLI is MSYS sh.exe, or cmd.exe. It is simply much more convenient if these are collected together, in a *few* standardised locations; for MSYS that standardised location is either /usr/local, or /mingw, for *native* applications, and /bin in the special case of MSYS applications. In either case, symlinking to those locations is not an option, because Woe32 does not support symlinks. Of course, for a GUI application, to be invoked from a desktop shortcut, or a menu pick, different rules apply; you probably do not want these cluttering up a directory normally used for CLI tools. In this case, perhaps $ProgramFiles/GUIappName [2] is an appropriate location; I don't know how a tool, such as Cmake, would handle that distinction, though. Regards, Keith. [1] Microsnot claim to have added this, in Vista. From what I've read about their implementation, it falls a long way short of a satisfactory one, but admittedly, this is hearsay. [2] Note the qualification based on GUIappName; IMO, this is imperative for for this type of application, but would always be wrong for a CLI application installed into a ${prefix} of /usr/local, or /mingw, where the binary needs to go directly into ${prefix}/bin, even if necessary support files go in ${prefix}/share/CLIappName/... |
From: Brandon V. E. <bva...@gm...> - 2007-10-24 23:45:51
|
On 10/24/07, Keith Marshall <kei...@us...> wrote: > On Wed, 2007-10-24 at 14:55 -0400, Brandon Van Every wrote: > > > Native Windows developers don't do that. Everything for a given app > > belongs under 1 directory. > > And each lives in splendid isolation, with no knowledge of other > installed apps, little if any co-operation between any two, and an > almighty mess of an overlong $PATH, to make it all hang together. > > Yuk!! That's Windows native development though. It is untrusting and paranoid. It is not for programmers, it is for end users. http://www.joelonsoftware.com/articles/Biculturalism.html There aren't stacks of trusted open source libraries to draw upon. There's no canonical configuration, so no testing for such a configuration. So what I'm getting at, is when you guys say MSYS is for Windows native development, do you really mean it? Or are you really saying, "We like everything to be Unix, but we don't like the bloat of Cygwin" ? > ...this sort of PATH proliferation. I'm not saying either approach is > right or wrong; they are simply different development models. MinGW is > "Minimalist GNU for Windows"; as such, it follows the Unixy GNU model, MinGW is a compiler. When I run mingw32-make from a Windows Command Prompt, I could care less about GNU anything. > > and the latter is canonical native Windows development, doesn't > > pollute anything. > > But it does lead to PATH proliferation, which I intensely dislike. Who cares? Well, you care, but why should the native Windows development world care what you don't like? I can think of all sorts of things in programming I don't like, many of them coming from Microsoft. I have the power to change lots of them in my own projects. But there are still dominant standards which people use by default. Windows native developers aren't concerned with path proliferation. It's standard drill. > I can't speak for the others, but my primary development platform is > GNU/Linux; I have absolutely no interest in developing exclusively for > Woe32. I use MinGW and MSYS as a vehicle for porting Unixy tools to > Woe32; if my employer didn't shortsightedly force me to use Woe32, I > wouldn't bother, for I use these Unixy tools almost exclusively, to > fulfil my job function. Right. You see MSYS as a Windows avoidance solution. I don't think that's the basis upon which we should be deciding the defaults, unless almost every MSYS user out there is typically a Windows avoider. If that's the case, then let's admit that MSYS really isn't about Windows native development. It just doesn't want to be bloated like Cygwin. My own biases: I'm an indie game developer. Realistically, Linux is moribund as a consumer desktop market. There's the Mac, but that platform doesn't have anywhere near the volume of the Windows PC. Consoles are expensive to develop for and have licensing restrictions. The Windows PC is pretty much the best platform for an indie game developer, whether I like it or not. I see MinGW as a free alternative to MSVC. Cygwin isn't an alternative, I'm not shipping GPLed code and -mno_cygwin is unreliable in practice. Cheers, Brandon Van Every |
From: Keith M. <kei...@us...> - 2007-10-25 17:52:56
|
On Wed, 2007-10-24 at 19:45 -0400, Brandon Van Every wrote: > So what I'm getting at, is when you guys say MSYS is for Windows > native development, do you really mean it? Huh? We've never said anything of the sort. MSYS is a *shell*; its only purpose is to provide a replacement for the execrable cmd.exe. Ok, we do throw in a few tools to facilitate running the build systems for GCS conforming applications, but it still isn't really for anything much more than what cmd.exe is for. Perhaps you are confusing MSYS with MinGW? These are not the same. > Or are you really saying, "We like everything to be Unix, but we don't > like the bloat of Cygwin"? No, not this either. The original goal of MSYS was to facilitate porting of Open Source packages, which traditionally target POSIX host systems, *without* requiring a POSIX emulation layer, or API. That places an onus on the porter to replace POSIX API calls with native Woe32 API calls, to achieve similar objectives. Obviously, this additional onus is inconvenient for some; to them we say "perhaps you should just use Cygwin". We don't view Cygwin as a competing solution; we view Cygwin and MSYS + MinGW as complementary. The two projects co-operate quite well, and indeed, we share some developers. Our objective is to offer choice to the cross-platform developer, in how his product will be delivered. Another issue is licensing. When an application is built for Cygwin, and subsequently distributed, then Cygwin licensing restrictions apply. MinGW has a much freer licensing model. > > ...this sort of PATH proliferation. I'm not saying either approach is > > right or wrong; they are simply different development models. MinGW is > > "Minimalist GNU for Windows"; as such, it follows the Unixy GNU model, > > MinGW is a compiler. When I run mingw32-make from a Windows Command > Prompt, I could care less about GNU anything. How is this relevant to MSYS? MinGW is *not* MSYS. If you are running MinGW from a Windoze Command Prompt, (a.k.a. cmd.exe), you are *not* using MSYS. Whether you care about it, or not, you *are* using the *GNU* Compiler Collection. > > > and the latter is canonical native Windows development, doesn't > > > pollute anything. > > > > But it does lead to PATH proliferation, which I intensely dislike. > > Who cares? Well, you care, but why should the native Windows > development world care what you don't like? I don't expect them to care. I respect their right to choose a development model, which is anathema to me. I don't care that they've made that choice; that is their business. I *do* ask that they respect my right to choose an alternative development model. When I choose to use MSYS as my primary CLI, I'm making a pretty clear statement that I expect my development model to conform approximately to POSIX. That I choose MSYS + MinGW over Cygwin, expresses a preference for creating applications which can run natively under Woe32, without requiring a POSIX emulation layer; to achieve that, I'm prepared to put in the porting effort, to convert POSIX API calls to Woe32 replacements. > I can think of all sorts of things in programming I don't like, many > of them coming from Microsoft. I have the power to change lots of > them in my own projects. But there are still dominant standards which > people use by default. So what? If I'm developing for my own use, or for use by like minded people, who also favour the POSIXy model, or for portability to a real POSIX system, why should I care what the Woe32 lock-in crowd do? > Windows native developers aren't concerned with path proliferation. > It's standard drill. > > > I can't speak for the others, but my primary development platform is > > GNU/Linux; I have absolutely no interest in developing exclusively for > > Woe32. I use MinGW and MSYS as a vehicle for porting Unixy tools to > > Woe32; if my employer didn't shortsightedly force me to use Woe32, I > > wouldn't bother, for I use these Unixy tools almost exclusively, to > > fulfil my job function. > > Right. You see MSYS as a Windows avoidance solution. Wrong. As a professional engineer, I see MSYS + MinGW as a vehicle for delivering effective solutions. IMO, Woe32 is a pretty crap platform for getting real engineering work done. > I don't think that's the basis upon which we should be deciding the > defaults, unless almost every MSYS user out there is typically a > Windows avoider. It has nothing to do with Windows avoidance; it has everything to do with expectations. MSYS is a POSIX command line environment; those who choose to use it, generally expect POSIX-like behaviour. > If that's the case, then let's admit that MSYS really isn't about > Windows native development. It isn't. No one but you ever claimed that it is. Regards, Keith. |
From: <gg...@ad...> - 2007-10-25 07:58:44
|
Bill Hoffman wrote: > > 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. The only questions here, is what should > the default be for CMake when creating makefiles for msys. > Bill, you should also mention some more things about how cmake works and what's requested. CMake provides generators that create makefiles or IDEs, like an autoconf on steroids. For MinGW, CMake provides both a "MinGW Generator" and a "MSYS Generator". Unfortunately, both default to $PROGRAMFILES. My request is to have the MSYS Generator default to /usr/local, while the MinGW one is left pointing to $PROGRAMFILES. The MinGW defaults to mingw-make if found, if I'm not mistaken, which further avoids path issues. CMake is oriented to development, not shipping products. An additional CMake component called CPack is one that can handle packaging a distribution for user installation using other generators (pkg, rpm, NSIS, etc). There's no reason to have the development and packaging install location be the same and often isn't. CMake's sandbox install under all other unix platforms (including cygwin), defaults to /usr/local. 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 mountpoints. From Bill's pov, this can present some long term headaches. For cmake to know msys mountpoints, there are now 4 proposed approaches: - link against a msys library. This is Bill's preferred approach. 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. - parse /etc/fstab. Potentially could have some issues with some mountpoints not listed, it seems. - Use the output of "mount". No problems. - Use sh -e "cd path; pwd -W". No problems, but somewhat slow. CMake in general goes to a little bit more trouble than autoconf does to avoid path naming, length and win32 issues, albeit it may not always be successful with windows paths under a unix-like makefile. -- Gonzalo Garramuño gg...@ad... AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy |
From: Keith M. <kei...@us...> - 2007-10-25 17:53:29
|
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 > mountpoints. 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 > approaches: > - 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... > - 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 justified. Regards, Keith. |
From: <gg...@ad...> - 2007-10-25 12:30:59
|
Bob Paddock wrote: > XP, and presumably Vista, do have symbolic links, they are called > 'Junctions > Points'. > > http://en.wikipedia.org/wiki/NTFS_junction_point > Nope. Not the same. Files are linked as hard links and the link cannot cross volumes. True symbolic links do not do the former and can do the later. Vista DOES add *REAL* symbolic links thou (it only took Microsoft 15+ years!), but mingw/cygwin would then need to link a newer microsoft runtime than the one being used now. That may be okay or may lead to some legal and technical issues. Probably worth asking the mingw-x64 team about what they are doing with that issue. -- Gonzalo Garramuño gg...@ad... AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy |