Hi there,
The qt4_use_modules is now mostly obsoleted by tll in CMake 2.8.11. The main
difference is that qt4_use_modules does not require the use of imported
targets.
I think we should deprecate it in favor of using tll() with imported targets
(using the imported targets is independent of
On Wed, Feb 6, 2013 at 5:46 AM, Stephen Kelly steve...@gmail.com wrote:
Hi there,
The qt4_use_modules is now mostly obsoleted by tll in CMake 2.8.11. The main
difference is that qt4_use_modules does not require the use of imported
targets.
I think we should deprecate it in favor of using
-Original Message-
From: Marcus D. Hanwell marcus.hanw...@kitware.com
To: Stephen Kelly steve...@gmail.com
Cc: cmake-developers cmake-developers@cmake.org
Sent: Wed, Feb 6, 2013 7:55 am
Subject: Re: [cmake-developers] Deprecating qt4_use_modules and qt4_automoc?
On Wed, Feb 6,
David Cole wrote:
I agree with Marcus. There's no reason to deprecate these (other than
deprecating Qt4 entirely, but not yet) unless there's a significant code
clarity advantage.
I think in the case of the qt4_automoc macro at least, there's some
technical issue with changes in
-Original Message-
From: Stephen Kelly steve...@gmail.com
To: cmake-developers cmake-developers@cmake.org
Sent: Wed, Feb 6, 2013 8:17 am
Subject: Re: [cmake-developers] Deprecating qt4_use_modules and qt4_automoc?
David Cole wrote:
I agree with Marcus. There's no reason to deprecate
Hi there,
I've pushed a branch with some addtional fixes for various issues in
generator expressions.
One of the issues relates to depends information in the build dir. I fixed
the situation in the makefile generator by expanding the COMPILE_DEFINITIONS
before writing out the
On 2013-02-05 19:46-0600 Eric Gross wrote:
Hi,
I'm using CMake 2.8.10.2 with the Unix Makefiles generator on Windows
and cross-compiling for Linux using GCC.
[]Any ideas?
What is your use case? It might turn out that direct compilation on a
Linux box is best for your needs since the
Hi,
I'm emailing about bug
13093http://public.kitware.com/Bug/view.php?id=13093in the backlog.
I found comments
by Brad http://www.cmake.org/pipermail/cmake/2011-February/042556.htmlthat
suggest it's a legitimate warning, but I'm not sure how a project
could avoid the warning. Maybe cmake could
In case you haven't thought of it, you could run actual Linux in VirtualBox
and not have to deal with cross compilation.
--
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
Hi
On Wed, Feb 6, 2013 at 11:59 AM, Pat Marion pat.mar...@kitware.com wrote:
Hi,
I'm emailing about bug
13093http://public.kitware.com/Bug/view.php?id=13093in the backlog. I
found comments
by Brad http://www.cmake.org/pipermail/cmake/2011-February/042556.htmlthat
suggest it's a
That's a pretty messy workaround though, I think. ExternalProject_Add
passes in lots of variables, including ones that do not typically change,
like CMAKE_CXX_COMPILER. Why impose a special requirement on the
CMAKE_TOOLCHAIN_FILE variable? Would a patch to avoid the warning be a
welcome change,
Sorry, i forgot to say that I'm using CMake 2.8.7?
Is there a chance to do so?
Thanks in advance
Am 05.02.2013 um 14:17 schrieb NoRulez noru...@me.com:
Hi,
when i run cpack, then it breaks after the first error.
Is there a way (For NMake for example) to run nmake /I to ignore exit codes
If you don't want to see the warning, then also pass in --no-warn-unused-cli on
the command line.
--no-warn-unused-cli= Don't warn about command line options.
But that suppresses the warning for all unreferenced variables.
Or... add:
message(STATUS
On Wed, Feb 6, 2013 at 5:59 AM, Pat Marion pat.mar...@kitware.com wrote:
Hi,
I'm emailing about bug 13093 in the backlog. I found comments by Brad that
suggest it's a legitimate warning, but I'm not sure how a project could
avoid the warning. Maybe cmake could send a fatal error if the
Hi Eric
On Wed, Feb 6, 2013 at 2:46 AM, Eric Gross eric.gr...@ni.com wrote:
Hi,
I'm using CMake 2.8.10.2 with the Unix Makefiles generator on Windows
and cross-compiling for Linux using GCC. I have Cygwin in the path for
make/sh/etc.
To cross compile I have the following items set:
I'd like you to try pasting the following text into a google search, so you
can appreciate how widespread the warning is, 257 results from lots of
different projects:
CMake Warning: Manually-specified variables were not used by the
project: CMAKE_TOOLCHAIN_FILE
Most of these projects
Thanks for the discussion guys! And thanks Marcus for the CMAKE_CACHE_ARGS
tip. I'll try that out.
In fact, the current design could be problematic because if you *do*
specify a different toolchain file, cmake will ignore it instead of sending
you a warning like it does if you change the
-Original Message-
From: Pat Marion pat.mar...@kitware.com
To: David Cole dlrd...@aol.com
Cc: themiwi them...@gmail.com; cmake cmake@cmake.org
Sent: Wed, Feb 6, 2013 8:34 am
Subject: Re: [CMake] Passing CMAKE_TOOLCHAIN_FILE on command line causes CMake
warning
I'd like you to try
2013/2/6 NoRulez noru...@me.com:
Sorry, i forgot to say that I'm using CMake 2.8.7?
Is there a chance to do so?
There is currently no way to do that.
Why would it be useful for CPack to partially build the packages?
Do you have an example?
--
Erk
Le gouvernement représentatif n'est pas la
2013/2/6 Pat Marion pat.mar...@kitware.com:
Thanks for the discussion guys! And thanks Marcus for the CMAKE_CACHE_ARGS
tip. I'll try that out.
In fact, the current design could be problematic because if you *do* specify
a different toolchain file, cmake will ignore it instead of sending
Alan W. Irwin ir...@beluga.phys.uvic.ca wrote on 02/06/2013 03:22:07
AM:
From: Alan W. Irwin ir...@beluga.phys.uvic.ca
To: Eric Gross eric.gr...@ni.com
Cc: cmake@cmake.org
Date: 02/06/2013 03:22 AM
Subject: Re: [CMake] Linker command line length issues when cross-
compiling from
Because CPack runs the default (all) target.
It could be that a target doesn't build because of compile or link errors and
are not an install target (unit tests for example or other sub projects which
are not required).
CPack should build as much as possible and only break if an install target
CPack does call make install -- and make install first does a make all to get
everything up to date.
So even calling just cpack by itself in this situation is no good.
-Original Message-
From: Eric Noulard eric.noul...@gmail.com
To: NoRulez noru...@me.com
Cc: CMake ML
I have looked through the CMake wikis and several mailing list threads that
the following google search returned, and I have not found a definitive
answer to my question.
[site:www.cmake.org/pipermail/cmake CPack multiple configurations in one
package]
My team delivers debug and release
Ok, when I have the following situation:
prj1 (install target)
prj2 (not install target but produce compile error, so this could be ignored)
prj3 (install target)
prj4 (install target)
At the moment I call cpack -G ZIP (normally I call cpack from within a
CTestScript) and it stops by prj2
You're right. Normally I do not ignore errors, but in some situations if unit
tests and/or parts of new libraries are under development, on some platforms
they won't compile/link, but the main application is still stable and could be
packaged. I think you know what I mean. It is not my
2013/2/6 NoRulez noru...@me.com:
You're right. Normally I do not ignore errors, but in some situations if
unit tests and/or parts of new libraries are under development, on some
platforms they won't compile/link, but the main application is still stable
and could be packaged. I think you know
Thank you I will try it.
In the future I/we will handle it better and do not ignore errors. ;-)
Best Regards
Am 06.02.2013 um 20:57 schrieb Eric Noulard eric.noul...@gmail.com:
2013/2/6 NoRulez noru...@me.com:
You're right. Normally I do not ignore errors, but in some situations if
unit
We are currently aiming for early February for the first release candidate.
On Tue, Feb 5, 2013 at 11:10 AM, NoRulez noru...@me.com wrote:
Hi,
does anybody know the new release date for CMake 2.8.11?
In Mantis the date was scheduled for 2013-01-30.
Thanks in advance
--
Powered by
Hello,
I've been trying to setup a cross-compiled project using cmake and so
far everything's working fine using Unix Makefiles generator, etc. Now
I know generating for visual studio generally doesn't work under a cross
compiling setup, but I was wondering if it's possible to set up cmake to
I have Cmake 2.8.8 installed along with MinGW 4.7.2 on Windows XP with no
other development tools. I would like this project to build using only MinGW
tools, if possible. The project includes C and Fortran code, and those are
both recognized (GNU 4.7.2 and GNU, respectively) and correctly generate
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 2d7bda312b7a9d958e0758e43631b0b90a9616fd (commit)
via
Greetings,
I try to compile and configure cmake with
fes-a120d19nas:/backup/fes-a120d19nas/cmake-2.8.10.2# ./configure --prefix=/usr
--mandir=/usr/share/man
and get
CMake 2.8.10.2, Copyright 2000-2012 Kitware, Inc.C compiler on this system is:
On 02/06/2013 01:05 PM, .uservorname .usernachname wrote:
Greetings,
This is a version control update notification mailing list.
Please go to the users list:
http://www.cmake.org/mailman/listinfo/cmake
-Brad
___
Cmake-commits mailing list
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 0c299664eb183f02272d0ecb86bd54e3794369ea (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 4057effc4de213e948a5e8be78ce4a01d13140e5 (commit)
via
36 matches
Mail list logo
