On 12/18/2014 09:02 PM, Aleix Pol wrote:
I would like to propose this as a final version of this patch.
http://proli.net/meu/kdevelop/0001-cmake-Add-option-to-generate-target-metadata-for-IDE.patch
For reference, this was also attached in a later message of this
thread on 2015-01-09:
On Tue, Jan 20, 2015 at 3:47 PM, Brad King brad.k...@kitware.com wrote:
On 12/18/2014 09:02 PM, Aleix Pol wrote:
I would like to propose this as a final version of this patch.
http://proli.net/meu/kdevelop/0001-cmake-Add-option-to-generate-target-metadata-for-IDE.patch
For reference, this was
On Tue, Jan 20, 2015 at 10:42:47 -0500, Daniel Levin wrote:
This wrapper script cannot be common, because for each kind of build env
variable set will be different. So it need to be created at CMake
generation time saving current QNX* env variables into this wrapper script.
So next time you
As far as I understand this 'env' is not a standard key in Ninja, right?
That would be actually great to let CMake define environment variables in
rules.
Does CMake support that already?
What about Makefile compatibility, is it possible to define env variables
per rule in Makefiles?
On Tue, Jan
Brad, below is the list of variables set manually by me before testing QNX
SDK environment variables, the qcc will fail if any of them are missing:
set QNX_CONFIGURATION=d:\opt\qnx-software-systems
set QNXLM_LICENSE_FILE=@10.144.209.10
set QNX_HOST=d:\opt\qnx650sp1\host\win32\x86
set
On 01/20/2015 12:26 PM, Daniel Levin wrote:
As far as I understand this 'env' is not a standard key in Ninja, right?
That would be actually great to let CMake define environment variables in
rules.
Does CMake support that already?
What about Makefile compatibility, is it possible to define
On 01/20/2015 10:42 AM, Daniel Levin wrote:
- you need to explicitly load environment variables each time before build
This is the standard approach expected by Makefile and Ninja generators.
Even for builds with MSVC's cl tool we expect users to launch a command
prompt with the proper PATH,
Brad, do you think rule env variables would be a good enhancement for CMake?
This actually follows existing approach: configure everything once, save
into cache, build with single invocation of build tool.
The difference is only in details whether to pass options as arguments or
as environment
On 01/20/2015 01:04 PM, Daniel Levin wrote:
Brad King wrote:
We expect that environment variables required by the toolchain
in use are already loaded.
configure everything once, save into cache, build with single
invocation of build tool
Use of a developer-provided environment was a very
Some bugs of CMake (or what downstreams thinks are bug), that I was not aware
of, and maybe noone else. I have no connection to any of these bugs, I just
found them by accident:
https://bugs.gentoo.org/show_bug.cgi?id=445308
Hello,
On 12/01/15 15:00, Brad King wrote:
I've made a change using that approach here:
Xcode: Do not require code signing for compiler id (#15329)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=584aaa1c
Works great. Do you plan to make this patch available in 3.1.1 release?
Thanks,
11 matches
Mail list logo
