Hello,
> On Sep 17, 2015, at 11:44 PM, Clinton Stimpson wrote:
>
> On Thursday, September 17, 2015 11:18:06 PM Mike Gelfand wrote:
>> Hello everyone,
>>
>> I’m using cmake 3.3.1 on Mac 10.10.4. I’m building an executable target on
>> Mac with the following settings:
>>
>> CMAKE_OSX_ARCHITECTU
On 17/09/2015 13:49, Brad King wrote:
This caused a regression:
-Wno-dev doesn't work any more in CMake 3.4
http://www.cmake.org/Bug/view.php?id=15747
Please take a look to fix it and extend the test suite accordingly.
Thanks,
-Brad
Ah okay, I've replicated it on my Linux development env
On Sep 17, 2015, at 11:44 PM, Clinton Stimpson wrote:
> I'm not sure where the defect is, or how to work around it, without getting
> more details.
>
> I've seen problems similar to this, but not exactly the same as what you are
> seeing. What I have seen before was discussed here:
> http://publ
Le 17/09/15 21:21, Domen Vrankar a écrit :
Please find attached the "feature" based onto 68dba7f. I added the variable
CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION and its component counterpart
for controlling strict behaviour on the files added to control.tar.gz .
Thanks, applied and squashe
On Thursday, September 17, 2015 11:18:06 PM Mike Gelfand wrote:
> Hello everyone,
>
> I’m using cmake 3.3.1 on Mac 10.10.4. I’m building an executable target on
> Mac with the following settings:
>
> CMAKE_OSX_ARCHITECTURES = i386;x86_64
> CMAKE_OSX_DEPLOYMENT_TARGET = 10.5
> CMAKE_OSX_SYSR
Hello everyone,
I’m using cmake 3.3.1 on Mac 10.10.4. I’m building an executable target on Mac
with the following settings:
CMAKE_OSX_ARCHITECTURES = i386;x86_64
CMAKE_OSX_DEPLOYMENT_TARGET = 10.5
CMAKE_OSX_SYSROOT = .../MacOSX10.10.sdk
Right after build, executable is runnable (from insi
> Please find attached the "feature" based onto 68dba7f. I added the variable
> CPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION and its component counterpart
> for controlling strict behaviour on the files added to control.tar.gz .
Thanks, applied and squashed patches with some changes to
cmArchive
We are pleased to announce that CMake 3.3.2 is now available for download.
Please use the latest release from our download page:
http://www.cmake.org/download/
Thanks for your support!
-
Changes in 3.3.2 since 3.3.1:
Brad
On Thu, Sep 17, 2015 at 11:45 AM, David Gobbi wrote:
> On Thu, Sep 17, 2015 at 11:25 AM, David Gobbi
> wrote:
>
>> On Thu, Sep 17, 2015 at 10:59 AM, Clinton Stimpson
>> wrote:
>>
>>>
>>> However, it does bother me that it found includes from the SDK and a
>>> library
>>> under /usr/lib.
>>>
>>>
On Thu, Sep 17, 2015 at 11:25 AM, David Gobbi wrote:
> On Thu, Sep 17, 2015 at 10:59 AM, Clinton Stimpson
> wrote:
>
>>
>> However, it does bother me that it found includes from the SDK and a
>> library
>> under /usr/lib.
>>
>> For example, if I use the 10.6 SDK on OS X 10.7, it appears that it
On Thu, Sep 17, 2015 at 10:59 AM, Clinton Stimpson
wrote:
>
> However, it does bother me that it found includes from the SDK and a
> library
> under /usr/lib.
>
> For example, if I use the 10.6 SDK on OS X 10.7, it appears that it would
> find
> /usr/lib/libpython.2.7.dylib and headers for python
On Thursday, September 17, 2015 12:54:26 PM Brad King wrote:
> On 09/17/2015 12:42 PM, David Gobbi wrote:
> > Okay, Clinton. Now you've made me paranoid that I should be prepending
> > the value of CMAKE_OSX_SYSROOT before the prefix if it isn't already
> > part of the prefix. I don't want to ign
On 09/17/2015 12:42 PM, David Gobbi wrote:
> Okay, Clinton. Now you've made me paranoid that I should be prepending
> the value of CMAKE_OSX_SYSROOT before the prefix if it isn't already
> part of the prefix. I don't want to ignore CMAKE_OSX_SYSROOT if it has
> been set, but unfortunately I don't
On 09/17/2015 12:03 PM, David Gobbi wrote:
> I've renamed the variable _PREFIX -> _Python_PREFIX and now the code
> unsets it once it's finished with it.
Thanks:
FindPythonLibs: unset temporary _PREFIX variable
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=19934b67
-Brad
--
Powered by
On Thu, Sep 17, 2015 at 9:46 AM, David Gobbi wrote:
> On Thu, Sep 17, 2015 at 9:08 AM, Clinton Stimpson
> wrote:
>
>>
>> Is that related to issues you are addressing here?
>>
>
> No, the prefix check was meant to fix things for people who use homebrew
> or other third-party package managers that
On Wednesday, September 16, 2015 11:04:23 PM David Gobbi wrote:
> On Wed, Sep 16, 2015 at 9:41 AM, Brad King wrote:
> > On 09/16/2015 11:39 AM, Brad King wrote:
> > > On 09/16/2015 10:00 AM, David Gobbi wrote:
> > >> this new patch only changes the search for the include dirs.
> > >
> > > Thanks.
On Thu, Sep 17, 2015 at 9:48 AM, Brad King wrote:
>
>
> Please provide a follow-up patch I can squash in for that.
>
I've renamed the variable _PREFIX -> _Python_PREFIX and now the code
unsets it once it's finished with it.
- David
0001-FindPythonLibs-unset-temporary-_PREFIX-variable.patch
De
On 09/17/2015 11:38 AM, David Gobbi wrote:
> The _PREFIX temporary variable is still lying around, though.
Please provide a follow-up patch I can squash in for that.
Thanks,
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wik
On Thu, Sep 17, 2015 at 9:08 AM, Clinton Stimpson
wrote:
>
> Hi,
>
> I did a quick test to see if my issue has been resolved.
>
> I have a CMakeLists.txt file with just:
> FIND_PACKAGE(PythonInterp REQUIRED)
> FIND_PACKAGE(PythonLibs ${PYTHON_VERSION_STRING} REQUIRED)
>
>
> And I get this error:
On Thu, Sep 17, 2015 at 9:32 AM, Brad King wrote:
> On 09/17/2015 10:43 AM, David Gobbi wrote:
> > It finds the install prefix for PYTHON_EXECUTABLE
> > and uses it as a hint for the library location
>
> Thanks. I revised the previous patch slightly to add a prefix to
> the _HINT temporary varia
On 09/17/2015 10:43 AM, David Gobbi wrote:
> It finds the install prefix for PYTHON_EXECUTABLE
> and uses it as a hint for the library location
Thanks. I revised the previous patch slightly to add a prefix to
the _HINT temporary variable and unset it when finished:
FindPythonLibs: Match include
On 09/11/2015 12:37 PM, Roman Wüger wrote:
> I added the required command line options, but it doesn't produce
> the expected output. It works in a normal environment, but not
> in the "CTest test case". Could you have a look at it?
We need to distinguish running CTest in dashboard script mode,
e
On Thu, Sep 17, 2015 at 7:44 AM, Brad King wrote:
>
> Thanks, applied:
>
> FindPythonLibs: Match include dir to library version
> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=89717916
This should be the last one. It finds the install prefix for
PYTHON_EXECUTABLE
and uses it as a hint f
On 09/17/2015 10:06 AM, mike.pa...@bmw.de wrote:
> would this mailing list be the right place to ask?
Yes, and thanks for offering to work on the patch. You can
post it here when finished, as described in CONTRIBUTING.rst.
Thanks,
-Brad
--
Powered by www.kitware.com
Please keep messages on-t
MAIN_DEPENDENCY does not easily work in our case (tried it), unless we change a
lot of targets in the project, which is not trivial. I'll be trying to submit a
patch, thanks for the offer. In case I have questions like "can I use this API
or should I use that one to do X", would this mailing lis
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15750
==
Reported By:CarlPoirier
Assigned To:
On 09/17/2015 09:51 AM, Kislinskiy, Stefan wrote:
> I wrote a SHELL_PATH genex which uses
> cmOutputConverter->ConvertToOutputFormat(..., SHELL) for the conversion.
> I decided to name the genex SHELL_PATH instead of TO_SHELL_PATH for the
> sake of consistency to other genexes like LOWER_CASE. What
Sorry for the late answer, I was on vacation. I wrote a SHELL_PATH genex which
uses cmOutputConverter->ConvertToOutputFormat(..., SHELL) for the conversion. I
decided to name the genex SHELL_PATH instead of TO_SHELL_PATH for the sake of
consistency to other genexes like LOWER_CASE. What do you t
On 09/17/2015 05:03 AM, mike.pa...@bmw.de wrote:
> force "old" rule files, which then would never trigger the command on their
> own.
Yes, I think that makes sense. Those files are only there because the
IDE project files need a place to attach the commands. Care to work on
a patch for this?
M
On 09/17/2015 01:04 AM, David Gobbi wrote:
> I've modified my patch
Thanks, applied:
FindPythonLibs: Match include dir to library version
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=89717916
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at
On 07/29/2015 09:26 AM, Brad King wrote:
> cmake: Add -W options to control deprecation warnings and errors
> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c96fe0b4
This caused a regression:
-Wno-dev doesn't work any more in CMake 3.4
http://www.cmake.org/Bug/view.php?id=15747
Please ta
Hi,
we are running into problems when using add_custom_command() without inputs.
The semantics of this is documented as "If DEPENDS is not specified the command
will run whenever the OUTPUT is missing", which is exactly what we need. This
is working everywhere, but not (cleanly) with VisualStud
32 matches
Mail list logo