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.
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 ->
/usr/include/H5pubconf-{32,
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 yo
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
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,
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 t
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
m
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 have made to hdf5 code. Is it possible
that yo
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 hdf5
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
http://www.kitware.
Orion Poplawski wrote:
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?
It looks like at least part of the problem is the FindHDF5 module:
if( HDF5_INCLUDE_DIR )
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
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 wh
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?
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/
On Thu, Oct 29, 2009 at 7:51 PM, Alexander Neundorf
wrote:
> On Thursday 29 October 2009, Mathieu Malaterre wrote:
>> On Thu, Oct 29, 2009 at 7:16 PM, Alexander Neundorf
>>
>> wrote:
>> > On Thursday 29 October 2009, Mathieu Malaterre wrote:
>> > ...
>> >
>> >> Done:
>> >> http://cmake.org/Bug/vi
On Thursday 29 October 2009, Mathieu Malaterre wrote:
> On Thu, Oct 29, 2009 at 7:16 PM, Alexander Neundorf
>
> 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. Unfortuna
Mathieu Malaterre wrote:
> On Thu, Oct 29, 2009 at 7:16 PM, Alexander Neundorf
> 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
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 havin
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
On Thu, Oct 29, 2009 at 7:16 PM, Alexander Neundorf
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 remove cmakecac
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 remove cmakecache.txt file before
> re-running this.
You can also use cmake-gui to
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
http://www.kitware.
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 FIND_LIBRA
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
How about FIND_LIBRARY with "fmcrt" instead of "libfmcrt" ... ?
On Thu, Oct 29, 2009 at 12:46 PM, Dixon, Shane wrote:
> 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 FIND_
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 FIND_PATH, but FIND_LIBRARY fails:
In toolchain.cmake:
INCLUDE( CMakeForceCompiler )
SET( CMAKE_SYSTEM_NAME Linux )
CMAKE_FORCE_C_COMPIL
On Thu, Oct 29, 2009 at 4:44 PM, Bill Hoffman 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
>>
>> wrote:
Mathieu Malaterre wrote:
>
> # ok we found jni.
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
wrote:
Mathieu Malaterre wrote:
# ok we found jni.h, now derive other location from it:
get_filename_component(jni_path ${JAVA_INCLUDE_PATH} PATH)
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, find_pat
-- Forwarded message --
From: Kevin Burge
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
I had a possibly related problem according to Bill Hoffman (windows
frequently rebuilding targets). I just switched b
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)
UtilityTes
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
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 a
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 modul
On Thu, Oct 29, 2009 at 9:45 AM, Kevin Burge 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
http://www.kitware.com/opensource/opensour
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 li
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 CMak
On Thu, Oct 29, 2009 at 1:35 PM, 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_pa
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
${jni_path}/fr
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 no
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 jawt.
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
__
On Thu, Oct 29, 2009 at 11:46 AM, Modestas Vainius 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 clue who did what.
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 CMakeLists.txt files. In the
CMakeLists.txt in project
On Thu, Oct 29, 2009 at 10:20 AM, Modestas Vainius 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
>> affect your
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
FIN
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 :
> CMake 2.8.0 RC 4 is now ready for people to try.
> You can find the source and binaries here:
47 matches
Mail list logo
