On 02/07/2012 02:43 PM, janitor 048 wrote:
Hello,
this is a question I recently asked on stackoverflow (
http://stackoverflow.com/questions/9129233/recommended-ways-to-use-cmake-with-icc-via-configuration-options)
but that has not received any response since then. Maybe this mailing list
is
On 02/08/2012 11:13 PM, Oliver kfsone Smith wrote:
Michael Hertling said the following on 2/6/2012 6:39 PM:
On 02/06/2012 10:56 PM, Alexander Neundorf wrote:
On Saturday 04 February 2012, Oliver Smith wrote:
My CMakeLists uses the Subversion repository information in a couple of
places (it
Hi,
I'm currently developing an app, and it's sources are divided into
subfolders. It seems that when I do:
add_executable(app ${sources} ${headers})
In my Xcode I can see two folders (Source files and Header files)
However, when I group sources in a subfolder with
source_group(folder
On 01/13/2012 08:02 PM, Michael Hertling wrote:
On 01/13/2012 03:42 PM, Bill Hoffman wrote:
On 1/13/2012 9:10 AM, Michael Hertling wrote:
With CMake 2.8.7 and VS 2008, I can report the following findings:
(1) Starting out from within an empty build directory: cmake ..
followed by cmake
I tried this out. The short story is that it works the way he states.
Changing the CMakeLists.txt cause CMake to rerun the ZERO_CHECK but the
executable generates a 0. Running the build again doesn't change
anything. Here is the transcript of the run:
Yuri,
Your suggestion is close to what I’m looking for.
What I need is a easy way to not this as the “Startup Project” , I need to
change the property of the INSTALL target itself.
By default, the INSTALL target is not in the “all” or if you open the
properties on the Solution , you will
I took a look at this, and it is behaving as expected with VS. VS does
NOT have a depend on compile flags. You can change a .vcproj file and
the flags it uses all you want, and VS will NOT rebuild any files
because of that.
So, as far as VS is concerned your source file has not changed and
It would seem useful to have a PARENT_SCOPE option for the unset() command,
just like its set() counterpart. Is there a particular reason why it does
not have it now?
-
Robert Dailey
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
On Thursday 09 February 2012, Robert Dailey wrote:
It would seem useful to have a PARENT_SCOPE option for the unset() command,
just like its set() counterpart. Is there a particular reason why it does
not have it now?
No, I think there is not particular reason.
Alex
--
Powered by
On Thu, Feb 9, 2012 at 2:22 PM, Alexander Neundorf
a.neundorf-w...@gmx.netwrote:
On Thursday 09 February 2012, Robert Dailey wrote:
It would seem useful to have a PARENT_SCOPE option for the unset()
command,
just like its set() counterpart. Is there a particular reason why it does
not
I didn't try that because I thought it would actually treat PARENT_SCOPE as
a string and add it to the variable. I did this instead:
set( var PARENT_SCOPE )
-
Robert Dailey
On Thu, Feb 9, 2012 at 1:26 PM, David Cole david.c...@kitware.com wrote:
On Thu, Feb 9, 2012 at 2:22 PM,
On Thu, Feb 9, 2012 at 2:41 PM, Robert Dailey rcdai...@gmail.com wrote:
I didn't try that because I thought it would actually treat PARENT_SCOPE
as a string and add it to the variable. I did this instead:
set( var PARENT_SCOPE )
That leaves it set, with a value of the empty string, in the
2012/1/29 Eric Noulard eric.noul...@gmail.com:
Hi All,
Just a small advertisement.
I will be giving a CMake presentation tutorial in Toulouse/France
on February 8th, 2012:
http://www.toulibre.org/evenements_a_venir
À 20h00 Éric Noulard présentera CMake, outil de compilation et de
test
I went through the slides; pretty good introduction-intermediate presentation.
I'm forwarding it to all the teams I work with here!
Aaron Meadows
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of
Eric Noulard
Sent: Thursday, February 09,
That worked, thanks David.
I guess CMake goes right-to-left for function parameters? I don't see how
else it doesn't think PARENT_SCOPE is a value instead of an option.
-
Robert Dailey
On Thu, Feb 9, 2012 at 1:45 PM, David Cole david.c...@kitware.com wrote:
On Thu, Feb 9, 2012 at
Yes, PARENT_SCOPE must occur as the last argument. Each command has its own
code for processing its argument list. See Source/cmSetCommand.cxx for
details on this one.
Interesting (not quite the right adjective?) side effect: it's difficult to
set a variable to the value PARENT_SCOPE because you
I dug into CMake’s C++ code and found there’s a generic setting named
EXCLUDE_FROM_ALL that most “targets” use to decide if a project should be under
the default build but, there’s particular target type named “GLOBAL_TARGET”
does use this setting and it’s always excluded from all.
Based on
Hi,
I'm (still) quite unsure if this isn't an FAQ (or if not maybe should be
one), but I have read through everything I could google-up regarding
this topic and found nothing usable...
I'm writing an x-platform-project which will be compiled using different
compilers and or under different
On Wednesday 08 February 2012, David Cole wrote:
The stage is intended only for topics that are imminently going to be
merged to 'next'...
The following CMake topic branches have been on the stage for quite some
time without being merged to 'next':
On Monday 30 January 2012, David Cole wrote:
...
From your original post:
So when ImageMagick is installed everything behaves as always. But if no
ImageMagick is installed behaviour was this:
find_package(ImageMagick) - ImageMagick_FOUND = TRUE
This is simply clearly incorrect,
On 2/9/2012 3:45 PM, Alexander Neundorf wrote:
Just to make completely sure: the purpose of this target property is *not*
that targets linking against a library with this property set should reuse
these include dirs, right ?
Correct. It's just to allow the directory-level INCLUDE_DIRECTORIES
On Thu, Feb 9, 2012 at 3:45 PM, Alexander Neundorf neund...@kde.org wrote:
On Monday 30 January 2012, Stephen Kelly wrote:
David Cole wrote:
On Sun, Jan 29, 2012 at 11:44 AM, Stephen Kelly
steve...@gmail.com wrote:
David Cole wrote:
OK... nearly complete now. Please review, then
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=12953
==
Reported By:Jean-Christophe Fillion-Robin
Assigned
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 a80db8077fe31f2be8692bcf145db0a7d69a9e8b (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 3d606bbc5c28a54642cb57e2b2947c0483cf0335 (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 d7510a4a4f698fdbe1c951c65ce2392e934bb3ff (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 0fcf69d72f113a989df43973e05c039e4bbd3d33 (commit)
from
27 matches
Mail list logo
