Re: [CMake] mingw32 linker line exceeds win32 limitations
On Fr, 2007-12-21 at 10:41 +0100, Felix Obenhuber wrote: Done. The Id is: 6192 [1] Thanks Brad for fixing! Works like a charm! Cheers, Felix ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Fwd: Re: [Help-gsl] problems raised by GPL v3 in GNU GLS
I forgot to copy this to the List -- Mensaje reenviado -- Asunto: Re: [Help-gsl] problems raised by GPL v3 in GNU GLS Fecha: Thu 03 Jan 2008 De: Pablo De Napoli [EMAIL PROTECTED] Para: Ralph Silva [EMAIL PROTECTED] El Thu 03 Jan 2008 03:45:16 escribió: Hi, most free softwares with GPLv2 come with the following description: ...under GPLv2 or *any later version*. So, choose *any later version *as GPLv3. Cheers, Ralph. Unfortunatelly, for the reasons that I've explained in my mail, things are not that simple. There exists some projects that are available under GPL version 2 only and the change to GPL v3 or GPL 2 on any later version is not that simple since every copyright holder must give permisson and copyright might be spread over a lot of people in some cases. Don't you seee my point here? Pablo --- ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Fwd: Re: [Help-gsl] problems raised by GPL v3 in GNU GLS
On Thursday 03 January 2008 13:43:58 Pablo De Napoli wrote: I forgot to copy this to the List -- Mensaje reenviado -- Asunto: Re: [Help-gsl] problems raised by GPL v3 in GNU GLS Fecha: Thu 03 Jan 2008 De: Pablo De Napoli [EMAIL PROTECTED] Para: Ralph Silva [EMAIL PROTECTED] El Thu 03 Jan 2008 03:45:16 escribió: Hi, most free softwares with GPLv2 come with the following description: ...under GPLv2 or *any later version*. So, choose *any later version *as GPLv3. Cheers, Ralph. Unfortunatelly, for the reasons that I've explained in my mail, things are not that simple. There exists some projects that are available under GPL version 2 only and the change to GPL v3 or GPL 2 on any later version is not that simple since every copyright holder must give permisson and copyright might be spread over a lot of people in some cases. Don't you seee my point here ? I recently asked fsf.org licensing support about this kind of stuff (I am going to switch a GPL v2 or later to GPLv3 and AGPLv3 for the code I can get agreement on). So for the GPLv2 only code you cannot relicense under GPLv3 unless you get agreement from all copyright holders of that code. Also notice that GPLv3 is not compatible with GPLv2 (because of the added restrictions to it) so you cannot easily mix code of both licenses. -- Mihai RUSU Email: [EMAIL PROTECTED] Linux is obsolete -- AST ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Fwd: Re: [Help-gsl] problems raised by GPL v3 in GNU GLS
Sorry, I've copied to the wrong list :) El Thu 03 Jan 2008 10:06:25 dizzy escribió: On Thursday 03 January 2008 13:43:58 Pablo De Napoli wrote: I forgot to copy this to the List ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] mingw32 linker line exceeds win32 limitations
Felix Obenhuber wrote: On Fr, 2007-12-21 at 10:41 +0100, Felix Obenhuber wrote: Done. The Id is: 6192 [1] Thanks Brad for fixing! Works like a charm! No problem. It actually cleaned up the implementation used for library linking too. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] mingw32 linker line exceeds win32 limitations
Gonzalo Garramuño wrote: Brad King wrote: CMake uses a link script approach to avoid placing the entire link line in the makefile. It is enabled on certain generators (including MinGW) and used for linking libraries but has not been yet needed for executables. Is the target for which you're having problems a library or an executable target? Is this the same as it is used with the NMake Generator? If so, please don't make this the default. It makes it impossible to see what the link line is when make VERBOSE=1. Or just have it turn on only when the line actually does exceed the limits. The fix is already in CMake HEAD in CVS. It is not the response file stuff used for NMake. The link line should be displayed in verbose mode. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] mingw32 linker line exceeds win32 limitations
On Jan 3, 2008, at 7:43 AM, Gonzalo Garramuño wrote: Brad King wrote: CMake uses a link script approach to avoid placing the entire link line in the makefile. It is enabled on certain generators (including MinGW) and used for linking libraries but has not been yet needed for executables. Is the target for which you're having problems a library or an executable target? Is this the same as it is used with the NMake Generator? If so, please don't make this the default. It makes it impossible to see what the link line is when make VERBOSE=1. Or just have it turn on only when the line actually does exceed the limits. Better yet, could we have make VERBOSE=1 spit out the temporary file as well? I've been irratated by not being able to see the contents of the compilation command, because it's hidden inside a file. James___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] mingw32 linker line exceeds win32 limitations
Brad King wrote: CMake uses a link script approach to avoid placing the entire link line in the makefile. It is enabled on certain generators (including MinGW) and used for linking libraries but has not been yet needed for executables. Is the target for which you're having problems a library or an executable target? Is this the same as it is used with the NMake Generator? If so, please don't make this the default. It makes it impossible to see what the link line is when make VERBOSE=1. Or just have it turn on only when the line actually does exceed the limits. -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Xubuntu Gutsy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.4.8 RC 9
I was just testing the dmg install on a Mac G5 running Mac OS X
10.4 . I do find it a touch odd that if I choose a directory
($dir) for install that it places it in $dir/usr. This means that
if I want to do an install into /usr/local I get a /usr/local/usr/
bin. That doesn't seem quite right.I haven't tried bundling my
own package yet.
Karl
On Jan 2, 2008, at 10:16 AM, Mike Jackson wrote:
On Jan 2, 2008, at 10:53 AM, Bill Hoffman wrote:
Bill Hoffman wrote:
I have a new beta release for 2.4.8 ready for cmake. This will
be the last release of the 2.4.X branch. The next release will
be 2.6.0. So,
please make sure you test it if you are interested in a 2.4.8.
Send any
issues to me or the cmake list. Thanks.
Just a reminder for folks to try 2.4.8 RC 9. I would like to
create the final 2.4.8 very soon
-Bill
Downloaded 2.4.8 RC9 source and compiled with ICC version 9.1.040
on OS X 10.4.11 (intel). I built RC-9 using CMake 2.4.7 if that
matters. I have a small example project with the following layout:
|--CMakeLists.txt
|--src
|foo.cxx
|foo.h
Here is my CMakeLists.txt file:
PROJECT (TestProj)
# -- Setup output Directories -
SET (LIBRARY_OUTPUT_PATH
${PROJECT_BINARY_DIR}/Bin
CACHE PATH
Single Directory for all Libraries
)
# - Setup the Executable output Directory -
SET (EXECUTABLE_OUTPUT_PATH
${PROJECT_BINARY_DIR}/Bin
CACHE PATH
Single Directory for all Executables.
)
INSTALL(DIRECTORY ${PROJECT_SOURCE_DIR}/src DESTINATION include/
TestProj
PATTERN *.h
)
# End CMakeLists.txt ---
Running cmake and then make install yields the following output:
[EMAIL PROTECTED]:Build]$ make install
Install the project...
-- Install configuration: Debug
-- Installing /tmp/include/TestProj/src
-- Installing /tmp/include/TestProj/src/foo.cxx
-- Installing /tmp/include/TestProj/src/foo.h
it is my understanding that ONLY the .h file should have been
installed. Is this a bug or just a misunderstanding of the usage of
INSTALL command?
Thanks
--
Mike Jackson
imikejackson gmail * com
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake will not be able to correctly generate this project.
I think you might be missing a very basic tenant of CMake: Out of Source Builds. CMake creates a pile of files and all the compiler output and all that sort of stuff _really_ needs to be gathered into it's own directory. The way you are running it currently, all those files will be put loose into your home directory. Try this: [EMAIL PROTECTED] ~]# cd /home/gregory/tarballs/canorus-0.5beta.R682 [EMAIL PROTECTED] ~]# mkdir Build [EMAIL PROTECTED] ~]# cd Build [EMAIL PROTECTED] ~]# cmake ../ [EMAIL PROTECTED] ~]# make And lets see what happens.. On Jan 3, 2008, at 11:09 AM, Gregory Anderson wrote: I have had some troubles with cmake (or maybe gcc). I keep getting this error whenever I try to use it. gcc is installed. [EMAIL PROTECTED] ~]# cmake /home/gregory/tarballs/canorus-0.5beta.R682 -- Check for working C compiler: /usr/lib/ccache/gcc -- Check for working C compiler: /usr/lib/ccache/gcc -- broken CMake Error: The C compiler /usr/lib/ccache/gcc is not able to compile a simple test program. It fails with the following output: /usr/bin/gmake -f CMakeFiles/cmTryCompileExec.dir/build.make CMakeFiles/cmTryCompileExec.dir/build gmake[1]: Entering directory `/home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp' /usr/bin/cmake -E cmake_progress_report /home/gregory/tarballs/canorus-0.5beta.R682/ CMakeFiles/CMakeTmp/CMakeFiles 1 Building C object CMakeFiles/cmTryCompileExec.dir/testCCompiler.o /usr/lib/ccache/gcc -o CMakeFiles/cmTryCompileExec.dir/ testCCompiler.o -c /home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp/ testCCompiler.c /home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp/ testCCompiler.c:4:19: error: stdio.h: No such file or directory /home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp/ testCCompiler.c: In function ‘main’: /home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp/ testCCompiler.c:12: warning: incompatible implicit declaration of built-in function ‘printf’ gmake[1]: Leaving directory `/home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp' gmake[1]: *** [CMakeFiles/cmTryCompileExec.dir/testCCompiler.o] Error 1 gmake: *** [cmTryCompileExec/fast] Error 2 CMake will not be able to correctly generate this project. -- Configuring done Can anyone point me in the right direction? Thanks in advance, Greg ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake -- Mike Jackson Senior Research Engineer Innovative Management Technology Services ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.4.8 RC 9
Karl Merkley wrote: I was just testing the dmg install on a Mac G5 running Mac OS X 10.4 . I do find it a touch odd that if I choose a directory ($dir) for install that it places it in $dir/usr. This means that if I want to do an install into /usr/local I get a /usr/local/usr/bin. That doesn't seem quite right.I haven't tried bundling my own package yet. That will be fixed in 2.6 but the fixes for that are too large for the 2.4.8 branch. But, the /usr/local thing is really sort of bad. I will look into seeing if some hack can be put on the branch to get around this -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.4.8 RC 9
On Jan 3, 2008, at 11:20 AM, Bill Hoffman wrote: Karl Merkley wrote: I was just testing the dmg install on a Mac G5 running Mac OS X 10.4 . I do find it a touch odd that if I choose a directory ($dir) for install that it places it in $dir/usr. This means that if I want to do an install into /usr/local I get a /usr/local/ usr/bin. That doesn't seem quite right.I haven't tried bundling my own package yet. That will be fixed in 2.6 but the fixes for that are too large for the 2.4.8 branch. But, the /usr/local thing is really sort of bad. I will look into seeing if some hack can be put on the branch to get around this -Bill Bill, having worked with packagemaker before I believe this is a simple fix. Who ever is packaging cmake should NOT use /usr as the root, but pack the bin/ share/ loose in the package. That way when someone selects /usr/local or even /usr the proper structure is built/ used. -- Mike Jackson imikejackson gmail * com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMake will not be able to correctly generate this project.
I have had some troubles with cmake (or maybe gcc). I keep getting this error whenever I try to use it. gcc is installed. [EMAIL PROTECTED] ~]# cmake /home/gregory/tarballs/canorus-0.5beta.R682 -- Check for working C compiler: /usr/lib/ccache/gcc -- Check for working C compiler: /usr/lib/ccache/gcc -- broken CMake Error: The C compiler /usr/lib/ccache/gcc is not able to compile a simple test program. It fails with the following output: /usr/bin/gmake -f CMakeFiles/cmTryCompileExec.dir/build.make CMakeFiles/cmTryCompileExec.dir/build gmake[1]: Entering directory `/home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp' /usr/bin/cmake -E cmake_progress_report /home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp/CMakeFiles 1 Building C object CMakeFiles/cmTryCompileExec.dir/testCCompiler.o /usr/lib/ccache/gcc -o CMakeFiles/cmTryCompileExec.dir/testCCompiler.o -c /home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp/testCCompiler.c /home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp/testCCompiler.c:4:19: error: stdio.h: No such file or directory /home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp/testCCompiler.c: In function ‘main’: /home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp/testCCompiler.c:12: warning: incompatible implicit declaration of built-in function ‘printf’ gmake[1]: Leaving directory `/home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp' gmake[1]: *** [CMakeFiles/cmTryCompileExec.dir/testCCompiler.o] Error 1 gmake: *** [cmTryCompileExec/fast] Error 2 CMake will not be able to correctly generate this project. -- Configuring done Can anyone point me in the right direction? Thanks in advance, Greg ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.4.8 RC 9
On 1/3/08 8:44 AM, Karl Merkley said: I was just testing the dmg install on a Mac G5 running Mac OS X 10.4 . I do find it a touch odd that if I choose a directory ($dir) for install that it places it in $dir/usr. This means that if I want to do an install into /usr/local I get a /usr/local/usr/ bin. That doesn't seem quite right. I missed the exciting discussion over the holidays about Mac install issues. I was happy to see that an install location choice is now possible. But I can confirm Karl's observations, and have to agree that it is odd. Is this simply a bug? Surely Apple's Installer application is not so inflexible that this is the best possible? Additionally, is it normal that the items installed (files and folders) have file owner and group both as 501? My user id is not 501. -- Sean McBride, B. Eng [EMAIL PROTECTED] Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.4.8 RC 9
On Jan 3, 2008, at 11:25 AM, Sean McBride wrote: Additionally, is it normal that the items installed (files and folders) have file owner and group both as 501? My user id is not 501. This is an error in the initial packaging. Since OS X PackageMaker uses tar (basically) for its archive all the user ids and permissions are left over from whomever did the packaging. When I did this sort of thing I usually ran a post build script that set all the permissions, user and group ids to what was expected, THEN ran packagemaker on the result directory tree. -- Mike Jackson imikejackson gmail * com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.4.8 RC 9
On Jan 3, 2008, at 11:38 AM, Bill Hoffman wrote: Mike Jackson wrote: On Jan 3, 2008, at 11:25 AM, Sean McBride wrote: Additionally, is it normal that the items installed (files and folders) have file owner and group both as 501? My user id is not 501. This is an error in the initial packaging. Since OS X PackageMaker uses tar (basically) for its archive all the user ids and permissions are left over from whomever did the packaging. When I did this sort of thing I usually ran a post build script that set all the permissions, user and group ids to what was expected, THEN ran packagemaker on the result directory tree. This is all fixed in CVS. The problems are in CPack. It requires too much code moving to get all the fixes into 2.4.8. I am thinking I will just yank the ability to move the install for 2.4.8. We have gotten along without it this far, and the current fix seems to be worst than what we had before. -Bill Unfortunately I agree with you. I would rather have it be _correctly_ installed in /usr than all messed up everywhere. Lets get it correct for 2.6. -- Mike Jackson imikejackson gmail * com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake will not be able to correctly generate this project.
I ran these commands but I still got the same error message at the cmake ../ stage. [EMAIL PROTECTED] ~]# cd /home/gregory/tarballs/canorus-0.5beta.R682 [EMAIL PROTECTED] canorus-0.5beta.R682]# mkdir Build [EMAIL PROTECTED] canorus-0.5beta.R682]# cd Build [EMAIL PROTECTED] Build]# cmake ../ -- Check for working C compiler: /usr/lib/ccache/gcc -- Check for working C compiler: /usr/lib/ccache/gcc -- broken CMake Error: The C compiler /usr/lib/ccache/gcc is not able to compile a simple test program. It fails with the following output: /usr/bin/gmake -f CMakeFiles/cmTryCompileExec.dir/build.make CMakeFiles/cmTryCompileExec.dir/build gmake[1]: Entering directory `/home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp' /usr/bin/cmake -E cmake_progress_report /home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp/CMakeFiles 1 Building C object CMakeFiles/cmTryCompileExec.dir/testCCompiler.o /usr/lib/ccache/gcc -o CMakeFiles/cmTryCompileExec.dir/testCCompiler.o -c /home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp/testCCompiler.c /home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp/testCCompiler.c:4:19: error: stdio.h: No such file or directory /home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp/testCCompiler.c: In function ‘main’: /home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp/testCCompiler.c:12: warning: incompatible implicit declaration of built-in function ‘printf’ gmake[1]: Leaving directory `/home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp' gmake[1]: *** [CMakeFiles/cmTryCompileExec.dir/testCCompiler.o] Error 1 gmake: *** [cmTryCompileExec/fast] Error 2 CMake will not be able to correctly generate this project. -- Configuring done [EMAIL PROTECTED] Build]# make make: *** No targets specified and no makefile found. Stop. [EMAIL PROTECTED] Build]# On Thu, 2008-01-03 at 11:15 -0500, Mike Jackson wrote: I think you might be missing a very basic tenant of CMake: Out of Source Builds. CMake creates a pile of files and all the compiler output and all that sort of stuff _really_ needs to be gathered into it's own directory. The way you are running it currently, all those files will be put loose into your home directory. Try this: [EMAIL PROTECTED] ~]# cd /home/gregory/tarballs/canorus-0.5beta.R682 [EMAIL PROTECTED] ~]# mkdir Build [EMAIL PROTECTED] ~]# cd Build [EMAIL PROTECTED] ~]# cmake ../ [EMAIL PROTECTED] ~]# make And lets see what happens.. On Jan 3, 2008, at 11:09 AM, Gregory Anderson wrote: I have had some troubles with cmake (or maybe gcc). I keep getting this error whenever I try to use it. gcc is installed. [EMAIL PROTECTED] ~]# cmake /home/gregory/tarballs/canorus-0.5beta.R682 -- Check for working C compiler: /usr/lib/ccache/gcc -- Check for working C compiler: /usr/lib/ccache/gcc -- broken CMake Error: The C compiler /usr/lib/ccache/gcc is not able to compile a simple test program. It fails with the following output: /usr/bin/gmake -f CMakeFiles/cmTryCompileExec.dir/build.make CMakeFiles/cmTryCompileExec.dir/build gmake[1]: Entering directory `/home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp' /usr/bin/cmake -E cmake_progress_report /home/gregory/tarballs/canorus-0.5beta.R682/ CMakeFiles/CMakeTmp/CMakeFiles 1 Building C object CMakeFiles/cmTryCompileExec.dir/testCCompiler.o /usr/lib/ccache/gcc -o CMakeFiles/cmTryCompileExec.dir/ testCCompiler.o -c /home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp/ testCCompiler.c /home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp/ testCCompiler.c:4:19: error: stdio.h: No such file or directory /home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp/ testCCompiler.c: In function ‘main’: /home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp/ testCCompiler.c:12: warning: incompatible implicit declaration of built-in function ‘printf’ gmake[1]: Leaving directory `/home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp' gmake[1]: *** [CMakeFiles/cmTryCompileExec.dir/testCCompiler.o] Error 1 gmake: *** [cmTryCompileExec/fast] Error 2 CMake will not be able to correctly generate this project. -- Configuring done Can anyone point me in the right direction? Thanks in advance, Greg ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.4.8 RC 9
Mike Jackson wrote: On Jan 3, 2008, at 11:25 AM, Sean McBride wrote: Additionally, is it normal that the items installed (files and folders) have file owner and group both as 501? My user id is not 501. This is an error in the initial packaging. Since OS X PackageMaker uses tar (basically) for its archive all the user ids and permissions are left over from whomever did the packaging. When I did this sort of thing I usually ran a post build script that set all the permissions, user and group ids to what was expected, THEN ran packagemaker on the result directory tree. This is all fixed in CVS. The problems are in CPack. It requires too much code moving to get all the fixes into 2.4.8. I am thinking I will just yank the ability to move the install for 2.4.8. We have gotten along without it this far, and the current fix seems to be worst than what we had before. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake will not be able to correctly generate this project.
I understand what you mean but fixing the path is a bit over my head. How do I fix the path? On Thu, 2008-01-03 at 11:52 -0500, Mike Jackson wrote: It looks as though your c compiler is broken, which is really to say that the ccache/gcc wrapper either is not looking in the proper location for standard include files OR your standard C include files are NOT in a location that is known. On Jan 3, 2008, at 11:46 AM, Gregory Anderson wrote: I ran these commands but I still got the same error message at the cmake ../ stage. [EMAIL PROTECTED] ~]# cd /home/gregory/tarballs/canorus-0.5beta.R682 [EMAIL PROTECTED] canorus-0.5beta.R682]# mkdir Build [EMAIL PROTECTED] canorus-0.5beta.R682]# cd Build [EMAIL PROTECTED] Build]# cmake ../ -- Check for working C compiler: /usr/lib/ccache/gcc -- Check for working C compiler: /usr/lib/ccache/gcc -- broken CMake Error: The C compiler /usr/lib/ccache/gcc is not able to compile a simple test program. It fails with the following output: /usr/bin/gmake -f CMakeFiles/cmTryCompileExec.dir/build.make CMakeFiles/cmTryCompileExec.dir/build gmake[1]: Entering directory `/home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp' /usr/bin/cmake -E cmake_progress_report /home/gregory/tarballs/canorus-0.5beta.R682/ CMakeFiles/CMakeTmp/CMakeFiles 1 Building C object CMakeFiles/cmTryCompileExec.dir/testCCompiler.o /usr/lib/ccache/gcc -o CMakeFiles/cmTryCompileExec.dir/ testCCompiler.o -c /home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp/ testCCompiler.c /home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp/ testCCompiler.c:4:19: error: stdio.h: No such file or directory /home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp/ testCCompiler.c: In function ‘main’: /home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp/ testCCompiler.c:12: warning: incompatible implicit declaration of built-in function ‘printf’ gmake[1]: Leaving directory `/home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp' gmake[1]: *** [CMakeFiles/cmTryCompileExec.dir/testCCompiler.o] Error 1 gmake: *** [cmTryCompileExec/fast] Error 2 CMake will not be able to correctly generate this project. -- Configuring done [EMAIL PROTECTED] Build]# make make: *** No targets specified and no makefile found. Stop. [EMAIL PROTECTED] Build]# On Thu, 2008-01-03 at 11:15 -0500, Mike Jackson wrote: I think you might be missing a very basic tenant of CMake: Out of Source Builds. CMake creates a pile of files and all the compiler output and all that sort of stuff _really_ needs to be gathered into it's own directory. The way you are running it currently, all those files will be put loose into your home directory. Try this: [EMAIL PROTECTED] ~]# cd /home/gregory/tarballs/canorus-0.5beta.R682 [EMAIL PROTECTED] ~]# mkdir Build [EMAIL PROTECTED] ~]# cd Build [EMAIL PROTECTED] ~]# cmake ../ [EMAIL PROTECTED] ~]# make And lets see what happens.. On Jan 3, 2008, at 11:09 AM, Gregory Anderson wrote: I have had some troubles with cmake (or maybe gcc). I keep getting this error whenever I try to use it. gcc is installed. [EMAIL PROTECTED] ~]# cmake /home/gregory/tarballs/ canorus-0.5beta.R682 -- Check for working C compiler: /usr/lib/ccache/gcc -- Check for working C compiler: /usr/lib/ccache/gcc -- broken CMake Error: The C compiler /usr/lib/ccache/gcc is not able to compile a simple test program. It fails with the following output: /usr/bin/gmake -f CMakeFiles/cmTryCompileExec.dir/build.make CMakeFiles/cmTryCompileExec.dir/build gmake[1]: Entering directory `/home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp' /usr/bin/cmake -E cmake_progress_report /home/gregory/tarballs/canorus-0.5beta.R682/ CMakeFiles/CMakeTmp/CMakeFiles 1 Building C object CMakeFiles/cmTryCompileExec.dir/testCCompiler.o /usr/lib/ccache/gcc -o CMakeFiles/cmTryCompileExec.dir/ testCCompiler.o -c /home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp/ testCCompiler.c /home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp/ testCCompiler.c:4:19: error: stdio.h: No such file or directory /home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp/ testCCompiler.c: In function ‘main’: /home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp/ testCCompiler.c:12: warning: incompatible implicit declaration of built-in function ‘printf’ gmake[1]: Leaving directory `/home/gregory/tarballs/canorus-0.5beta.R682/CMakeFiles/CMakeTmp' gmake[1]: *** [CMakeFiles/cmTryCompileExec.dir/testCCompiler.o] Error 1 gmake: *** [cmTryCompileExec/fast] Error 2 CMake will not be able to correctly generate this project. -- Configuring done Can anyone point me in the right direction? Thanks in advance, Greg ___
Re: [CMake] CMake will not be able to correctly generate this project.
On Jan 3, 2008 12:06 PM, Gregory Anderson [EMAIL PROTECTED] wrote: I understand what you mean but fixing the path is a bit over my head. How do I fix the path? Why don't you just reinstall the compiler? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.4.8 RC 9
On 1/3/08 11:38 AM, Bill Hoffman said: This is all fixed in CVS. The problems are in CPack. It requires too much code moving to get all the fixes into 2.4.8. I am thinking I will just yank the ability to move the install for 2.4.8. We have gotten along without it this far, and the current fix seems to be worst than what we had before. I am forced to agree. :( Though I really look forward to a working 'choose install location' feature. -- Sean McBride, B. Eng [EMAIL PROTECTED] Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake will not be able to correctly generate this project.
On Thu, 2008-01-03 at 12:22 -0500, Brandon Van Every wrote: On Jan 3, 2008 12:06 PM, Gregory Anderson [EMAIL PROTECTED] wrote: I understand what you mean but fixing the path is a bit over my head. How do I fix the path? Why don't you just reinstall the compiler? I did a few times. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake will not be able to correctly generate this project.
On Jan 3, 2008 12:31 PM, Gregory Anderson [EMAIL PROTECTED] wrote: On Thu, 2008-01-03 at 12:22 -0500, Brandon Van Every wrote: On Jan 3, 2008 12:06 PM, Gregory Anderson [EMAIL PROTECTED] wrote: I understand what you mean but fixing the path is a bit over my head. How do I fix the path? Why don't you just reinstall the compiler? I did a few times. Try fooling with the GCC environment variables. http://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html I think occasionally I've had to set C_INCLUDE_PATH and LIBRARY_PATH, but really, this stuff should already be set up for you and just work if you're using some kind of standard GCC package. Or did you build GCC from scratch or something? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] win32 problem with export_library_dependencies
Hi,
the cmake function export_library_dependencies creates - as the name
indicates - library dependency informations.
At least for kdelibs and kdepimlibs these dependencies are placed into a
file which is installed and released along with all the other installed
files of the related package. Other source packages use this dependency
file at configure time to determine to which libraries local
libraries/application have to link to. Below is an example of the file
KDELibsDependencies.cmake created for the kdelibs package on a german
win32 system.
SET(kdecore_LIB_DEPENDS
C:/Programme/kdewin/lib/QtCore4.lib;C:/Programme/kdewin/lib/QtCored4.lib;C:/Programme/kdewin/lib/QtNetwork4.lib;C:/Programme/kdewin/lib/QtNetworkd4.lib;C:/Programme/kdewin/lib/QtDBus4.lib;C:/Programme/kdewin/lib/QtDBusd4.lib;C:/Programme/kdewin/lib/QtXml4.lib;C:/Programme/kdewin/lib/QtXmld4.lib;C:/Programme/kdewin/lib/zlib.lib;C:/Programme/kdewin/lib/kdewin32.lib
;user32;shell32;ws2_32;netapi32;userenv;C:/Programme/kdewin/lib/bzip2.lib;C:/Programme/kdewin/lib/libintl.lib;)
SET(C:/Programme/kdewin/lib/QtCore4.lib_LINK_TYPE optimized)
SET(C:/Programme/kdewin/lib/QtCored4.lib_LINK_TYPE debug)
SET(C:/Programme/kdewin/lib/QtNetwork4.lib_LINK_TYPE optimized)
SET(C:/Programme/kdewin/lib/QtNetworkd4.lib_LINK_TYPE debug)
SET(C:/Programme/kdewin/lib/QtDBus4.lib_LINK_TYPE optimized)
SET(C:/Programme/kdewin/lib/QtDBusd4.lib_LINK_TYPE debug)
The problem now is that the hardcoded pathes are valid on kdelibs
compile time on a specific computer but may not be valid on other
computers (for example on an english installed pc which uses c:/Program
Files/ by default) or if the installation uses different pathes or drives.
To solve this problem it is required that export_library_dependencies
do not print out hardcoded pathes instead it should print out the
related variable names from the CMakeCache.txt file.
Let me explain this with an example for some dependencies. In the
kdelibs build CMakeCache.txt file there are the following definitions:
//Path to a library.
QT_QTCORE_LIBRARY:FILEPATH=C:/Programme/kdewin/lib/QtCore4.lib
//Path to a library.
QT_QTCORE_LIBRARY_DEBUG:FILEPATH=C:/Programme/kdewin/lib/QtCored4.lib
export_library_dependencies should create the following definitions
SET(kdecore_LIB_DEPENDS
${QT_QTCORE_LIBRARY};${QT_QTCORE_LIBRARY_DEBUG};...)
SET(${QT_QTCORE_LIBRARY}_LINK_TYPE optimized)
SET(${QT_QTCORE_LIBRARY_DEBUG}_LINK_TYPE debug)
(only a subset of the real required dependencies are listed)
To provide a complete patch it would need more time to dig into the
cmake internals (I haven't found a short way to get the cmake cache
variable name of a related dependency) so at now I can only give some
hints for the required implementation.
The related part is located in the method void
cmExportLibraryDependenciesCommand::ConstFinalPass() line 100 and
following.
To enable this mode of operation there should be an additional optional
parameter for export_library_dependencies as mentioned below in the
related help page.
--help-command output
Write out the dependency information for all targets of a project.
export_library_dependencies(file [SYMBOLIC] [APPEND])
Create a file named file that can be included into a CMake listfile
with the INCLUDE command. The file will contain a number of SET
commands that will set all the variables needed for library dependency
information. This should be the last command in the top level
CMakeLists.txt file of the project.
If the SYMBOLIC option is specified, the SET commands will use
variable names instead of hardcoded library pathes.
If the APPEND option is specified, the SET commands will be appended
to the given file instead of replacing it.
-
BTW: This type of operation may also help to support non standard
dependency path locations on unix too.
Would it be possible to implement such a feature in cmake ?
Ralf
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake will not be able to correctly generate this project.
Cmake is now working. I haven't finished installing the program yet though because I do not have the time. I will finish it tomarrow as long as all goes well. I did not have gdb installed. That fixed it. Just incase anyone is curious I am running Fedora 8 with Planet ccrma and all the packages were installed via yum. Thanks for all the very quick help. Greg. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
