Re: [CMake] environment variables and visual studio
Sylvain Benner wrote: Is there any way for CMake to set environment variables which can be picked up in Visual Studio's pre/post-build steps? I'm working on a system where I've got a couple of studio project included via the INCLUDE_EXTERNAL_MSPROJECT(), and I would like to be able to refer to things like CMAKE_BINARY_DIR, so that the external msprojects can put their output relative to the CMake build dir. You can still generate the projects you are including with the INCLUDE_EXTERNAL_MSPROJECT. It make sense since they are part of your CMake framework (you want to rely on CMake variables). No, I can't. The reason I don't generate them is that they have to be portable since they are shipped to customers as a part of an SDK, and as I understand it the project files CMake generates are not portable/movable (due to absolute paths, etc). At start, it can be a lot of work to write the CMakeLists.txt for each projects but you need to do it only once. I actually had CMakeLists.txt for the projects, but had to discard them for the reason above. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] environment variables and visual studio
Bill Hoffman wrote: Jesper Eskilson wrote: Is there any way for CMake to set environment variables which can be picked up in Visual Studio's pre/post-build steps? I'm working on a system where I've got a couple of studio project included via the INCLUDE_EXTERNAL_MSPROJECT(), and I would like to be able to refer to things like CMAKE_BINARY_DIR, so that the external msprojects can put their output relative to the CMake build dir. No, this is not possible. CMake is no longer running when the project is built. I do not think there is a way to set variables in the .sln file which is where they would have to be set. I was afraid you might say that. Oh, well, I'll have to think of another solution. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Caching calculated values.
-Original Message-
From: Amitha Perera [mailto:[EMAIL PROTECTED]
Sent: 22 October 2007 18:53
To: Josef Karthauser
Cc: cmake@cmake.org
Subject: Re: [CMake] Caching calculated values.
On Mon 22 Oct 2007, Josef Karthauser wrote:
As each set of calculations are connected to a single CMakeList.txt
file, it should be possible to avoid recalculating, and useing
cached
values where possible. In order to do that however I need to know
whether a CMakeLists.txt file is stale, with respect to the last
time
it
ran, or not. Is there an easy way for me to determine from within a
CMakeLists.txt file, whether it is out-of-date?
In the VXL project, we use a serial number for that purpose.
Something like
# The serial number below will allow the maintainers to force builds
# to update cached results. Whenever you make a change that makes it
# necessary for cached values to be updated, increment the serial
# number. The format follows a DNS-style numbering: the current date
# followed by a modification time within the day.
#
SET( VXL_CONFIG_SERIAL_CURRENT 2006-16-03-002 )
In the end I've come up with a method based around dropping a file in
each project build directory, and then comparing its time stamp with
that of the associated CMakeLists.txt file. Instead of calling PROJECT,
I just call GEO_PROJECT. This then manages the correct setting of the
relevant USE_CACHE setting for each project, which is utilised elsewhere
by the code that needs to avoid doing the work.
Joe
MACRO(GEO_PROJECT PROJECTNAME)
PROJECT(${PROJECTNAME})
DEBUG_MESSAGE(GEO_CACHE_VERBOSE Configuring project
${PROJECTNAME})
# We record the source files in per-project source variablesa
# with this prefix.
SET(GEO_SOURCE GEO_SOURCE_${PROJECTNAME})
# Create the cache file.
SET(GEO_CACHE_FILE ${PROJECT_BINARY_DIR}/source.cached)
# If cached file exists, and is younger than CMakeLists.txt then
# use the cache.
SET(${GEO_SOURCE}_USE_CACHE 0)
IF(EXISTS ${GEO_CACHE_FILE})
DEBUG_MESSAGE(GEO_CACHE_VERBOSE Cache exists)
DEBUG_MESSAGE(GEO_CACHE_VERBOSE Cmakelists file:
${PROJECT_SOURCE_DIR} CMakeLists.txt)
DEBUG_MESSAGE(GEO_CACHE_VERBOSE Geocache file:
${GEO_CACHE_FILE})
IF(NOT ${PROJECT_SOURCE_DIR}/CMakeLists.txt IS_NEWER_THAN
${GEO_CACHE_FILE})
DEBUG_MESSAGE(GEO_CACHE_VERBOSE CMakelists newer)
SET(${GEO_SOURCE}_USE_CACHE 1)
ENDIF(NOT ${PROJECT_SOURCE_DIR}/CMakeLists.txt IS_NEWER_THAN
${GEO_CACHE_FILE})
ENDIF(EXISTS ${GEO_CACHE_FILE})
DEBUG_MESSAGE(GEO_CACHE_VERBOSE Use cache:
${${GEO_SOURCE}_USE_CACHE})
# If not using the cache, then erase the previously cached list
# and start again.
IF(NOT ${GEO_SOURCE}_USE_CACHE)
# Clear the file names
SET(${GEO_SOURCE} CACHE INTERNAL FORCE)
FOREACH(PFORM ${ALL_PLATFORMS})
SET(${GEO_SOURCE}_${PFORM} CACHE INTERNAL FORCE)
ENDFOREACH(PFORM)
# Create the cache file.
MESSAGE((Re-)Configuring project ${PROJECTNAME})
FILE(WRITE ${GEO_CACHE_FILE} Cache exists)
ELSE(NOT ${GEO_SOURCE}_USE_CACHE)
DEBUG_MESSAGE(GEO_CACHE_VERBOSE \tUsing cached file list)
ENDIF(NOT ${GEO_SOURCE}_USE_CACHE)
ENDMACRO(GEO_PROJECT)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] environment variables and visual studio
No, I can't. The reason I don't generate them is that they have to be portable since they are shipped to customers as a part of an SDK, and as I understand it the project files CMake generates are not portable/movable (due to absolute paths, etc). You can generate relative paths with the following switch CMAKE_USE_RELATIVE_PATHS. We managed to have portable generated projects that we can ship. After the CMake pass it should be no difference between a generated project and a manually constructed project. In fact CMake assure that the projects are consistent since it's an automated process, I encourage you to use CMake for all your projects. --Sylvain ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Selecting compiler on Windows platform
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Josef Karthauser
Sent: 22 October 2007 13:59
To: [EMAIL PROTECTED]; cmake@cmake.org
Subject: RE: [CMake] Selecting compiler on Windows platform
However, I’d like to control this from within a CMake file, and
this
doesn’t appear possible. From what I can see,
CMakeDetermineCXXCompiler is
loaded and executed prior to the CMakeLists.txt file, which means
that I
cannot set the compiler internally. Is this true,
Yes, this is true.
One reason is that one build tree must not use several compilers for
one language, because all the configure checks are global for one
build tree and so the results are only correct for the compiler which
was used when they were executed.
This seems overly restrictive, a tree might contain a number of sub-
trees which use different compilers. Whilst I understand the need to
keep things consistent by default, if a user wants to shoot themselves
in the foot it ought to be allowed. (Tools not policy! :)
I guess I'm going to have to run CMakeDetermineCXXCompiler again
myself. :/.
For the record, I've solved the problem by setting the environment variables
that I require and then running the the determine and test modules again, like
so:
SET(ENV{CC} gcc)
SET(ENV{CXX} g++)
INCLUDE(CMakeDetermineCCompiler)
INCLUDE(CMakeDetermineCXXCompiler)
INCLUDE(CMakeTestCCompiler)
INCLUDE(CMakeTestCXXCompiler)
This appears to work, although it of course doesn't disable the initial
automatic compiler test.
Joe
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Re: Re: Re: Hyperlinked indexed reference?
On Tuesday 23 October 2007 00:51, Fernando Cacciola wrote: Hi Bill, Just create a patch and send it to me. OK. Here's a patch for cmDocumentationFormatterHTML.cxx It adds, at the beginning of each section, a list with hyperlinks to each entry in it. Unfortunately, adding a similar list to the whole document is more difficult given the current documentation arquitecture, so it will take me some more (free) time to di it, but this is a good start. At least within each section you can easily see all entries (options,commands,properties,modules) at once, and jump directly to the one you are interested in. Can you also try to add this for the man pages (i.e. emphasizing instead of links) ? Bye Alex ___ 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: 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
[CMake] Native Pathsupport under Windows
Hello List,
I need to use under windows the buildin commands of the shell. But when I run
these commands they doesn't work correctly, because the windows commands doen't
like the slashes (/). It seems to me that they want to get backslashes (\).
A example:
ADD_CUSTOM_COMMAND(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/image.h
COMMAND copy
${CMAKE_CURRENT_BINRAR_DIR}/image.h+${CMAKE_CURRENT_BINARY_DIR}/test.h
${CMAKE_CURRENT_BINRAR_DIR}/image.h)
Then the shell says:
copy C:/Projects/build/image.h+C:/Projects/build/test.h
C:/Projects/build//image.h
The syntax of the command is incorrect.
Do i the same in a command line with normal windows backslashes in paths, then
everything is fine.
BTW. I do that with the buildin copy, because in the documentation at
file(append) there is a note which says, i am not allowed to use the generated
file as an input. But i need that generated file to compile my lib.
1. Is there a possiblity to get backslashes instead of slashes as paths?
2. Maybe is there a better way to solve that kind of problem?
Thanks for all your help
Greetings
Alexander
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Native Pathsupport under Windows
[EMAIL PROTECTED] wrote: I need to use under windows the buildin commands of the shell. But when I run these commands they doesn't work correctly, because the windows commands doen't like the slashes (/). It seems to me that they want to get backslashes (\). 1. Is there a possiblity to get backslashes instead of slashes as paths? FILE(TO_NATIVE_PATH ...) -Torsten This e-mail and any files sent with it contain information that may be privileged or confidential and is the property of the GateHouse Group. This information is intended solely for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use the message or any part thereof. If you have received this e-mail in error, please notify the sender immediately, and delete all copies of this message. In accordance with GateHouse Security Policy, e-mails sent or received may be monitored. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Selecting compiler on Windows platform
-Original Message-
From: Josef Karthauser
Sent: 23 October 2007 10:29
To: Josef Karthauser; [EMAIL PROTECTED]; cmake@cmake.org
Subject: RE: [CMake] Selecting compiler on Windows platform
This seems overly restrictive, a tree might contain a number of sub-
trees which use different compilers. Whilst I understand the need to
keep things consistent by default, if a user wants to shoot
themselves
in the foot it ought to be allowed. (Tools not policy! :)
I guess I'm going to have to run CMakeDetermineCXXCompiler again
myself. :/.
For the record, I've solved the problem by setting the environment
variables that I require and then running the the determine and test
modules again, like so:
SET(ENV{CC} gcc)
SET(ENV{CXX} g++)
INCLUDE(CMakeDetermineCCompiler)
INCLUDE(CMakeDetermineCXXCompiler)
INCLUDE(CMakeTestCCompiler)
INCLUDE(CMakeTestCXXCompiler)
This appears to work, although it of course doesn't disable the initial
automatic compiler test.
Actually, this doesn't work. :/ By this time CMake has automatically noticed
that I have a working CL.exe in the path, and setup for it. When I then change
to gcc, and rerun the Determine and Test scripts it still has a number of
variables set which it got by running the Visual C configuration stuff - this
causes the later stages of configuration to fail. :/
So I tried another thing, basically setting the correct environment variables
from within CMake, and then shelling out to a new CMake to do the correct
configuration, like so:
# Set correct environment variables, depending upon platform and
configuration type, etc.
CONFIGURE_COMPILER()
# Re-invoke cmake with the correct compiler set populate the build tree
IF(NOT GEO_INNER_CMAKE AND NOT GEO_CONFIGURED)
EXEC_PROGRAM(${CMAKE_COMMAND}
ARGS -DGEO_INNER_CMAKE=1
-DCMAKE_BUILD_TYPE=\${CMAKE_BUILD_TYPE}\
-G \${CMAKE_GENERATOR}\ ${CMAKE_HOME_DIRECTORY}
)
SET(GEO_CONFIGURED 1 CACHE INTERNAL FORCE)
MESSAGE(FATAL_ERROR CMake configure internal loop and exited.)
ENDIF(NOT GEO_INNER_CMAKE AND NOT GEO_CONFIGURED)
MESSAGE(Inner loop got here.)
ADD_SUBDIRECTORIES(...) etc.
However now this doesn't work, because although the inner cname does configure
correctly and run, the outer one blats the cache file when it exists with the
FATAL_ERROR and unconfigures all the projects. :/.
Is there a way of causing CMake to exit without touching the cache, so that I
can use it to drive an internal cmake?
Either that, or what is the correct sequence of modules to run internally, once
I've set the correct environment variables, to get it to reconfigure the
compiler.
I'd really appreciate some help with this.
The problem I'm trying to solve is how to set up a number of
configurations/build trees, each configured for a different compiler, from a
single source tree. I want to describe the compilers from within CMake;
obviously I could create an external batch file, but then I'd have some
compiler stuff (like library paths, include paths, etc) in the CMakeLists.txt
file, and some info like ENV{PATH}, ENV{CC}, ENV{CXX} in the batch file. I
really want it all in a single place.
Thanks,
Joe
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Native Pathsupport under Windows
Hi,
I need to use under windows the buildin commands of the shell. But
when I run these commands they doesn't work correctly, because the
windows commands doen't like the slashes (/). It seems to me that
they want to get backslashes (\).
1. Is there a possiblity to get backslashes instead of slashes as
paths?
FILE(TO_NATIVE_PATH ...)
When I do a FILE(TO_NATIVE_PATH ${CMAKE_CURRENT_BINARY_DIR} RESULT)
and then use ${RESULT} I get the whole again with slashes.
So I can't use that with custom_command:
ADD_CUSTOM_COMMAND(...
COMMAND copy ${RESULT}\\image.h+${RESULT}\\test.h ${RESULT}\\image.h
VERBATIM)
Even without VERBATIM I get both times the already given error.
Greetings
Alexander
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Native Pathsupport under Windows
On Oct 23, 2007, at 7:13 AM, Torsten Martinsen wrote:
[EMAIL PROTECTED] wrote:
FILE(TO_NATIVE_PATH ...)
When I do a FILE(TO_NATIVE_PATH ${CMAKE_CURRENT_BINARY_DIR} RESULT)
and then use ${RESULT} I get the whole again with slashes.
So I can't use that with custom_command:
ADD_CUSTOM_COMMAND(...
COMMAND copy ${RESULT}\\image.h+${RESULT}\\test.h ${RESULT}\\image.h
VERBATIM)
To copy files, use ${CMAKE_COMMAND} -E copy.
He doesn't just want to copy files, he wants to concatenate two files
(copy file1+file2 destfile). I doesn't look like cmake provides a
built in cmake -E command for that.
One possibility is to use a separate cmake script to do the
concatenation and run it as a command:
cmake_concatenate.cmake
EXECUTE_PROCESS( COMMAND ${CMAKE_COMMAND} -E copy ${FILE1} $
{DEST_FILE})
FILE(READ ${FILE2} file2_contents)
FILE(APPEND ${DEST_FILE} ${file2_contents})
call it from regular CMakeLists.txt file
COMMAND ${CMAKE_COMMAND}
ARGS -P cmake_concatenate.cmake -DFILE1:STRING=${RESULT}/image.h -
DFILE2:STRING=${RESULT}/test.h -DDEST_FILE:STRING=${RESULT}/image.h
In this particular case the destination and the first source file are
the same, so a modified cmake_concatenate.cmake file could be more
appropriate.
James
___
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/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
[CMake] Warning level change when going from 2.4.6 to 2.4.7
After upgrading CMake from 2.4.6 to 2.4.7, the warning level on Windows is now 3 instead of 4. Running CMakeSetup in clean build directory results in projects having warning level 3. Going back to CMake 2.4.6 fixes the problem (warning level is 4). Is there something new in 2.4.7 that causes that? -- Artur Kedzierski ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CTest patch
Hi, I made few changes to CTest concerning SVN support. I added support for the french SVN output so that it can handles revision number, automatic updates and etc. I also changed some routine that I think were defectives. Please leave me your comments/suggestions and test the english version so I didn't break anything. Regards, Félix C. Morency cmCTestUpdateHandler.cxx.patch Description: Binary data ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CTest patch
Félix C. Morency wrote: Hi, I made few changes to CTest concerning SVN support. I added support for the french SVN output so that it can handles revision number, automatic updates and etc. I also changed some routine that I think were defectives. Please leave me your comments/suggestions and test the english version so I didn't break anything. Can you please attach the patch to the bug in the bug tracker? Thanks. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMakeSetup requires elevation on Vista
I'm experiencing the same problem as in bug #5072
(http://www.vtk.org/Bug/view.php?id=5072), regarding requiring CMake
requiring elevation on Vista ('run as administrator').
The problem lies in the fact that the build scripts/directories are
owned by the administrator, which means that Visual Studio won't own
the files, or directories (e.g. problematic if the runtime creates
temporary files in the build directories).
A solution has been reported in the bug reports, but it doesn't seem
to be incorporated into the latest CMake version. Does anyone have
more details?
--
Nico Galoppo :: http://www.ngaloppo.org
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMakeSetup requires elevation on Vista
Nico Galoppo wrote:
I'm experiencing the same problem as in bug #5072
(http://www.vtk.org/Bug/view.php?id=5072), regarding requiring CMake
requiring elevation on Vista ('run as administrator').
The problem lies in the fact that the build scripts/directories are
owned by the administrator, which means that Visual Studio won't own
the files, or directories (e.g. problematic if the runtime creates
temporary files in the build directories).
A solution has been reported in the bug reports, but it doesn't seem
to be incorporated into the latest CMake version. Does anyone have
more details?
The fix is in CVS CMake, but you have to build CMake with VS 8. The
next release of CMake will have this fix in it.
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] MinGW broken on Vista
If you try to run CMakeSetup with MinGW on Windows Vista, and you get a screenful of errors including a line: gcc.exe: installation problem, cannot exec `cc1': No such file or directory it's not you and it's not CMake. MinGW's gcc 3.4.5 is fundamentally broken under Vista. I've been chasing around the mailing list archives and it looks like it won't be officially fixed until MinGW ships gcc 4.2.0. Unofficially, you can get a patched set of driver files. http://dessent.net/tmp/gcc-vista-3.4.5-20060117-1.tar.gz YMMV as to how well they work. They do get me past the cannot exec cc1 problem but I don't have any other experience with them so far. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMakeSetup requires elevation on Vista
On 10/23/07, Bill Hoffman [EMAIL PROTECTED] wrote: The fix is in CVS CMake, but you have to build CMake with VS 8. The next release of CMake will have this fix in it. Is VS8 a temporary or permanent requirement? If permanent, are there guards to keep people from building CMake with earlier versions of VS? I don't think we want a proliferation of Windows .exe's. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CTest patch
Am Dienstag 23 Oktober 2007 schrieb Félix C. Morency: I made few changes to CTest concerning SVN support. I added support for the french SVN output so that it can handles revision number, automatic updates and etc. I also changed some routine that I think were defectives. Please leave me your comments/suggestions and test the english version so I didn't break anything. Is the output dependent on the locale? If yes, wouldn't is make more sense to run svn in an English locale instead of adding countless languages? HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Native Pathsupport under Windows
On 10/23/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi,
I need to use under windows the buildin commands of the shell. But
when I run these commands they doesn't work correctly, because the
windows commands doen't like the slashes (/). It seems to me that
they want to get backslashes (\).
1. Is there a possiblity to get backslashes instead of slashes as
paths?
FILE(TO_NATIVE_PATH ...)
When I do a FILE(TO_NATIVE_PATH ${CMAKE_CURRENT_BINARY_DIR} RESULT)
and then use ${RESULT} I get the whole again with slashes.
You have found a bug, which I have filed as
http://cmake.org/Bug/view.php?id=5939
FILE(TO_NATIVE_PATH ${CMAKE_CURRENT_SOURCE_DIR} native_srcdir)
MESSAGE(${native_srcdir})
under a MinGW Makefiles generator produces
C:/devel/src/bugs/native. This is wrong. A Visual Studio 8 2005
generator produces C:\devel\src\bugs\native, the correct result.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
