The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=12022
==
Reported By:Sergiu Michin
Assigned To:
Hi all,
Now that we have released CMake 2.8.4, *now* would be a great time to
prioritize bug fixes for the next release of CMake.
Replies requested. Read on. *Just a short reply with bug numbers* or links
to the bugs is all we need here. Please move specific discussions into the
bugs themselves
I was trying to build a project on a seperate drive from the sources.
This works very well for lots of my projects, and so a cmake based
project should work as well. There is a limitation in cmake using
'command' with working directory
BASE_BUILD_COMMAND is make_gamedata_arch.bat
On 03/28/2011 02:51 PM, Rolf Eike Beer wrote:
I try to do an INSTALL(EXPORT) to allow others to link against one of my
libraries. That libraries is linked against some other internal libraries
the target's don't need to link to as everything in them is purely
internal.
I tried something
On 03/28/2011 02:51 PM, Rolf Eike Beer wrote:
I try to do an INSTALL(EXPORT) to allow others to link against one of my
libraries. That libraries is linked against some other internal
libraries
the target's don't need to link to as everything in them is purely
internal.
I tried something
On Tue, Mar 29, 2011 at 1:58 AM, Michael Hertling mhertl...@online.dewrote:
On 03/29/2011 07:47 AM, Michael Hertling wrote:
On 03/28/2011 08:23 PM, David Doria wrote:
I have setup a list of definitions:
SET(MAIN_BUILD_DEFINITIONS ${MAIN_BUILD_DEFINITIONS} UNIX;)
On 3/29/2011 8:25 AM, David Doria wrote:
(with and without quotes around ${my_definitions} in the
set_target_properties line)
The message command seems to be fine:
my definitions: UNIX;USE_ITK;USE_FLOAT_PIXELS;PIXEL_DIMENSION=1
but the #if defined(UNIX) still fails in the code!
Did you do
Did you do a make VERBOSE=1 to see what was being passed to the compiler?
Yes, none of the definitions are being passed:
http://pastebin.com/X0t0L4Jv
http://pastebin.com/X0t0L4Jv
David
___
Powered by www.kitware.com
Visit other Kitware open-source
On 3/29/2011 8:59 AM, David Doria wrote:
Did you do a make VERBOSE=1 to see what was being passed to the
compiler?
Yes, none of the definitions are being passed:
http://pastebin.com/X0t0L4Jv
http://pastebin.com/X0t0L4Jv
David
Can you create a standalone example of this to make it
Can you create a standalone example of this to make it easier to debug?
add_executable(foo foo.cxx)
...
Bill,
My standalone example works fine: http://pastebin.com/tGjX1AZ8
You can see that the UNIX and DAVID definitions are both passed.
Maybe something is overriding the definitions in my
On 3/29/2011 9:22 AM, David Doria wrote:
My standalone example works fine: http://pastebin.com/tGjX1AZ8
You can see that the UNIX and DAVID definitions are both passed.
Maybe something is overriding the definitions in my real example? I
see these definitions:
D_FILE_OFFSET_BITS=64
On 03/29/2011 05:19 AM, Rolf Eike Beer wrote:
The basic idea is: any symbols from those private libraries are, well,
private. The user only ever sees the symbols from the public library. In
fact he _can't_ even link to the private libraries on Windows as we never
install the .lib files. And
You might want to try running cmake --trace and see if something odd is
happening when it is run.
-Bill
Here is the output of the trace:
http://pastebin.com/MfTcNHFE
It looks like the definitions list is being created and applied to the
target, does it not? (see the last 10 lines of that
On 03/29/2011 02:28 AM, J Decker wrote:
This ends up building a command line that looks like
(On c:)
cd L:\games\spring\cont\base make_gamedata_arch.bat ...
since the current drive is the C drive, this doesn't change the drive,
it only changes the drive on L:, so you'd have to
On 3/29/2011 9:49 AM, David Doria wrote:
You might want to try running cmake --trace and see if something odd is
happening when it is run.
-Bill
Here is the output of the trace:
http://pastebin.com/MfTcNHFE
It looks like the definitions list is being created and applied to the
target, does
Most likely coming from here:
/home/doriad/src/CMake/Modules/UsewxWidgets.cmake(72): SET(CMAKE_CXX_FLAGS
${CMAKE_CXX_FLAGS} ${wxWidgets_CXX_FLAGS} )
I added:
message(CMAKE_CXX_FLAGS: ${CMAKE_CXX_FLAGS})
and the output is:
CMAKE_CXX_FLAGS: -pthread -ftemplate-depth-50 -Wall -Wno-deprecated
Hi,
We ran into an issue using CMake with our fortran project. We have
constructions such as:
...
#ifdef OPTION1
USE Module1
#else
USE Module2
#endif
...
It's not actually finding modules as dependencies. Any thoughts? I am using
version 2.8.1, I can try to upgrade if somebody thinks it
Hi Alex,
Thanks for the change. The version you sent didn't end up working here (with
just a CXX project). The line to set the compiler is checking for CXX but,
at least on my system, ${_lang} is set to c++. Once I changed the line to
check for CXX or c++, it worked fine. I also noticed
Hi all,
Now that we have released CMake 2.8.4, *now* would be a great time to
prioritize bug fixes for the next release of CMake.
Replies requested. Read on. *Just a short reply with bug numbers* or links
to the bugs is all we need here. Please move specific discussions into the
bugs themselves
http://public.kitware.com/Bug/view.php?id=11206
John
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
2011/3/29 David Cole david.c...@kitware.com:
Please discuss issues here as needed, and add notes to existing issues in
the bug tracker that you are interested in seeing fixed for 2.8.5 -- we will
be looking at the mailing list and activity in the bug tracker to help
prioritize the bug fixes
Eric, those all look good, but I'd like to particularly +1 this one:
http://public.kitware.com/Bug/view.php?id=8438
I've hacked around this deficiency in several places and I'm sure
other users have as well. It would be nice to replace these hacks with
a nice simple solution.
Thanks,
tyler
On
On 2011-03-29 13:56-0400 David Cole wrote:
Hi all,
Now that we have released CMake 2.8.4, *now* would be a great time to
prioritize bug fixes for the next release of CMake.
Replies requested. Read on. Just a short reply with bug numbers or links to
the bugs is all we need here. Please move
On 03/29/2011 11:53 AM, Tim Gallagher wrote:
Hi,
We ran into an issue using CMake with our fortran project. We have
constructions such as:
...
#ifdef OPTION1
USE Module1
#else
USE Module2
#endif
...
It's not actually finding modules as dependencies. Any thoughts?
Are those
I'll third that. I'd like to see 8438 addressed as well.
-Mike
On 03/29/2011 02:56 PM, Tyler wrote:
Eric, those all look good, but I'd like to particularly +1 this one:
http://public.kitware.com/Bug/view.php?id=8438
I've hacked around this deficiency in several places and I'm sure
other
On Tue, 29 Mar 2011 13:56:03 -0400, David Cole said:
Now that we have released CMake 2.8.4, *now* would be a great time to
prioritize bug fixes for the next release of CMake.
http://public.kitware.com/Bug/view.php?id=11746
--
Sean
On 03/29/2011 04:14 PM, David Doria wrote:
Most likely coming from here:
/home/doriad/src/CMake/Modules/UsewxWidgets.cmake(72): SET(CMAKE_CXX_FLAGS
${CMAKE_CXX_FLAGS} ${wxWidgets_CXX_FLAGS} )
I added:
message(CMAKE_CXX_FLAGS: ${CMAKE_CXX_FLAGS})
and the output is:
CMAKE_CXX_FLAGS:
Am Dienstag, 29. März 2011, 09:41:36 schrieb Brad King:
On 03/29/2011 05:19 AM, Rolf Eike Beer wrote:
The basic idea is: any symbols from those private libraries are, well,
private. The user only ever sees the symbols from the public library. In
fact he _can't_ even link to the private
They are listed as dependencies for the target, ie:
add_executable(myexe Module1.F90)
or
add_executable(myexe Module2.F90)
depending on whether OPTION1 is defined or not (really, there's an
option(USE_OPTION1) etc).
The actual project is way more complicated than this -- we store the
An inspection of your CMakeLists.txt file [1] and the outputs
of make VERBOSE=1 [2,3] reveals the following goings-on:
In [2], the lines 13 and 16 generate the object files
CMakeFiles/Tech.dir/src/tech/Pch.cpp.o
CMakeFiles/Tech.dir/src/tech/tech/Atomic.cpp.o
and obviously, these are
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 28a8d3af3a9700fd7d0b91b8d39b5938b9724b9f (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 32997e7cb840b023ce7be8c1a2b523ae65bd5c38 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 72dd36e628a8ad7500a7ffbbecdc17d49836b9a9 (commit)
from
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via cb6c118336b318547e8a936e3496d6262df1cccf (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 23e8306e7faa461300bb51f3922305db49613f51 (commit)
from
35 matches
Mail list logo
