Hi,
I wish that fix for bug #9687 should be in final 2.8.0 too (at least
it is not mentioned in this).
Without it the whole Codeblocks with NMake is too much broken.
-Timi
2009/10/28 Bill Hoffman bill.hoff...@kitware.com:
CMake 2.8.0 RC 4 is now ready for people to try.
You can find the
Modestas,
FindJNI.cmake stopped working for me at some point (during transition
of *official* cmake 2.6.4 - *official* cmake 2.8rc4), this means it
affect your patched cmake 2.6.4 on debian.
if you want to reproduce on debian:
$ apt-get install gcj-4.4-jdk openjdk-6-jdk
$ cat CMakeLists.txt
On Thu, Oct 29, 2009 at 10:20 AM, Modestas Vainius modes...@vainius.eu wrote:
Hello,
On ketvirtadienis 29 Spalis 2009 10:29:15 Mathieu Malaterre wrote:
FindJNI.cmake stopped working for me at some point (during transition
of *official* cmake 2.6.4 - *official* cmake 2.8rc4), this means it
On Thu, Oct 29, 2009 at 11:46 AM, Modestas Vainius modes...@vainius.eu wrote:
Ok. If you had thought about this more, you would have realized that it would
Yeah, well, I don't like regression, esp. on rc4.
not be my code you would have to fix. You patched library directories, but
I have no
Timi Tuohenmaa wrote:
Hi,
I wish that fix for bug #9687 should be in final 2.8.0 too (at least
it is not mentioned in this).
Without it the whole Codeblocks with NMake is too much broken.
I am pretty sure that fix is in the release, but I did not mention it...
Can you try?
-Bill
Mathieu Malaterre wrote:
# ok we found jni.h, now derive other location from it:
get_filename_component(jni_path ${JAVA_INCLUDE_PATH} PATH)
FIND_PATH(JAVA_INCLUDE_PATH2 jni_md.h
${jni_path}
${jni_path}/win32
${jni_path}/linux
${jni_path}/freebsd
)
FIND_PATH(JAVA_AWT_INCLUDE_PATH
On 29. Oct, 2009, at 13:25 , Bill Hoffman wrote:
Timi Tuohenmaa wrote:
Hi,
I wish that fix for bug #9687 should be in final 2.8.0 too (at least
it is not mentioned in this).
Without it the whole Codeblocks with NMake is too much broken.
I am pretty sure that fix is in the release, but I did
On 29. Oct, 2009, at 13:35 , Bill Hoffman wrote:
Mathieu Malaterre wrote:
# ok we found jni.h, now derive other location from it:
get_filename_component(jni_path ${JAVA_INCLUDE_PATH} PATH)
FIND_PATH(JAVA_INCLUDE_PATH2 jni_md.h
${jni_path}
${jni_path}/win32
${jni_path}/linux
On Thu, Oct 29, 2009 at 1:35 PM, Bill Hoffman bill.hoff...@kitware.com wrote:
Mathieu Malaterre wrote:
# ok we found jni.h, now derive other location from it:
get_filename_component(jni_path ${JAVA_INCLUDE_PATH} PATH)
FIND_PATH(JAVA_INCLUDE_PATH2 jni_md.h
${jni_path}
${jni_path}/win32
On 29. Oct, 2009, at 11:11 , Tim Just wrote:
Hi,
I'm using CMake 2.8 rc3 on Ubuntu to build a modular and extensible
project. Therefore I have a directory called 'modules' beneath the
project root. In this folder may be an undefined number of
subfolders containing module sources and
Thanks,
Kevin
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this
On Thu, Oct 29, 2009 at 9:45 AM, Kevin Burge kevin.bu...@systemware.com wrote:
Thanks,
The fix for that is in 2.8.0 rc4. Are you still having this bug?
John
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
Michael Wild wrote:
On 29. Oct, 2009, at 11:11 , Tim Just wrote:
Hi,
I'm using CMake 2.8 rc3 on Ubuntu to build a modular and extensible
project. Therefore I have a directory called 'modules' beneath the
project root. In this folder may be an undefined number of subfolders
containing
On 29. Oct, 2009, at 15:11 , Tim Just wrote:
Michael Wild wrote:
On 29. Oct, 2009, at 11:11 , Tim Just wrote:
Hi,
I'm using CMake 2.8 rc3 on Ubuntu to build a modular and
extensible project. Therefore I have a directory called 'modules'
beneath the project root. In this folder may be
Hi all
I'm a bit struggling with using CMAKE_OSX_SYSROOT. The problem is that
find_library and cohorts do not consider CMAKE_OSX_SYSROOT at all,
thus reporting bogus paths.
I think that find_library, find_path and find_file (did I forget any?)
should honour CMAKE_OSX_SYSROOT and treat it
My project currently appends a d extension to all Debug executables (via
CMAKE_DEBUG_POSTFIX). How can I configure CTEST to use this alternate
extension when running Debug tests? (I was hoping for a similar
CTEST_DEBUG_POSTFIX variable)
UtilityTest.exe (Release)
-- Forwarded message --
From: Kevin Burge kevin.bu...@systemware.com
Date: Thu, Oct 29, 2009 at 10:41 AM
Subject: Re: [CMake] Does 2.8.0 rc4 not have the ZERO_CHECK fix?
To: John Drescher dresche...@gmail.com
I had a possibly related problem according to Bill Hoffman (windows
On 29. Oct, 2009, at 15:39 , Sean McBride wrote:
On 10/29/09 3:30 PM, Michael Wild said:
I'm a bit struggling with using CMAKE_OSX_SYSROOT. The problem is
that
find_library and cohorts do not consider CMAKE_OSX_SYSROOT at all,
thus reporting bogus paths.
I think that find_library,
Modestas Vainius wrote:
Hello,
On ketvirtadienis 29 Spalis 2009 14:50:14 Mathieu Malaterre wrote:
On Thu, Oct 29, 2009 at 1:35 PM, Bill Hoffman bill.hoff...@kitware.com
wrote:
Mathieu Malaterre wrote:
# ok we found jni.h, now derive other location from it:
get_filename_component(jni_path
On Thu, Oct 29, 2009 at 4:44 PM, Bill Hoffman bill.hoff...@kitware.com wrote:
Modestas Vainius wrote:
Hello,
On ketvirtadienis 29 Spalis 2009 14:50:14 Mathieu Malaterre wrote:
On Thu, Oct 29, 2009 at 1:35 PM, Bill Hoffman bill.hoff...@kitware.com
wrote:
Mathieu Malaterre wrote:
# ok
How about FIND_LIBRARY with fmcrt instead of libfmcrt ... ?
On Thu, Oct 29, 2009 at 12:46 PM, Dixon, Shane shane.di...@atmel.comwrote:
So gcc-fm.exe main.c -rdynamic fails ?
Yes, it fails.
Does gcc-fm.exe main.c -shared work ?
Yes, -shared seems to work.
I'm still having success with
I opened a bug report for this because it seems odd that FIND_PATH and
FIND_LIBRARY both have their mode set to ONLY and one works and the other
doesn't.
--
Shane Dixon
Linux Engineer
-Original Message-
From: cmake-boun...@cmake.org on behalf of Dixon, Shane
Sent: Thu 10/29/2009 10:46
No, that doesn't work either. :(
-Shane
-Original Message-
From: David Cole [mailto:david.c...@kitware.com]
Sent: Thu 10/29/2009 11:08 AM
To: Dixon, Shane
Cc: a.neundorf-w...@gmx.net; cmake@cmake.org
Subject: Re: [CMake] Toolchain.cmake causing find_library problems
How about
Modestas Vainius wrote:
P.S. Bill, when do you expect 2.8.0 final to be ready?
Hopefully soon. I am pretty much in regression fix only mode now.
-Bill
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
On Thu, Oct 29, 2009 at 7:16 PM, Alexander Neundorf
a.neundorf-w...@gmx.net wrote:
On Thursday 29 October 2009, Mathieu Malaterre wrote:
...
Done:
http://cmake.org/Bug/view.php?id=9793
Bug report include the test I used. Unfortunately find_package caches
results, so one need to manually
Le 29 oct. 09 à 13:07, Mathieu Malaterre a écrit :
Sorry but -again- I do not like your proposed fix. jni_md.h and jawt.h
should be found within the same subdirectory as jni.h (by contract).
So something like (not tested):
...
FIND_PATH(JAVA_INCLUDE_PATH jni.h
${JAVA_AWT_INCLUDE_DIRECTORIES}
Actually, using fmcrt does work. I had to clean out my build directory and it
worked. The other issues I was having was because the Makefiles I'm porting to
cmake use both cl and gcc so .lib's and .a's live together, which is bad for
CMake because it can't see both at the same time. I'm
Mathieu Malaterre wrote:
On Thu, Oct 29, 2009 at 7:16 PM, Alexander Neundorf
a.neundorf-w...@gmx.net wrote:
On Thursday 29 October 2009, Mathieu Malaterre wrote:
...
Done:
http://cmake.org/Bug/view.php?id=9793
Bug report include the test I used. Unfortunately find_package caches
results,
On Thursday 29 October 2009, Mathieu Malaterre wrote:
On Thu, Oct 29, 2009 at 7:16 PM, Alexander Neundorf
a.neundorf-w...@gmx.net wrote:
On Thursday 29 October 2009, Mathieu Malaterre wrote:
...
Done:
http://cmake.org/Bug/view.php?id=9793
Bug report include the test I used.
On Thu, Oct 29, 2009 at 7:51 PM, Alexander Neundorf
a.neundorf-w...@gmx.net wrote:
On Thursday 29 October 2009, Mathieu Malaterre wrote:
On Thu, Oct 29, 2009 at 7:16 PM, Alexander Neundorf
a.neundorf-w...@gmx.net wrote:
On Thursday 29 October 2009, Mathieu Malaterre wrote:
...
Done:
James C. Sutherland wrote:
It appears that the variable
HDF5_FOUND
is not being set in the FindHDF5.cmake module.
Any way of getting this fixed prior to the 2.8.0 release?
It is set for my systems when it is found. The standard system module
FindPackageHandleStandardArgs should set it
I'm getting a test failure in FindModulesExecuteAll building 2.8.0 rc4.
Is this expected? Do you really need every package installed for this
to succeed, or is it something else?
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division
Will Dicharry wrote:
Is there a 2.8.0 release branch where I can make that change?
Make the change in head, and I will merge it into the next RC.
-Bill
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
On 10/29/2009 02:31 PM, Will Dicharry wrote:
Orion,
While searching for probable causes of hdf5.h being in your /usr/include
without H5pubconf.h (it is required by hdf5.h), I came across some
patches in fedora 11 cvs that you have made to hdf5 code. Is it possible
that your system has a bad
On Oct 29, 2009, at 2:03 PM, Will Dicharry wrote:
James C. Sutherland wrote:
It appears that the variable
HDF5_FOUND
is not being set in the FindHDF5.cmake module.
Any way of getting this fixed prior to the 2.8.0 release?
It is set for my systems when it is found. The standard system
Orion,
While searching for probable causes of hdf5.h being in your /usr/include
without H5pubconf.h (it is required by hdf5.h), I came across some
patches in fedora 11 cvs that you have made to hdf5 code. Is it
possible that your system has a bad hdf5 install?
I plan on submitting the fix
On 10/29/2009 02:38 PM, Will Dicharry wrote:
Orion Poplawski wrote:
On 10/29/2009 02:31 PM, Will Dicharry wrote:
Orion,
While searching for probable causes of hdf5.h being in your /usr/include
without H5pubconf.h (it is required by hdf5.h), I came across some
patches in fedora 11 cvs that you
Orion Poplawski wrote:
On 10/29/2009 02:38 PM, Will Dicharry wrote:
Orion Poplawski wrote:
On 10/29/2009 02:31 PM, Will Dicharry wrote:
Orion,
While searching for probable causes of hdf5.h being in your
/usr/include
without H5pubconf.h (it is required by hdf5.h), I came across some
patches
Bill Hoffman wrote:
Will Dicharry wrote:
Is there a 2.8.0 release branch where I can make that change?
Make the change in head, and I will merge it into the next RC.
-Bill
Thanks, the change is committed.
Orion, is your site on the main CMake dashboard? If not, please let me
know if
On 10/29/2009 03:05 PM, Will Dicharry wrote:
Just so I understand...Are you referring to alternatives in the Fedora
packaging sense?
-- Will
Yes, so there would be a symbolic link chain as appropriate:
/usr/include/H5pubconf.h - /etc/alternatives/H5pubconf.h -
I'm using a custom gcc toolchain to cross-compile for a linux device. It
doesn't support -rdynamic. I've put in a bug so that when I set the compiler
and it does try_compile, it doesn't die on those that don't support
-rdynamic, but in the meantime I need to remove it from the link_flags. I
41 matches
Mail list logo
