Re: [cmake-developers] [PATCH] FindOpenGL: Don't add AGL to OPENGL_LIBRARIES on OS X.

On Mon, Dec 14, 2015 at 7:48 AM, Brad King <brad.k...@kitware.com> wrote: > On 12/12/2015 02:12 PM, David Gobbi wrote: > > CMake had been setting OPENGL_glu_LIBRARY to AGL.framework, even > > though AGL is not GLU. AGL is simply the GL component for the > > deprec

[cmake-developers] [PATCH] FindOpenGL: Don't add AGL to OPENGL_LIBRARIES on OS X.

CMake had been setting OPENGL_glu_LIBRARY to AGL.framework, even though AGL is not GLU. AGL is simply the GL component for the deprecated Carbon framework. GLU is provided by OpenGL.framework. A side effect of the old behavior was that if AGL was not found (it is absent from OS X SDK 10.10 or

Re: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks

On Thu, Sep 17, 2015 at 9:32 AM, Brad King <brad.k...@kitware.com> 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 pat

Re: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks

On Thu, Sep 17, 2015 at 9:46 AM, David Gobbi <david.go...@gmail.com> wrote: > On Thu, Sep 17, 2015 at 9:08 AM, Clinton Stimpson <clin...@elemtech.com> > wrote: > >> >> Is that related to issues you are addressing here? >> > > No, the prefix che

Re: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks

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

Re: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks

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) > > >

Re: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks

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

Re: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks

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

Re: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks

On Thu, Sep 17, 2015 at 11:45 AM, David Gobbi <david.go...@gmail.com> wrote: > On Thu, Sep 17, 2015 at 11:25 AM, David Gobbi <david.go...@gmail.com> > wrote: > >> On Thu, Sep 17, 2015 at 10:59 AM, Clinton Stimpson <clin...@elemtech.com> >> wrote

Re: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks

On Thu, Sep 17, 2015 at 11:25 AM, David Gobbi <david.go...@gmail.com> wrote: > On Thu, Sep 17, 2015 at 10:59 AM, Clinton Stimpson <clin...@elemtech.com> > wrote: > >> >> However, it does bother me that it found includes from the SDK and a >> library >>

Re: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks

On Wed, Sep 16, 2015 at 7:03 AM, Brad King <brad.k...@kitware.com> wrote: > On 09/15/2015 10:09 AM, David Gobbi wrote: > > The first is trivial, it simply adds Python 3.5 and 3.6 to the search > list. > > > > The second removes the long-deprecated PYTHON_

Re: [cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks

On Wed, Sep 16, 2015 at 9:41 AM, Brad King <brad.k...@kitware.com> 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. Rather tha

[cmake-developers] [PATCH] FindPythonLibs patches for version searching and frameworks

Hi All, I've attached three suggested patches for cmake. The first is trivial, it simply adds Python 3.5 and 3.6 to the search list. The second removes the long-deprecated PYTHON_INCLUDE_PATH as a suggestion for PYTHON_INCLUDE_DIR. The third does two important things: 1) it fixes bugs for

[CMake] FindPythonLibs patches for version searching and frameworks

Hi All, I've attached three suggested patches for cmake. The first is trivial, it simply adds Python 3.5 and 3.6 to the search list. The second removes the long-deprecated PYTHON_INCLUDE_PATH as a suggestion for PYTHON_INCLUDE_DIR. The third does two important things: 1) it fixes bugs for

Re: [CMake] CMake and OS X compiler tools without SDK

On Fri, Sep 21, 2012 at 9:34 AM, Brad King brad.k...@kitware.com wrote: I just made a few more commits to address this before 2.8.10. The main changes are: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a0a0877a http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=230ea218 Now CMake

[CMake] CMake and OS X compiler tools without SDK

Hi All, Just yesterday, Apple released new Command Line Tools for XCode 4.5. Unlike their previous command-line compiler tools, these new tools no longer require XCode. They are stand-alone. This is great, because the package is just 110MB (compared to 1560MB for XCode). However, there is a

Re: [CMake] CMake and OS X compiler tools without SDK

On Thu, Sep 20, 2012 at 2:55 PM, Sean McBride s...@rogue-research.com wrote: On Thu, 20 Sep 2012 14:26:54 -0600, David Gobbi said: Hi All, Just yesterday, Apple released new Command Line Tools for XCode 4.5. Unlike their previous command-line compiler tools, these new tools no longer require

Re: [CMake] OS X spaces in paths issue

On Fri, Sep 7, 2012 at 11:14 AM, David Gobbi david.go...@gmail.com wrote: I've attached the script. The location of cmake doesn't appear anywhere in the script, ctest finds cmake automatically in /usr/local/bin/cmake, which is a symlink to /Applications/CMake 2.8-9.app/Contents.bin/cmake. CMake

[CMake] OS X spaces in paths issue

This might have already been answered on the list but it didn't come up in a search. Someone that I work with was trying to run a ctest dashboard-generation script on OS X, and ctest was reporting There was an error: No such file or directory. Running ctest -VV gave more info about the error:

[CMake] Patch - FindPythonLibs provides PYTHON_VERSION

Hi All, The attached patch changes FindPythonLibs.cmake so that it returns the following variables: PYTHON_VERSION PYTHON_MAJOR_VERSION PYTHON_MINOR_VERSION PYTHON_MICRO_VERSION The purpose of this patch is to allow CMake scripts to perform conditional configuration based on what python version

Re: [CMake] Patch - FindPythonLibs provides PYTHON_VERSION

I've attached a slightly modified patch, this one uses [0-9A-Za-z\\.]+ as the version regex instead of [0-9\\.]+ just in case the version is a pre-release with a, b etc. as part of the version string. - David On Wed, Jul 6, 2011 at 11:10 AM, David Gobbi david.go...@gmail.com wrote: Hi All

[CMake] Interrogate header files without TRY_RUN

Hi All, Is there a way for CMake to search for macro definitions in header files without doing a try_run? The reason I'm asking is that eventually I'll require FindPython.cmake to report the version of python that it finds. But I don't want to do this by checking the directory names (which is

Re: [CMake] Interrogate header files without TRY_RUN

On Thu, Jun 16, 2011 at 10:58 AM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: You could simply read the header file and try to grep fpor the version numbers. Works quite good in many cases. Or you could try to mess around with try_compile(), and search in the produced binary for the

[CMake] Targets where the command decides if the target needs rebuilding

Hi all, There are times when a CMake custom command will generate exactly the same output file even if its inputs have changed. In these cases, I would like the timestamp on the output file to remain unchanged, but to generate a fake .target file with the current timestamp so the custom command

Re: [CMake] Targets where the command decides if the target needs rebuilding

the command. David On Mon, May 31, 2010 at 10:13 AM, David Gobbi david.go...@gmail.com wrote: Hi all, There are times when a CMake custom command will generate exactly the same output file even if its inputs have changed.  In these cases, I would like the timestamp on the output file to remain