On Fri, Jul 31, 2015 at 6:13 AM, Crast, Nicholas
nicholas.cr...@saabsensis.com wrote:
Well that's a way to do it, but there's not a way to do all of that in one
shot?
make a macro to do it?
it's not like that's all that much to do...
files( glob file_list *)
foreach( file ${file_list} )
Well that's a way to do it, but there's not a way to do all of that in one
shot?
Nick Crast
Software Engineer
Saab Sensis Corporation
Phone: 315-445-5703
Email: nicholas.cr...@saabsensis.com
-Original Message-
From: David Cole
On 7/31/2015 12:33 PM, Ruslan Baratov wrote:
rm -rf _builds
cmake -H. -B_builds
cmake -H. -B_builds -DA=ON
grep '\B\' _builds/CMakeCache.txt
B:STRING=There is no A
I'm not saying cache is a bad idea, I'm just saying that when users hit
such kind of situations that's
On Fri, Jul 31, 2015 at 2:05 AM, Nagy-Egri Máté Ferenc cmake@cmake.org wrote:
I agree that JSON looks better. I have no fetish about XML and I could be
convinced on just about anything in the choice of the IR. The only important
point is that it SHOULD EXIST and be well defined. Hooking all the
This seems to work for me:
set(CMAKE_BUILD_TYPE_INIT RelWithDebInfo)
--
Daniel Schepler
From: CMake [cmake-boun...@cmake.org] on behalf of Dan Kegel [d...@kegel.com]
Sent: Friday, July 31, 2015 9:38 AM
To: Ruslan Baratov
Cc: cmake; Bill Hoffman
Subject:
On Fri, Jul 31, 2015 at 11:33 AM, Ruslan Baratov
ruslan_bara...@yahoo.com wrote:
I never use the GUI, and consider the cache an anti-feature there solely
to support GUI users. It complicates my life, and I'd love to see it go.
In what way do you think it is causing you trouble?
Here is an
On 30-Jul-15 20:36, Bill Hoffman wrote:
On 7/30/2015 11:56 AM, Dan Kegel wrote:
I believe the latter, but not the former.
I never use the GUI, and consider the cache an anti-feature there solely
to support GUI users. It complicates my life, and I'd love to see it
go.
It is certainly not there
On Fri, Jul 31, 2015 at 11:43 AM, Bill Hoffman bill.hoff...@kitware.com wrote:
Something like:
$CACHE{A}
Then, it would never be confused with the the variable A. However, getting
rid of the cache would not be something that could be done.
Having a cache for invariants is a good thing if it
Understood. I am doing it this way, I was just thinking maybe there was some
more sophisticated pattern matching that I could do (get all files matching
this regular expression) without looping through the whole list.
Thanks
-Nick
Nick Crast
Software
On Fri, Jul 31, 2015 at 11:44 AM, Daniel Schepler
dschep...@scalable-networks.com wrote:
Here's another example from real life. Maybe I'm just being an idiot,
but this is what I had to do to set a default:
IF(DEFINED CMAKE_BUILD_TYPE AND (NOT ${CMAKE_BUILD_TYPE} STREQUAL None))
On 31-Jul-15 19:43, Bill Hoffman wrote:
On 7/31/2015 12:33 PM, Ruslan Baratov wrote:
rm -rf _builds
cmake -H. -B_builds
cmake -H. -B_builds -DA=ON
grep '\B\' _builds/CMakeCache.txt
B:STRING=There is no A
I'm not saying cache is a bad idea, I'm just saying that when
On 31-Jul-15 19:44, Daniel Schepler wrote:
This seems to work for me:
set(CMAKE_BUILD_TYPE_INIT RelWithDebInfo)
By the way you need to set it before first 'project' command. Also it
will not have any effects for multi-config generators like Xcode or
Visual Studio.
--
Powered by
It doesn't look like it's documented, at least in the command line
--help-variable.
It's a special case, which I think works for a lot of the build flag related
cache variables (though for a lot of the others, you probably need to put
values in e.g. a c_flag_overrides.cmake included by setting
On Thu, Jul 30, 2015 at 1:51 PM, Nagy-Egri Máté Ferenc cmake@cmake.org
wrote:
[...]
@Nicolas:
Yes, these tools indeed have been working for the past few decades. Others
also suggested why don’t I generate CMakelists.txt instead?
The problem is that the current limitations of CMake all
Okay, please forget this question. I misread the error message, and my example
had a type. The errors actually are generated in another macro which tries to
iterate over the source files of a target, and fails to find the generator
expression.
Best wishes,
Jens
--
Dr. Jens Auer | CGI |
On Thu, Jul 30, 2015 at 8:55 PM, Bill Somerville b...@classdesign.com
wrote:
On 30/07/2015 19:36, Rashad M wrote:
Hi all,
Hi Rashad
We have a similar way here to get dll dependencies recursively and create
a zip archive. Ideally, this could be integrated in cmake but not sure if
that
As for the GUI editor of a project, it has occured to me (and others too)
that such a tool would be darn useful. If it were a seperate tool, I’d
still use it just about every day, but you are correct that this feature
would be best embedded into the IDE. I am actively engaged with the folk
Hi guys,
I am currently working on some CMake build scripts that were designed for
crossplatform use. However they are not working perfectly under windows.
The isolated testcase looks like this: initialize a fortran project. CMake
always tries to use 'ifort' from Visual Studio as compiler but I
@all:
Thank you folks for the input and the active discussion (not shifting into
flame and troll wars).
@DaveDan:
I agree that JSON looks better. I have no fetish about XML and I could be
convinced on just about anything in the choice of the IR. The only important
point is that it
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 1aa0ee9cc3514467d66832d127aa955a99fb (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 22d1597f20869110edca4411236e8f5263cd5ece (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 199ea5b65360275f0bc489dff1ddbefc064cd271 (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 fb65bd6b653a30e83faf97c73e0de1961f6e5c7e (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 967364dea4fb2a13bfe22f73d8343bccf15d3883 (commit)
via
On 07/31/2015 07:14 AM, Radovan Bast wrote:
the cmake-3.3.0-Linux-x86_64.tar.gz
on http://www.cmake.org/download/
is not gzipped.
Yes, it is. From a shell on the hosting server:
$ file cmake-3.3.0-Linux-x86_64.tar.gz
cmake-3.3.0-Linux-x86_64.tar.gz: gzip compressed data, ...
$ shasum -a
On 07/30/2015 05:17 PM, Roger Leigh wrote:
Are the duplicated template exports here at the level of the translation
unit not elided when linking the DLL? In the dlltest git repo, I
specifically create DLLs with duplicate template exports in different
translation units to make sure it
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 4413ed800ccfd7adb73eda166442245eb286fe82 (commit)
via
On 07/30/2015 11:59 AM, Aleix Pol wrote:
I need to get the linked libraries of a target. I was moving the code
away from get_target_property to generator expressions that should get
into a generated file, although I haven't managed yet.
Is there any possibility to do that already?
I've
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 82e77d74304707255265a564678b38ea372813dd (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 6c3d0e9a6bf88a03442acf1f0bc1ef1575779d46 (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 609e8b181a4bf49c5095fff33365606db30e7921 (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 e91f096e1beba3c3d6f71e5c7cbc337c9d9d7282 (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 6e11703c6c9526724040f72c48e2f18616290080 (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 6b24fa692f950a95e500ad3f41c51b9db642afa4 (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 1549af20a9fbeac6535f6f7134afeb3a4849de74 (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 3394db5b8debc195eae4275ae1e9c8e74611d422 (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 7899f6955a3e4782db656c46390087f4c8a8e205 (commit)
via
On 07/31/2015 03:09 PM, Brad King wrote:
I think some browsers or other download tools may automatically
gunzip files during download.
I seem to get that with Chromium too.
The HTTP response for cmake-3.3.0.tar.gz does contain:
Content-Encoding: x-gzip
Which I think does tell clients
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 2a9b8c6cf786ec1eb0fbfa3be87223b7ec59f1dc (commit)
via
thanks Brad! interesting. sorry for the noise.
best wishes,
radovan
On Fri, Jul 31, 2015 at 3:09 PM Brad King brad.k...@kitware.com wrote:
On 07/31/2015 07:14 AM, Radovan Bast wrote:
the cmake-3.3.0-Linux-x86_64.tar.gz
on http://www.cmake.org/download/
is not gzipped.
Yes, it is.
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 81fd86fa1998a107ab1de090b91c396c1f9e79a5 (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 8515f26a6381e32d8d15064afd030eb1392ce2d8 (commit)
via
On Thursday 30 July 2015 09:28:12 Brad King wrote:
On 07/29/2015 03:58 PM, Alex Merry wrote:
This is intended to be used from a settings file which is applied to a
group of CMake projects. This allows the file to control which policies
means that users of the settings file are not forced to
Indeed a Chrome version that I have installed today does that
to my surprise. Auto-unpacks during download but keeps the suffix.
I would like to ask why but this is not the right list :-)
Thanks again for the clarification!
radovan
On Fri, Jul 31, 2015 at 3:11 PM Radovan Bast
On 07/31/2015 12:54 PM, Alex Merry wrote:
Setting policies centrally breaks their compatibility model.
I should perhaps explain our use case:
My assertion stands regardless of the use case.
Now, sure, we could change every single project that includes this module to
use NO_POLICY_SCOPE
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 45a48d7e23bae2590516118643d592f02f69ff4e (commit)
via
20150731)
+set(CMake_VERSION_PATCH 20150801)
#set(CMake_VERSION_RC 1)
---
Summary of changes:
Source/CMakeVersion.cmake |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
hooks/post-receive
--
CMake
OK.
New version of patches. There is now a component per extra tool (for now IdlJ
and JarSigner as suggested by Brad) to ensure future extensibility.
Marc
On 30/07/15 16:49, Brad King brad.k...@kitware.com wrote:
On 07/30/2015 09:55 AM, CHEVRIER, Marc wrote:
here is the correct version.
Am 30.07.2015 um 17:20 schrieb Clinton Stimpson:
On Thursday, July 30, 2015 10:56:02 AM Brad King wrote:
On 07/30/2015 09:29 AM, Pascal Bach wrote:
CMAKE_FIND_ROOT_PATH_MODE would then need to be extended to support
something like NATIVE and TARGET that one could use to choose where
to look
dear all,
the cmake-3.3.0-Linux-x86_64.tar.gz
on http://www.cmake.org/download/
is not gzipped. this confused me a bit
since tar xvzf complained. of course
it can be extracted still but i think it would
be good to replace it by the compressed one.
thank you and best wishes,
radovan
--
50 matches
Mail list logo
