Hi,
Apologies if this has been answered before. In an effort to ensure
cross-platform consistent results, I need to force some (C++ and
Fortran) source files to always be built debug. Is there any easy
syntax to do this?
I build our libraries like this.
SET(SRCS
${EXEC_DIR}/AfterStep
Hello, In many cmake modules, I see <> used around names, as in:
SET(CMAKE_C_COMPILE_OBJECT " -o
-c ")
What does this notation mean? I looked around but missed
this in the documentation.
Thanks,
-steve
___
Powered by www.kitware.com
Visit ot
I found that when using the FindBoost.cmake and using the Boost_USE_STATIC_LIBS
option, it wouldn't find the static libs in my C:\Boost\libs folder. It kept
coming back with files ending in -gd libs instead of -sgd libs even though the
option Boost_USE_STATIC_LIBS was set. I found that it had
On 9/2/2010 1:43 PM, Ingolf Steinbach wrote:
Hi,
2010/9/2 Ryan Pavlik:
Set the appropriate variables at the top of the CMakeLists.txt file of the
given subdirectory. Each add_subdirectory call creates a new scope, so
variables set in sub-directories do not propagate to parents unless
specif
Hi,
2010/9/2 Ryan Pavlik :
> Set the appropriate variables at the top of the CMakeLists.txt file of the
> given subdirectory. Each add_subdirectory call creates a new scope, so
> variables set in sub-directories do not propagate to parents unless
> specifically told to.
But which variables woul
Set the appropriate variables at the top of the CMakeLists.txt file of
the given subdirectory. Each add_subdirectory call creates a new scope,
so variables set in sub-directories do not propagate to parents unless
specifically told to.
Hope this helps!
Ryan
On 9/2/2010 11:11 AM, Ingolf Ste
find_program(CONFIG_EXECUTABLE NAMES my-config PATHS
${CONFIG_EXECUTABLE_PATH} NO_DEFAULT_PATH)
Looks good, should work.
Alternately, must I simply set the path to the program using the
following command?
set(CONFIG_EXECUTABLE, ${CONFIG_EXECUTABLE_PATH}/my-config)
You can do that too.
You
On Thursday 02 September 2010, Andreas Pakulat wrote:
> Hi,
>
> I've got a small problem here, I'm building an installing a static
> library which links (among other things) against QtCore. I'm also using
> the cmake install(TARGETS .. EXPORT) stuff to export a Target.cmake file
> with the library
On Wednesday 01 September 2010, Nicholas Kinar wrote:
> Hello,
>
> Suppose that I have a program (named "my-config") that is on the *NIX
> system path, and I have another version of the program (also named
> "my-config") in a sub-folder of the HOME directory.
>
> How would I use the find_program(
On Thursday 02 September 2010, Raymond Wan wrote:
> Hi Chiheng,
>
> On Thu, Sep 2, 2010 at 16:15, Chiheng Xu wrote:
> > CMake is a very great tool. But its drawback is also obvious. It
> > will consume large amount of time to generate Makefiles every time you
> > want to build, especially f
Nevermind, carry on - I realized that all I had to do was set
CMAKE_INSTALL_PREFIX to "" at the beginning of the file - it's "off"
for the Find* routines and re-set by the end of the process.
CY
On 9/2/10, Clifford Yapp wrote:
> I have a setup in CMake where I am deliberately re-setting a few
>
Hi,
how can link flags be modified (augmented) for *all* targets within a
given sub-directory (recursively) of a project? To clarify: I do not
want to modify the project-wide link flags. Just for a certain part
within the project.
Kind regards
Ingolf
__
On 02.09.10 17:02:02, Diablo 666 wrote:
>
> > I think what Andreas meant is that he expects IDE's to use CMake
> > as their native build system and auto-generate the CMake code.
>
> Exactly. AFAIK KDevelop 4 is actually building cmake files.
It doesn't, it tries to help you write them and even s
On 2. Sep, 2010, at 17:02 , Diablo 666 wrote:
>
>> I think what Andreas meant is that he expects IDE's to use CMake
>> as their native build system and auto-generate the CMake code.
>
> Exactly. AFAIK KDevelop 4 is actually building cmake files. But I didn't
> see a working version of it, yet :
> I think what Andreas meant is that he expects IDE's to use CMake
> as their native build system and auto-generate the CMake code.
Exactly. AFAIK KDevelop 4 is actually building cmake files. But I didn't
see a working version of it, yet :(
__
On 2. Sep, 2010, at 16:54 , Bill Hoffman wrote:
> On 9/2/2010 10:44 AM, Diablo 666 wrote:
>> Hi,
>>
>> > For example, when you add a C++ source file,
>> > you'll need to run cmake and then make.
>>
>> make will automatically re-run cmake, if the cmake files have changed.
>> I guess, there will
On 9/2/2010 10:44 AM, Diablo 666 wrote:
Hi,
> For example, when you add a C++ source file,
> you'll need to run cmake and then make.
make will automatically re-run cmake, if the cmake files have changed.
I guess, there will be some IDEs automatically generating cmake files in
the future.
Th
Hi,
> For example, when you add a C++ source file,
> you'll need to run cmake and then make.
make will automatically re-run cmake, if the cmake files have changed.
I guess, there will be some IDEs automatically generating cmake files in the
future.
> generate n Makefiles so that each CPU is re
I have a setup in CMake where I am deliberately re-setting a few
variables to NOTFOUND in macros in order to allow an option change to
re-populate them. Unfortunately, I have run into a rather curious
behavior that I'm not quite sure how to disable.
The FIND_* routines on the first configure pass
Hi Chiheng,
On Thu, Sep 2, 2010 at 16:15, Chiheng Xu wrote:
> CMake is a very great tool. But its drawback is also obvious. It
> will consume large amount of time to generate Makefiles every time you
> want to build, especially for ultra large projects. Building can be
> parallelized, b
On Thu, Sep 2, 2010 at 10:08, Michael Wild wrote:
> Ever timed "gcc -M" which is the usual approach to dependency-generation of
> hand-crafted Makefiles? THAT is slow. ;-)
It's also correct, which requires preprocessing all the headers.
gcc -MMD will do the same as a side-effect of the build so
On 2. Sep, 2010, at 10:04 , Mike McQuaid wrote:
>
> On 2 Sep 2010, at 08:49, Chiheng Xu wrote:
>
>> Suppose you have a ultra large project, it will consume 5 minutes to
>> CMake, 2 hours to build serially. If you have an 64 Cores ccNUMA
>> systems, like Xeon 7500 (8 Cores * 8), theretically
On 2 Sep 2010, at 08:49, Chiheng Xu wrote:
> Suppose you have a ultra large project, it will consume 5 minutes to
> CMake, 2 hours to build serially. If you have an 64 Cores ccNUMA
> systems, like Xeon 7500 (8 Cores * 8), theretically, you will have a
> 60+ accelaration in parallel build. Th
On 2. Sep, 2010, at 9:49 , Chiheng Xu wrote:
> On Thu, Sep 2, 2010 at 3:32 PM, Mike McQuaid wrote:
>>
>> On 2 Sep 2010, at 08:15, Chiheng Xu wrote:
>>
>>> CMake is a very great tool.But its drawback is also obvious.It
>>> will consume large amount of time to generate Makefiles every ti
On Thu, Sep 2, 2010 at 3:32 PM, Mike McQuaid wrote:
>
> On 2 Sep 2010, at 08:15, Chiheng Xu wrote:
>
>> CMake is a very great tool. But its drawback is also obvious. It
>> will consume large amount of time to generate Makefiles every time you
>> want to build, especially for ultra large pro
On 2 Sep 2010, at 08:15, Chiheng Xu wrote:
> CMake is a very great tool.But its drawback is also obvious.It
> will consume large amount of time to generate Makefiles every time you
> want to build, especially for ultra large projects. Building can be
> parallelized, but the CMaking, li
On Thu, Sep 2, 2010 at 2:02 PM, Chris Hillery wrote:
> On Wed, Sep 1, 2010 at 10:17 PM, Chiheng Xu wrote:
>>
>> On Fri, Aug 20, 2010 at 1:11 AM, <"\"Roman Wüger\"
>> "@mac.com> wrote:
>> > CMake is a Makefile-Generator an nothing else
>> >
>> > Why would you write the Makefiles by yourself?
>> >
27 matches
Mail list logo
