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 Tue, Aug 3, 2010 at 8:01 AM, Michael Wild 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 installed
>
;-) 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 "latest-versio
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 (o
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,
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 ch
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 t
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 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 M
On 23. Jul, 2010, at 18:43 , Branan Purvine-Riley wrote:
> On Fri, Jul 23, 2010 at 12:28 AM, Michael Wild 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 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.
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
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
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" situa
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
> >
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+0
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
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+
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 po
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 wr
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 th
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
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
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 develope
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 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
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 Mi
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("
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 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
trailin
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
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) http://public.kitwa
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 o
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
>>>
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 priorit
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
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
2010/7/18 Alan W. Irwin :
[...]
> # 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 ${PYTHON_version_output
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
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.
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 id
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 how to specify a Python 3
framework. Besides that
42 matches
Mail list logo
