How about ditching the whole idea of finding the latest version and just search
for un-versioned names? If the user wants something different, she should set
PYTHON_EXECUTABLE.
Michael
On 3. Aug, 2010, at 7:37 , Michael Hertling wrote:
On 07/22/2010 02:17 PM, Marcel Loose wrote:
Hi all,
Bingo.
With more than one of *anything* installed, the find modules can only guess.
They can never know which one is correct.
In the presence of exactly one installation of something, the find modules
are wonderful.
In the presense of two or more, the find modules suck eggs for half the
users
;-) Thanks David.
One thing remains which also sucks and I don't know enough about: Windows. I
know that many software packages create registry entries naming the
installation directory etc. Hopefully they do that for each installed version
individually, but do they also create a
On Tue, Aug 3, 2010 at 8:01 AM, Michael Wild them...@gmail.com wrote:
;-) Thanks David.
One thing remains which also sucks and I don't know enough about: Windows.
I know that many software packages create registry entries naming the
installation directory etc. Hopefully they do that for each
On 2010-08-03 07:57-0400 David Cole wrote:
When there are multiple matching installations, the developer must specify
which one he wants. The way he does that varies from module to module, but
it is always do-able by simply setting some cache values to point to the
right stuff.
I agree about
On 07/22/2010 02:17 PM, Marcel Loose wrote:
Hi all,
That sounds like a good solution. It is probably the cleanest way to
solve this controversy. OTOH, it adds two extra keywords that, of
course, are not used in existing (now sometimes failing) Find macros.
IMHO, solving the issue by
On 07/22/2010 01:30 PM, Michael Wild wrote:
Thanks for reminding me of my old idea ;-)
http://www.cmake.org/pipermail/cmake/2010-May/036993.html
I think that would be the cleanest solution. Extract the loop body into a
function and then have two separate loops calling the same function.
On 07/22/2010 09:18 AM, Alan W. Irwin wrote:
On 2010-07-22 03:09+0200 Michael Hertling wrote:
In summary, my point is: Even if the loops are swapped, we wouldn't get
a solution that works well in real-world scenarios so I doubt if it's
worth the effort [...].
Hi Michael:
I think find
On 23. Jul, 2010, at 18:43 , Branan Purvine-Riley wrote:
On Fri, Jul 23, 2010 at 12:28 AM, Michael Wild them...@gmail.com wrote:
On 23. Jul, 2010, at 8:59 , Branan Purvine-Riley wrote:
On Sunday 18 July 2010 12:07:43 you wrote:
On Sunday 18 July 2010 09:15:17 Michael Hertling wrote:
On
On 24. Jul, 2010, at 5:58 , Michael Hertling wrote:
On 07/23/2010 09:02 AM, Michael Wild wrote:
On 23. Jul, 2010, at 6:29 , Michael Hertling wrote:
On 07/22/2010 10:36 AM, Michael Wild wrote:
On 22. Jul, 2010, at 10:17 , Marcel Loose wrote:
[...]
Hi Michael and others,
I mostly
On Sunday 18 July 2010 12:07:43 you wrote:
On Sunday 18 July 2010 09:15:17 Michael Hertling wrote:
On 07/18/2010 06:50 AM, Branan Riley wrote:
I've mad a very cursory effort to add Python 3 support to CMake. All
I've done so far is take FindPythonLibs and FindPythonInterp, and
change
On 23. Jul, 2010, at 6:29 , Michael Hertling wrote:
On 07/22/2010 10:36 AM, Michael Wild wrote:
On 22. Jul, 2010, at 10:17 , Marcel Loose wrote:
[...]
Hi Michael and others,
I mostly agree with what your saying. However, IMHO, you refer to a
perfect world situation, where all Find
On 23. Jul, 2010, at 8:59 , Branan Purvine-Riley wrote:
On Sunday 18 July 2010 12:07:43 you wrote:
On Sunday 18 July 2010 09:15:17 Michael Hertling wrote:
On 07/18/2010 06:50 AM, Branan Riley wrote:
I've mad a very cursory effort to add Python 3 support to CMake. All
I've done so far is
On 23. Jul, 2010, at 8:59 , Branan Purvine-Riley wrote:
On Sunday 18 July 2010 12:07:43 you wrote:
On Sunday 18 July 2010 09:15:17 Michael Hertling wrote:
On 07/18/2010 06:50 AM, Branan Riley wrote:
I've mad a very cursory effort to add Python 3 support to CMake. All
I've done so far is
On 07/23/2010 09:02 AM, Michael Wild wrote:
On 23. Jul, 2010, at 6:29 , Michael Hertling wrote:
On 07/22/2010 10:36 AM, Michael Wild wrote:
On 22. Jul, 2010, at 10:17 , Marcel Loose wrote:
[...]
Hi Michael and others,
I mostly agree with what your saying. However, IMHO, you refer to a
On 22. Jul, 2010, at 3:09 , Michael Hertling wrote:
On 07/21/2010 10:26 AM, Michael Wild wrote:
On 21. Jul, 2010, at 9:56 , Marcel Loose wrote:
On Tue, 2010-07-20 at 09:18 -0700, Alan W. Irwin wrote:
On 2010-07-20 17:12+0200 Michael Hertling wrote:
On 07/20/2010 03:26 AM, Alan W.
On 2010-07-22 03:09+0200 Michael Hertling wrote:
In summary, my point is: Even if the loops are swapped, we wouldn't get
a solution that works well in real-world scenarios so I doubt if it's
worth the effort [...].
Hi Michael:
I think find issues are a really important topic so I am glad you
On 22. Jul, 2010, at 9:18 , Alan W. Irwin wrote:
On 2010-07-22 03:09+0200 Michael Hertling wrote:
[...] one should
prefer to improve the find modules and get rid of those non-equivalent
alternatives after the NAMES option, in particular hardcoded version
lists, and freshly developed
On Thu, 2010-07-22 at 03:09 +0200, Michael Hertling wrote:
On 07/21/2010 10:26 AM, Michael Wild wrote:
On 21. Jul, 2010, at 9:56 , Marcel Loose wrote:
On Tue, 2010-07-20 at 09:18 -0700, Alan W. Irwin wrote:
On 2010-07-20 17:12+0200 Michael Hertling wrote:
On 07/20/2010 03:26 AM,
On 22. Jul, 2010, at 10:17 , Marcel Loose wrote:
[...]
Hi Michael and others,
I mostly agree with what your saying. However, IMHO, you refer to a
perfect world situation, where all Find modules properly use VERSION
to specify a version number and do not abuse NAMES for that.
I know
With respect to fixing 10718, *if* we fix it (and that's a big *if* because
it's a sweeping change in behavior with largely unpredictable real world
consequences), I suggest that we:
- have both loops in CMake,
- and that the default behavior remains the same as it is now,
- and that we activate
Thanks for reminding me of my old idea ;-)
http://www.cmake.org/pipermail/cmake/2010-May/036993.html
I think that would be the cleanest solution. Extract the loop body into a
function and then have two separate loops calling the same function.
Michael
On 22. Jul, 2010, at 13:19 , David Cole
Hi all,
That sounds like a good solution. It is probably the cleanest way to
solve this controversy. OTOH, it adds two extra keywords that, of
course, are not used in existing (now sometimes failing) Find macros.
IMHO, solving the issue by changing CMake's behaviour would be
preferable, using a
On 07/22/2010 10:17 AM, Marcel Loose wrote:
On Thu, 2010-07-22 at 03:09 +0200, Michael Hertling wrote:
On 07/21/2010 10:26 AM, Michael Wild wrote:
On 21. Jul, 2010, at 9:56 , Marcel Loose wrote:
On Tue, 2010-07-20 at 09:18 -0700, Alan W. Irwin wrote:
On 2010-07-20 17:12+0200 Michael
On 07/22/2010 10:36 AM, Michael Wild wrote:
On 22. Jul, 2010, at 10:17 , Marcel Loose wrote:
[...]
Hi Michael and others,
I mostly agree with what your saying. However, IMHO, you refer to a
perfect world situation, where all Find modules properly use VERSION
to specify a version number
On 07/22/2010 08:33 AM, Michael Wild wrote:
On 22. Jul, 2010, at 3:09 , Michael Hertling wrote:
On 07/21/2010 10:26 AM, Michael Wild wrote:
On 21. Jul, 2010, at 9:56 , Marcel Loose wrote:
On Tue, 2010-07-20 at 09:18 -0700, Alan W. Irwin wrote:
On 2010-07-20 17:12+0200 Michael Hertling
On Tue, 2010-07-20 at 09:18 -0700, Alan W. Irwin wrote:
On 2010-07-20 17:12+0200 Michael Hertling wrote:
On 07/20/2010 03:26 AM, Alan W. Irwin wrote:
On 2010-07-20 00:51+0200 Michael Hertling wrote:
On 07/18/2010 10:14 PM, Alan W. Irwin wrote:
(1)
On 21. Jul, 2010, at 9:56 , Marcel Loose wrote:
On Tue, 2010-07-20 at 09:18 -0700, Alan W. Irwin wrote:
On 2010-07-20 17:12+0200 Michael Hertling wrote:
On 07/20/2010 03:26 AM, Alan W. Irwin wrote:
On 2010-07-20 00:51+0200 Michael Hertling wrote:
On 07/18/2010 10:14 PM, Alan W. Irwin
On 2010-07-19 00:47+0200 Eric Noulard wrote:
import sys; print sys.version.split()[0] will not work with python 3 because
print is a function:
Hi Eric:
Thanks for that reminder about using the print function for python3
and also for giving me the hint about sys.version_info to avoid
trailing
On 2010-07-21 08:50-0700 Alan W. Irwin wrote:
To draw this subthread to a definite conclusion, here is what works
for me now to get python version for either python2 or python3.
softw...@raven python -c \
'import sys; print(%s.%s.%s % sys.version_info[0:3])'
2.6.5
softw...@raven python3 -c \
On 21. Jul, 2010, at 18:59 , Alan W. Irwin wrote:
On 2010-07-21 08:50-0700 Alan W. Irwin wrote:
To draw this subthread to a definite conclusion, here is what works
for me now to get python version for either python2 or python3.
softw...@raven python -c \
'import sys; print(%s.%s.%s %
On 07/21/2010 10:26 AM, Michael Wild wrote:
On 21. Jul, 2010, at 9:56 , Marcel Loose wrote:
On Tue, 2010-07-20 at 09:18 -0700, Alan W. Irwin wrote:
On 2010-07-20 17:12+0200 Michael Hertling wrote:
On 07/20/2010 03:26 AM, Alan W. Irwin wrote:
On 2010-07-20 00:51+0200 Michael Hertling
On 07/20/2010 03:26 AM, Alan W. Irwin wrote:
On 2010-07-20 00:51+0200 Michael Hertling wrote:
On 07/18/2010 10:14 PM, Alan W. Irwin wrote:
(1) http://public.kitware.com/Bug/view.php?id=10718 is fixed. In my
view this bug has been the source of much CMake find trouble for a long
time, and I
On 2010-07-20 17:12+0200 Michael Hertling wrote:
On 07/20/2010 03:26 AM, Alan W. Irwin wrote:
On 2010-07-20 00:51+0200 Michael Hertling wrote:
On 07/18/2010 10:14 PM, Alan W. Irwin wrote:
(1) http://public.kitware.com/Bug/view.php?id=10718 is fixed. In my
view this bug has been the source
On 07/18/2010 09:07 PM, Branan Purvine-Riley wrote:
On Sunday 18 July 2010 09:15:17 Michael Hertling wrote:
On 07/18/2010 06:50 AM, Branan Riley wrote:
I've mad a very cursory effort to add Python 3 support to CMake. All
I've done so far is take FindPythonLibs and FindPythonInterp, and
change
On 07/18/2010 10:14 PM, Alan W. Irwin wrote:
On 2010-07-18 12:07-0700 Branan Purvine-Riley wrote:
Unfortunately, I can't think of a way to get out of using hardcoded version
lists, since python is often in specific locations (or has a specific
executable
name) based on its version number.
On 2010-07-20 00:51+0200 Michael Hertling wrote:
On 07/18/2010 10:14 PM, Alan W. Irwin wrote:
(1) http://public.kitware.com/Bug/view.php?id=10718 is fixed. In my
view this bug has been the source of much CMake find trouble for a long
time, and I hope the CMake developers make it a high
On 07/18/2010 06:50 AM, Branan Riley wrote:
I've mad a very cursory effort to add Python 3 support to CMake. All
I've done so far is take FindPythonLibs and FindPythonInterp, and
change the variable names and the python versions. It doesn't yet have
framework support on Mac, as I have no idea
On Sunday 18 July 2010 09:15:17 Michael Hertling wrote:
On 07/18/2010 06:50 AM, Branan Riley wrote:
I've mad a very cursory effort to add Python 3 support to CMake. All
I've done so far is take FindPythonLibs and FindPythonInterp, and
change the variable names and the python versions. It
On 2010-07-18 12:07-0700 Branan Purvine-Riley wrote:
Unfortunately, I can't think of a way to get out of using hardcoded version
lists, since python is often in specific locations (or has a specific executable
name) based on its version number.
I haven't read through the new Find Python work
2010/7/18 Alan W. Irwin ir...@beluga.phys.uvic.ca:
[...]
# Get the Python version.
execute_process(
COMMAND
${PYTHON_EXECUTABLE} -c import sys; print sys.version.split()[0]
OUTPUT_VARIABLE PYTHON_version_output
OUTPUT_STRIP_TRAILING_WHITESPACE
)
SET(PYTHON_VERSION
41 matches
Mail list logo
