Re: [CMake] CMake2.5 - wrong default install location for mingw
Bill Hoffman wrote: The C++ code did not forget anything. I intentionally do not set the CMAKE_INSTALL_PREFIX to the equivalent of /usr/local in a windows PATH because I think it is the wrong default. I still think that it is correct to install into program files. The only case where I would accept /usr/local as the default for make install for msys, is if someone made a native msys version of cmake that linked to the msys run time. That would be a cmake used for creating other msys applications that would install into /usr/local for msys. If cmake is creating a native windows application that uses the microsoft run time, then it is a native windows application and it belongs in program files. Native windows applications do not belong in /usr/local (since they don't even know what /usr/local is). But mingw or cygwin under windows will ALWAYS link against the microsoft runtime, regardless of whether you compile cmake specifically for it or not. It isn't likely mingw or cygwin will change that unless they go into the OS business. As such I fail to see the logic then of why you would make it install on /usr/local if you were linking against a mingw runtime and not the other way. Either way, you are still linking against one (or more) microsoft libraries when on windows. Also, cmake2.5 provides, currently, a MinGW Generator AND an MSYS Generator which could operate differently and have different default install locations. I'll ask you a trick question. How do you know the user IS running under windows and using a microsoft runtime? He could be running it under wine and not having a single microsoft DLL in sight. Do you consider wine windows? The underlying OS is really linux and all the wine DLL's link against the linux libraries. If you ask me, in these days of virtualization, choosing install locations based on who is the owner of an underlying DLL seems VERY hard to do right and well... wrong to me. Perhaps it would help if you explained your use case. Sure, I'll give you several examples. Why would you want to build MSVC and an MSYS version of your software on the same machine? To follow your advice from some months ago, where you specifically told me that you just COULDN'T generate Visual Studio files without linking to the Visual Studio library (back then I also disagreed, but since I don't know the VS innards well enough, I took your word for it). Funny enough, it was kind of the reverse argument of what you are saying now. Up to an earlier cmake2.5 version from 2 or 3 months ago (my stable one that got overwritten), that was still true. A MinGW cmake could not generate MSVC projects. It seems now this may have changed (not sure, did not do proper tests yet). Do they behave differently? Don't know. They used to. Do they? Or, are you just testing to make sure your stuff can be built by both MSVC and MSYS? Correct. I also have code that I need to compile that cannot be compiled under MSVC (ffmpeg, for example, due to microsoft's broken compiler up to 7.1 at least). No other proprietary alternative video library matches all that an even LGPL ffmpeg can do. Also, one of my template libraries also started crashing the microsoft compiler version I use with an undocumented C1001 and as such I am considering banning the compiler completely from all my build projects in the future. I honestly I am not going to be the betatester for microsoft for a product that cost me U$1500 and works worse than gcc and will now require even more money to upgrade to fix the bugs I need. Nor am I going to upgrade to a free MSVC8 before I ship my product as I don't even know all the limitations of Express (which I'm sure there are there). If they do not behave differently, why would you want one installed in program files and one in /usr/local? They DID behave differently. But I also answered this privately to Brandon. Basically, because that's a very good development policy that at least *I* like (but I'm pretty sure I'm not alone on this one). Some old Unix guru (whoever came up with the idea) provides, in practice, the idea of using /usr/local as a sandbox for software. Autotools makes that the default even. I can easily get the latest ffmpeg from svn, compile it in /usr/local and see if it broke stuff. LD_LIBRARY_PATH or PATH has /usr/local in it first. If something breaks, I don't upgrade or ship my software with that version. I keep using the one in /usr or in $PROGRAMFILES. If cmake worked like that on windows, I could do the same thing with cmake. Currently, I can't unless I specifically remember to pass a flag each time. So even though I upgrade cmake from CVS I usually don't compile it and try it, and I am now 2-3 months behind cmake development. I'll give you yet another example. I contributed 3 or 4 modules to cmake. I got an email asking to become maintainer for them. If I cannot check my code against the latest
Re: [CMake] CMake2.5 - wrong default install location for mingw
On 10/23/07, Gonzalo Garramuño [EMAIL PROTECTED] wrote: Native windows applications do not belong in /usr/local (since they don't even know what /usr/local is). But mingw or cygwin under windows will ALWAYS link against the microsoft runtime, regardless of whether you compile cmake specifically for it or not. It isn't likely mingw or cygwin will change that unless they go into the OS business. Cygwin GCC does not link against the Microsoft runtime, it links against cygwin1.dll. Unless you go through a lot of pain to use -mno_cygwin, which almost nobody uses in practice and is going to break lotsa things in practice. Also, cmake2.5 provides, currently, a MinGW Generator AND an MSYS Generator which could operate differently and have different default install locations. I suggest that you go argue this with the MSYS developers. If they tell you what we've told you, then you'll understand why we're doing what they want, even if you don't agree with it. If they tell you they actually think installing stuff to /usr/local by default is a good idea, then we'll have to reconsider our understanding of their intent. I honestly I am not going to be the betatester for microsoft for a product that cost me U$1500 and works worse than gcc and will now require even more money to upgrade to fix the bugs I need. I sympathize. I'm not sure how I'm going to get Microsoft DirectX SDK support out of MinGW though. Last time I looked at that, the hacks people had tried were ugly and didn't work. One possibility is to go the OpenGL route, which is indeed a more logical cross-platform fit to CMake capabilities. But my point is, some people end up in support scenarios where MSVC is pretty much what they're stuck with. That's how Microsoft makes money. Nor am I going to upgrade to a free MSVC8 before I ship my product as I don't even know all the limitations of Express (which I'm sure there are there). I think it has limits on optimization and maybe stack size. For instance, it couldn't handle the pile of functions that the Chicken Scheme -- C compiler generated. It was enough of a PITA that nobody ever made a serious effort to solve the problem. Some old Unix guru (whoever came up with the idea) provides, in practice, the idea of using /usr/local as a sandbox for software. As I said privately though, that's Unix development, not native Windows development. Native Windows development has limitations, as do all operating systems, but it is what it is. The core issue is that you think MSYS should be about native Unix development, and the MSYS people don't. If cmake worked like that on windows, I could do the same thing with cmake. Currently, I can't unless I specifically remember to pass a flag each time. So even though I upgrade cmake from CVS I usually don't compile it and try it, and I am now 2-3 months behind cmake development. The rest of us just set our tool paths to be exactly what we want. We compile from CVS to the degree that it is actually important to us. Clearly, it is not so important to you, or you would have a hermetically sealed build environment that does it already. I'll give you yet another example. I contributed 3 or 4 modules to cmake. I got an email asking to become maintainer for them. If I cannot check my code against the latest cmake sanely, I honestly don't want to even try to maintain it. I already support close to 10 open source projects and soon two closed source ones. There's no way I could guarantee my modules work correctly with latest cmake. Or debug those modules under MSYS, MSVC and MinGW (I'd have to choose one). But the choice of %ProgramFiles% or /usr/local doesn't change any of this. There are always lotsa build scenarios, and they're all going to have different bugs. If you're too overloaded to deal with them, then you're too overloaded to deal with them. You can try to marshal other people to deal with them, and they either will or won't. If nobody will deal with them, then they don't get dealt with. In Open Source you get what you pay for. Yet one more example. I am currently forking fltk2 (at least temporarily) with one of the goals to add cmake support, as properly keeping in sync VS files is, in my opinion, one thing that is slowing fltk2's development. Currently, it also builds using autotools under MSYS and as such it installs in /usr/local by default. User's will expect that to keep working the same way. You can certainly make it true for fltk2. Same thing will happen for any autotools project that works under msys that wants to move to cmake. That doesn't follow. The autotools crowd is stuck with MSYS and Cygwin shells. CMake isn't. It's a political battle, between people who think cross-platform == Unix and people who think cross-platform == doing things the way the native system does it. When migrating a project from Unix to true cross-platform development, there's inevitably politics to reckon
Re: [CMake] CMake2.5 - wrong default install location for mingw
On 10/23/07, Bill Hoffman [EMAIL PROTECTED] wrote: OK, now this is more what I was asking for. If autotools based projects in msys install into /usr/local by default, then maybe CMake ones should as well. As far as I'm concerned, this is Autotools' problem. CMake should pursue no slavish strategy with regards to Autotools. Only strategies that actually result in Autotools projects getting converted to CMake projects. I've made known my political views on that! It's mostly about working with people who are ready to move on and willing to make changes. I think I am going to post to the msys mailing list and get some input from those folks. My reason for not wanting to use /usr/local was that msys states that it does not want to become a cygwin, but rather just a tool so that you can build autotools projects under msys. Last I checked a couple of years back, the MSYS developers were surprisingly hostile to autotools. Don't wade into their mailing list saying MSYS is for running autotools unless you want to seek offense. I believe I checked into this when you and I were having this very argument awhile ago. And I conceded, having previously been of the /usr/local mindset, because of what I found on the MSYS list. It will be interesting to see what you determine *at present*. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake2.5 - wrong default install location for mingw
Brandon Van Every wrote: On 10/23/07, Bill Hoffman [EMAIL PROTECTED] wrote: OK, now this is more what I was asking for. If autotools based projects in msys install into /usr/local by default, then maybe CMake ones should as well. As far as I'm concerned, this is Autotools' problem. CMake should pursue no slavish strategy with regards to Autotools. Only strategies that actually result in Autotools projects getting converted to CMake projects. I've made known my political views on that! It's mostly about working with people who are ready to move on and willing to make changes. I think I am going to post to the msys mailing list and get some input from those folks. My reason for not wanting to use /usr/local was that msys states that it does not want to become a cygwin, but rather just a tool so that you can build autotools projects under msys. Last I checked a couple of years back, the MSYS developers were surprisingly hostile to autotools. Don't wade into their mailing list saying MSYS is for running autotools unless you want to seek offense. I believe I checked into this when you and I were having this very argument awhile ago. And I conceded, having previously been of the /usr/local mindset, because of what I found on the MSYS list. It will be interesting to see what you determine *at present*. OK, I am officially moving this discussion to the msys mailing list. If anyone is interested in this, please join the mingw-msys mailing list here: https://lists.sourceforge.net/lists/listinfo/mingw-msys The initial response on that list in favor of keeping CMake the way it currently is. There is an interesting discussion on the pros/cons of setting c:/msys/usr/local as an install prefix that happened Sept 2007 on that list. Here is the initial response to my inquiry: 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. If anyone wants to argue for/against CMake defaulting to /usr/local then do it on the msys mailing list. Thanks. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake2.5 - wrong default install location for mingw
Bill Hoffman wrote: Looks like a nice patch that you can put in your cmakelist files. I still do not think it should go in CMake. I don't think that things built by cmake that are native windows things belong in the /usr/local mount point of msys. If you do, it is easy enough to change your project to install by default in anywhere you want. Okay, I looked at the C++ code of MSYS generator. And surprise, surprise. It does EXACTLY what I said to do of searching the path (but looks for make.exe instead of sh.exe). Also it uselessly (and somewhat potentially incorrectly) parses /etc/fstab to find where mingw's bin directory is (and does not cache any of the other paths, which could indeed potentially allow FIND_PATH() and others to work with mingw paths eventually). The C++ code just forgets to set CMAKE_INSTALL_PREFIX to MSYS proper values. I'll revert this .cmake patch and I'll give you a C++ patch of it instead, as the code is much cleaner that way. And to be honest, I find the C++ code to be much more readable than the .cmake code (which is somewhat disturbing). -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake2.5 - wrong default install location for mingw
On 10/21/07, Gonzalo Garramuño [EMAIL PROTECTED] wrote: Also it uselessly... ... (which is somewhat disturbing). It seems you have strong opinions on what should be correct behavior and what is good coding style. How you choose to present those opinions probably matters as to how others will act upon them. Have you accepted that /usr/local isn't going to become the default MSYS installation path? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake2.5 - wrong default install location for mingw
On 10/21/07, Bill Hoffman [EMAIL PROTECTED] wrote: The only case where I would accept /usr/local as the default for make install for msys, is if someone made a native msys version of cmake that linked to the msys run time. That would be a cmake used for creating other msys applications that would install into /usr/local for msys. And the only people who need that, are the MSYS developers themselves. Or people who want to subvert the policies of the MSYS developers and go their own way, har har har! Open Source is never having to say you're sorry. Anyways, before bothering to create a MSYS CMake, it would best to ask the MSYS developers what they want. I predict they will tell you they want no such thing. Perhaps it would help if you explained your use case. Your original email said that the install overwrote your MSVC version of your software. My memory is he said it overwrote his MSVC version of CMake. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake2.5 - wrong default install location for mingw
Bill Hoffman wrote:
Not really true, cygwin has its own symlinks. See here:
http://www.cygwin.com/cygwin-ug-net/using.html
That's not a symlink. That's a mount point.
And it does not effect anything I said. Just try putting such a mount
point on PATH (which is special). It will get translated automatically
whenever you call a DOS or windows app to an actual UNC or DOS path.
Also see here:
http://www.mingw.org/MinGWiki/index.php/Shells%2C%20terminals%20and%20MSYS
Again, no contradiction to what I said. cmake must run from one top
shell or console, regardless of how many are nested. That's the one you
look as reference.
That's why I said looking at the envvar is a hack, while doing it with
win32api is the proper way.
So, even if you figured out what shell you were running from, you
still could not write to /usr/local because that directory does not
exist to a windows program.
No. Did you read what I wrote?
Here's some code which may be easier. I have MSYS and a standalone Ruby
NOT compiled for msys.
$ cat /etc/fstab
c:/msys/1.0/mingw /mingw
c:/ActiveState/perl /perl
$ echo $PATH
/usr/local/bin:/mingw/bin:/bin:/perl
# here i print path from ruby
$ /C/ruby/bin/ruby.exe -e puts ENV['PATH']
C:\msys\1.0\local\bin;c:\msys\1.0\mingw\bin;C:\msys\1.0\bin;c:\ActiveState\perl
# here I find sh.exe in path
$ /C/ruby/bin/ruby.exe -e puts ENV['PATH'].split(';').find {|dir|
File.exists?( dir + '/sh.exe' ) }
C:\msys\1.0\bin
# here I get /usr/local
$ /C/ruby/bin/ruby.exe -e puts ENV['PATH'].split(';').find {|dir|
File.exists?( dir + '/sh.exe' ) } + '../local'
C:\msys\1.0\bin\..\local
Explanation:
Find 'sh.exe' in $PATH. PATH already has a DOS or UNC path from the
MSYS/CYGWIN paths, regardless of how many mount points or 'symlinks'
msys or cygwin uses.
From it, you have /usr/local by doing ../local ( or just .. if sh.exe
happens to weirdly be in (ROOT)/local/bin which you can know from the
word local in it). Under any Unix (Linux) layer, sh.exe is not supposed
to be installed ANYWHERE else and must exist in some form.
MSYS and CYGWIN *MUST* translate PATH to a windows equivalent or else
child programs would not work correctly. Other vars, like
LD_LIBRARY_PATH don't get this special treatment.
--
Gonzalo Garramuño
[EMAIL PROTECTED]
AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake2.5 - wrong default install location for mingw
On 20.10.07 06:17:56, Gonzalo Garramuño wrote: Andreas Pakulat wrote: But exactly that is not supposed to happen. Why not? Maybe I was not clear: Or maybe I didn't read that part of the thread :) cmake2.5 has a MSYS Makefile generator. Aah, ok. I take back all I said. The MSYS Makefile generator of course should follow msys standards and thus accept that this is a posix-environment with paths like /usr/local. I did -G MSYS Makefile and I got an install on $PROGRAMFILES. That's not correct. If I wanted to install in $PROGRAMFILES, there's NMake Makefiles or many of the other Windows specific generators. Or MINGW Makefiles ;) Andreas -- You look tired. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake2.5 - wrong default install location for mingw
Bill Hoffman wrote:
But hey CMake is open source, you can always add the code you want by
yourself.
Here it is... I put some questions in the comments as I'm not that
familiar with the subtleties of some cmake's commands.
You probably want to clean it up. Took me too long to write (love cmake
the make system and docs and platform and flexibility and support, but
its language syntaxtoo much pain for my taste -- i never remember
the commands).
As far as the other stuff...
BTW both cygwin and msys have a ln to create symlinks:
Again, they are NOT symlinks. In the same page you sent me it clearly
specifies that those are not symlinks but get translated to mount points
in /etc/fstab when they are dirs. When they are files, you get a
hardlink (and only if they are on NTFS!). Not the same. At least not
at all to what the Unix world or Wikipedia calls symlinks.
Only with *Windows Vista* you can get actual symlinks in windows, but
cygwin/mingw will likely not benefit from that anytime soon as they link
against an old msvcrt for legal reasons.
Either way, this is offtopic and has *nothing* to do with what I asked.
I am not going to add code into CMake that translates POSIX's paths
into windows paths.
You aren't and I did not ask for that. You are always working with
windows paths. The conversion is handled by MSYS for you in the PATH
variable AUTOMATICALLY.
CMake would have to be a MSYS app to understand MSYS paths.
No. But if you want to make FIND_PATH() and all the others also support
MSYS mount points, be my guest. That's not what I asked for, thou.
Or was all this just a trick to get me to become a cmake developer? :)
Anyway, if you want to go down that path of an MSYS cmake, rather than
linking the cygwin/mingw library, have you considered just parsing
/etc/fstab now that you know where it is as far as windows is
concerned? The big benefit of that is you maintain a single windows
cmake that can generate all types of makefiles.
--
Gonzalo Garramuño
[EMAIL PROTECTED]
AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
Index: Modules/Platform/Windows-gcc.cmake
===
RCS file: /cvsroot/CMake/CMake/Modules/Platform/Windows-gcc.cmake,v
retrieving revision 1.19
diff -r1.19 Windows-gcc.cmake
55a56,109
FILE(TO_CMAKE_PATH $ENV{PROGRAMFILES} PROGRAMFILES )
#
# Q: Should CMAKE_PROJECT_NAME be used instead?
#
SET( PROGRAMFILES ${PROGRAMFILES}/${PROJECT_NAME} )
IF(MSYS AND CMAKE_INSTALL_PREFIX STREQUAL ${PROGRAMFILES})
# MESSAGE( STATUS Find MSYS ROOT )
#
# Attempt to locate MSYS root path by finding sh.exe
# in users' path or from environment variable MSYS_ROOT.
#
IF( NOT MSYS_ROOT )
SET( MSYS_ROOT $ENV{MSYS_ROOT} )
ENDIF( NOT MSYS_ROOT )
IF(NOT MSYS_ROOT)
FIND_PATH( MSYS_ROOT NAMES sh.exe PATHS $ENV{PATH} )
IF( NOT MSYS_ROOT )
MESSAGE( FATAL_ERROR
CMake could not determine MSYS root. Please set MSYS_ROOT )
ENDIF( NOT MSYS_ROOT)
# MESSAGE( STATUS 1 ${MSYS_ROOT} )
IF( MSYS_ROOT MATCHES .*/local/bin )
SET( MSYS_ROOT ${MSYS_ROOT}/.. )
ELSE( MSYS_ROOT MATCHES .*/local/bin )
SET( MSYS_ROOT ${MSYS_ROOT}/../local )
ENDIF( MSYS_ROOT MATCHES .*/local/bin )
# MESSAGE( STATUS 2 ${MSYS_ROOT} )
FILE(TO_CMAKE_PATH ${MSYS_ROOT} MSYS_ROOT)
# MESSAGE( STATUS 3 ${MSYS_ROOT} )
ENDIF(NOT MSYS_ROOT)
#
# CMake BUG: IS_DIRECTORY should be used, but that fails with
# ../ in path.
# Also, it would be better if we normalized the path
# first, but I could not find a function to do so.
#
IF( NOT EXISTS ${MSYS_ROOT} )
MESSAGE( FATAL_ERROR
CMake uses MSYS root ${MSYS_ROOT}. But no ${MSYS_ROOT} on disk. Please create directory or set CMAKE_INSTALL_PREFIX or MSYS_ROOT differently. )
ENDIF( NOT EXISTS ${MSYS_ROOT} )
SET( CMAKE_INSTALL_PREFIX ${MSYS_ROOT} )
ENDIF(MSYS AND CMAKE_INSTALL_PREFIX STREQUAL ${PROGRAMFILES})
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake2.5 - wrong default install location for mingw
Gonzalo Garramuño wrote: Bill Hoffman wrote: But hey CMake is open source, you can always add the code you want by yourself. Here it is... I put some questions in the comments as I'm not that familiar with the subtleties of some cmake's commands. You probably want to clean it up. Took me too long to write (love cmake the make system and docs and platform and flexibility and support, but its language syntaxtoo much pain for my taste -- i never remember the commands). Looks like a nice patch that you can put in your cmakelist files. I still do not think it should go in CMake. I don't think that things built by cmake that are native windows things belong in the /usr/local mount point of msys. If you do, it is easy enough to change your project to install by default in anywhere you want. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake2.5 - wrong default install location for mingw
On 10/19/07, Gonzalo Garramuño [EMAIL PROTECTED] wrote: Brandon Van Every wrote: Agreed, having gone through this debate awhile ago. I would further note that MinGW doesn't require MSYS, and that one would of course expect %ProgramFiles% as the default in that case. Adding MSYS doesn't change the compiler being used, and the MSYS philosophy is as Bill said. So using %ProgramFiles% would make sense there too. Well, if you are not using MSYS with MinGW you expect MinGW to basically NOT be able do any installs. That would be the responsibility of something like DevC++ or the makefile you create. Yeah, but there are Windows Command Prompt versions of make, typically named mingw32-make. You'd expect those to install to %ProgramFiles%, they don't have any /usr/local file system associated with them. Either way, it would also be good if CMake did make a distinction about itself. I really do not like the idea of MinGW by default overwriting my (then stable) MSVC version. I agree. Make a feature request. I just lost half a day trying to restore to a stable build. I recommend Acronis TrueImage. http://www.acronis.com Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake2.5 - wrong default install location for mingw
On 10/19/07, Gonzalo Garramuño [EMAIL PROTECTED] wrote: a) All unix autotools utilities (or other libs like ffmpeg) built under mingw/msys will not install in $PROGRAMFILES, which leads to cmake's approach being totally backwards with the rest of msys. Actually, last I checked 2+ years ago, I was surprised how totally hostile the MSYS developers were to Autotools. Previously I sorta thought the entire point of MSYS was to run the Autotools but apparently they didn't think so. So, as far as I'm concerned, the behavior of Autotools does not in any way define the expectations of MSYS. It would be reasonable for the Autotools to be modified to work with native Windows installation paths as the default. However, the FSF is hostile to Windows, they want it to go away. This is a case of pretending that MSYS is and should be Unix, as opposed to a shell for Windows native development. b) cygwin's approach is sadly bloated and uses a somewhat inefficient approach Complaints about bloat fall on my deaf ears. I'm writing Autoconf GMake -- CMake translators in CMake script! :-) that also forces you to depend on cygwin.dll But yeah, the GPL is a limitation. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake2.5 - wrong default install location for mingw
Gonzalo Garramuño wrote: Compiling CMake HEAD with mingw. After install, it defaulted to installing in $PROGRAMFILES/CMake, instead of /usr/local/ (ie. C:/msys/1.0/usr/local) incorrectly overwriting my MSVC version. That is not a bug. MSYS in its charter explicitly says it does not want to become a new cygwin. The tools in msys are available only for support of the compiler tool chain. The main goal is to build native windows applications with the mingw tool chain. If you want posix applications you should be using cygwin. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake2.5 - wrong default install location for mingw
Bill Hoffman wrote: That is not a bug. MSYS in its charter explicitly says it does not want to become a new cygwin. The tools in msys are available only for support of the compiler tool chain. The main goal is to build native windows applications with the mingw tool chain. If you want posix applications you should be using cygwin. Well, yes, the problem with that theory or that take on mingw's charter is that: a) All unix autotools utilities (or other libs like ffmpeg) built under mingw/msys will not install in $PROGRAMFILES, which leads to cmake's approach being totally backwards with the rest of msys. The proper approach for mingw with cmake should be to detect the environment the user is using. To me the simplest approach to doing that would really be to check if $SHELL is defined. If it is, it should default to a Unix install location of /usr/local (ie MingGW root's /usr/local). If it is not defined, it should default to a windows install of $PROGRAMFILES. b) cygwin's approach is sadly bloated and uses a somewhat inefficient approach that also forces you to depend on cygwin.dll and the microsoft runtimes (mingw only depends on an outdated microsoft runtime). That makes it not suitable for a lot of stuff (Mind you, I've used cygwin for 5+ years to have a basic unix shell environment on windows and for that I'm eternally thankful but mainly because mingw as a shell environment back then was pitiful). Now the combo of mingw-msys has evolved to be a superior solution for me (and I don't need X11 gui tools on windows which mingw will probably never provide, which is how I interpret mingw's charter). -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake2.5 - wrong default install location for mingw
Bill Hoffman wrote: There is no way to tell at cmake time what the user intends to use the code for. If the user of cmake is building a windows app, which is the standard use case for MinGW, then it you don't want /usr/local. I disagree. You can infer how MinGW is being used by looking at the user's environment. /usr/local is more tricky but can also be inferred. More below. The clear goal is to produce native Windows programs, and to support the autotools make toolchain with enough programs to run make in order to produce native windows applications. Okay so far. What you want to do is extend the msys environment with extra POSIX compatible tools. No. I was just trying to compile cmake (or other stuff) under msys and have it behave like all other (subset of) autotools libraries or executables that can be compiled under such environment. All of these get compiled and installed under MSYS's /usr/local root, not under $PROGRAMFILES. To do that cmake would have to link to the MSYS run time library in order to understand things like sym links and mount points. AFAIK, no. If my understanding of MSYS/MinGW is correct, there's no extra POSIX compatibility library. The POSIX compatibility comes from the limited POSIX compatibility provided by the win32api and the msvcrt DLL. This is one of the things it distinguishes it from cygwin, where the cygwin.dll does indeed try to have a 1-to-1 correspondence with POSIX (and some Linux internals too). --- digression--- Currently, neither cygwin nor mingw support sym links (as they are still constrained by what pre-windows vista supports). Cygwin might support mount points other than windows ones (like NFS), but not sure. MinGW certainly does not (only windows A: to Z: drives). The only magic msys utilities like bash perform is modifying the PATH variable for Windows to make /C/ become C:\ and '/' become MSYSROOT\. ---back on topic-- To do what I was suggesting (properly), a MinGW cmake would have to use *Windows API* calls to find what its process is child of (like cmd.exe, command.com, bash.exe, rxvt.exe, etc.) and then act accordingly to that. As that may be tricky to do, I suggested a simpler (somewhat hack) approach of using the environment variable called SHELL which SHOULD be defined under any kind of Unix shell to a valid shell and SHOULD NOT be defined under cmd.exe, command.com or if cmake+mingw gets called directly by some other windows build environment or utility. The TERM environment variable could also probably be used. As far as finding the MSYS root, that is indeed tricky as the MSYS.bat file does not by default seem to define any environment variable for it. Currently the MSYS environment is often installed with InnoSetup and a registry entry for it exists in: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ MSYS-1.0_is1 or similar In the case no installer was used or you don't want to tie yourself to InnoSetup, it can still be inferred from the user environment. For one, the PATH variable HAS to contain the unix utilities somewhere. The path to some common unix utility like 'ls' or 'sh' or 'make' could be used (which should be $MSYSROOT\bin but could also potentially be $MSYSROOT\usr\local\bin). If addition, you probably still want to have an environment variable or CMAKE variable to specify the root of msys in case cmake 'guesses' incorrectly. -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake2.5 - wrong default install location for mingw
Gonzalo Garramuño wrote: What you want to do is extend the msys environment with extra POSIX compatible tools. No. I was just trying to compile cmake (or other stuff) under msys and have it behave like all other (subset of) autotools libraries or executables that can be compiled under such environment. All of these get compiled and installed under MSYS's /usr/local root, not under $PROGRAMFILES. How is a native windows program supposed to write to /usr/local? (see below) To do that cmake would have to link to the MSYS run time library in order to understand things like sym links and mount points. AFAIK, no. If my understanding of MSYS/MinGW is correct, there's no extra POSIX compatibility library. The POSIX compatibility comes from the limited POSIX compatibility provided by the win32api and the msvcrt DLL. This is one of the things it distinguishes it from cygwin, where the cygwin.dll does indeed try to have a 1-to-1 correspondence with POSIX (and some Linux internals too). --- digression--- Currently, neither cygwin nor mingw support sym links (as they are still constrained by what pre-windows vista supports). Cygwin might support mount points other than windows ones (like NFS), but not sure. MinGW certainly does not (only windows A: to Z: drives). The only magic msys utilities like bash perform is modifying the PATH variable for Windows to make /C/ become C:\ and '/' become MSYSROOT\. Not really true, cygwin has its own symlinks. See here: http://www.cygwin.com/cygwin-ug-net/using.html Also see here: http://www.mingw.org/MinGWiki/index.php/Shells%2C%20terminals%20and%20MSYS Firstly: a MSYS application is one that uses (links with) the the MSYS runtime (msys-1.0.dll), just like a Cygwin application However, the key here is that this MSYS environment is just a driver for native Win32 tools such as the MinGW gcc which produces MinGW binaries. 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. They have special files and the cygwin run time knows what to do with them. msys also has mount points and such. For example on my machine: $ mount C:\DOCUME~1\hoffman\LOCALS~1\Temp on /tmp type user (binmode,noumount) C:\msys\1.0\bin on /usr/bin type user (binmode,cygexec,noumount) C:\msys\1.0\bin on /bin type user (binmode,cygexec,noumount) C:\msys\1.0 on /usr type user (binmode,noumount) C:\msys\1.0 on / type user (binmode,noumount) c:\MinGW on /mingw type user (binmode) c: on /c type user (binmode,noumount) Note, that /usr is really c:\msys\1.0. An all native windows program has no idea what /user or /tmp is according to the msys commands. So, there is no way the native windows cmake could write to /usr/local for installing files. So, there is more magic than meets the eye. So, even if you figured out what shell you were running from, you still could not write to /usr/local because that directory does not exist to a windows program. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake2.5 - wrong default install location for mingw
Gonzalo Garramuño wrote: Bill Hoffman wrote: That is not a bug. MSYS in its charter explicitly says it does not want to become a new cygwin. The tools in msys are available only for support of the compiler tool chain. The main goal is to build native windows applications with the mingw tool chain. If you want posix applications you should be using cygwin. Well, yes, the problem with that theory or that take on mingw's charter is that: a) All unix autotools utilities (or other libs like ffmpeg) built under mingw/msys will not install in $PROGRAMFILES, which leads to cmake's approach being totally backwards with the rest of msys. CMake is not an autotools utility. The proper approach for mingw with cmake should be to detect the environment the user is using. To me the simplest approach to doing that would really be to check if $SHELL is defined. If it is, it should default to a Unix install location of /usr/local (ie MingGW root's /usr/local). If it is not defined, it should default to a windows install of $PROGRAMFILES. There is no way to tell at cmake time what the user intends to use the code for. If the user of cmake is building a windows app, which is the standard use case for MinGW, then it you don't want /usr/local. Not only that, but cmake does not even know what /usr/local is, as it does not link to the msys run time. I guess what you really want is an msys version of cmake. This would be much like the cygwin version of cmake, it would be used to build msys binaries. I have not attempted to build such a version of cmake, currently such a thing does not exist. b) cygwin's approach is sadly bloated and uses a somewhat inefficient approach that also forces you to depend on cygwin.dll and the microsoft runtimes (mingw only depends on an outdated microsoft runtime). That makes it not suitable for a lot of stuff (Mind you, I've used cygwin for 5+ years to have a basic unix shell environment on windows and for that I'm eternally thankful but mainly because mingw as a shell environment back then was pitiful). Now the combo of mingw-msys has evolved to be a superior solution for me (and I don't need X11 gui tools on windows which mingw will probably never provide, which is how I interpret mingw's charter). Let's look at the www.mingw.org web page: MinGW: A collection of freely available and freely distributable Windows specific header files and import libraries combined with GNU toolsets that allow one to produce native Windows programs that do not rely on any 3rd-party C runtime DLLs. MSYS: A Minimal SYStem to provide POSIX/Bourne configure scripts the ability to execute and create a Makefile used by make. The clear goal is to produce native Windows programs, and to support the autotools make toolchain with enough programs to run make in order to produce native windows applications. What you want to do is extend the msys environment with extra POSIX compatible tools. To do that cmake would have to link to the MSYS run time library in order to understand things like sym links and mount points. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake2.5 - wrong default install location for mingw
Brandon Van Every wrote: Agreed, having gone through this debate awhile ago. I would further note that MinGW doesn't require MSYS, and that one would of course expect %ProgramFiles% as the default in that case. Adding MSYS doesn't change the compiler being used, and the MSYS philosophy is as Bill said. So using %ProgramFiles% would make sense there too. Well, if you are not using MSYS with MinGW you expect MinGW to basically NOT be able do any installs. That would be the responsibility of something like DevC++ or the makefile you create. Either way, it would also be good if CMake did make a distinction about itself. I really do not like the idea of MinGW by default overwriting my (then stable) MSVC version. I just lost half a day trying to restore to a stable build. -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake2.5 - wrong default install location for mingw
On 10/19/07, Bill Hoffman [EMAIL PROTECTED] wrote: Gonzalo Garramuño wrote: Compiling CMake HEAD with mingw. After install, it defaulted to installing in $PROGRAMFILES/CMake, instead of /usr/local/ (ie. C:/msys/1.0/usr/local) incorrectly overwriting my MSVC version. That is not a bug. MSYS in its charter explicitly says it does not want to become a new cygwin. The tools in msys are available only for support of the compiler tool chain. The main goal is to build native windows applications with the mingw tool chain. If you want posix applications you should be using cygwin. Agreed, having gone through this debate awhile ago. I would further note that MinGW doesn't require MSYS, and that one would of course expect %ProgramFiles% as the default in that case. Adding MSYS doesn't change the compiler being used, and the MSYS philosophy is as Bill said. So using %ProgramFiles% would make sense there too. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMake2.5 - wrong default install location for mingw
Compiling CMake HEAD with mingw. After install, it defaulted to installing in $PROGRAMFILES/CMake, instead of /usr/local/ (ie. C:/msys/1.0/usr/local) incorrectly overwriting my MSVC version. -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
