On 11/10/2010 01:17 AM, James Bigler wrote:
> I have a build rule that copies files from the source tree to the build
> tree:
>
> foreach( script ${scripts} )
> set( src "${CMAKE_CURRENT_SOURCE_DIR}/${script}" )
> set( dest "${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/${script}" )
> list( APPEND dest
I have a question regarding removing prior entries from include_directories.
Specifically, in a CMakeLists.txt, I have several targets. For example:
# target 1
include_directories(x y z)
add_executable(my_exe ...)
#target 2
include_directories(a b c)
add_executable(my_exe2 ...)
#target 3
I have a build rule that copies files from the source tree to the build
tree:
foreach( script ${scripts} )
set( src "${CMAKE_CURRENT_SOURCE_DIR}/${script}" )
set( dest "${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/${script}" )
list( APPEND dest_files "${dest}" )
add_custom_command(
OUTPUT "${des
Michael Hertling said the following on 11/6/2010 7:39 AM:
stored in the ${CMAKE_BINARY_DIR}/filelist.dat script as an assignment
to the variable FILELIST. Subsequently, this filelist.dat is read via
INCLUDE(), so CMake keeps track of it, i.e. changing the filelist.dat
results in a rebuild. Finall
Eric Noulard said the following on 11/6/2010 6:20 AM:
Initially it may be a pain to list them but after a while its generally better
to manually keep track of file (dis)appearing in your source tree.
(which is usually what you do when using an IDE without CMake)
I.e. if those files are/were adde
On 11/07/2010 03:37 PM, luxInteg wrote:
> On Sunday 07 November 2010 11:34:47 Richard Wackerbarth wrote:
>> First let me suggest that you word your request in a more complete manner.
>> What "does not work"?
> cant get an executable generated because the 'COMMAND' syntax is incorrect"
> so could
On 11/9/2010 8:03 AM, Brad King wrote:
Taking out the new AdditionalOptions=" /W1 /libs:dll /threads" allowed
the project to succeed.
The regression was introduced here:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=20f49730
So, you should be able to get a temporary fix by reverting
Hi All,
sorry for taking so much time for this wimpy problem. I think I found the issue
and it's simple as always.
See some small comments inline
On 09.11.2010, at 03:28, Alan W. Irwin wrote:
> On 2010-11-09 02:52+0100 Michael Hertling wrote:
>
>> On 11/08/2010 10:03 PM, Jochen Issing wrote:
>
On Sun, Nov 7, 2010 at 8:29 PM, Luigi Calori wrote:
> On 07/11/2010 21.01, Philip Lowman wrote:
>
> On Fri, Nov 5, 2010 at 12:08 PM, Luigi Calori wrote:
>
>> +1 for FindBoost support to "CMakeified" version of Boost at "
>>> http://gitorious.org/~denisarnaud/boost/denisarnauds-zeuners-boost-cm
On 11/8/2010 3:54 PM, Allen D Byrne wrote:
>The projects do differ in the VFFortranCompilerTool option of the project
> file
>
> DEBUG:
>
> AdditionalOptions=" /W1 /libs:dll /threads /dbglibs" instead of
> AdditionalOptions=" /dbglibs"
>
> RELEASE:
>
> AdditionalOptions=" /W1 /libs:dll /th
I have a project containing a few MIDL files that has been working
fine using the "Visual Studio 9 2008" generator. I have been migrating
the project over to Visual Studio 2010 which includes using the cmake
"Visual Studio 10" generator. However the resultant Visual Studio 2010
files do not seems t
On Mon, 2010-11-08 at 18:28 -0800, Alan W. Irwin wrote:
> On 2010-11-09 02:52+0100 Michael Hertling wrote:
>
> > On 11/08/2010 10:03 PM, Jochen Issing wrote:
> >> Hi list,
> >>
> >> I tried to add ctest to my project and did this by adding
ENABLE_TESTING() and several ADD_TEST(...) to my CMakeList
12 matches
Mail list logo
