Re: [CMake] ifort,icc,icpc: ld: cannot find -lcilkrts
On 11/12/2011 08:48 AM, Ilias Miroslav wrote: > Dear experts, > > our problem is that cmake sets automatically linking libraries for C,C++ and > with Intel compilers (Fortran,C,C++) we are getting these problems > ( first observed here > https://repo.ctcc.no/CDash/viewBuildError.php?buildid=5283 ) : > . > . > . > Linking Fortran executable dirac.x > /people/disk2/ilias/bin/cmake_install/bin/cmake -E cmake_link_script > CMakeFiles/dirac.x.dir/link.txt --verbose=1 > /people/disk2/magnus/intel/composerxe-2011.2.137/bin/intel64/ifort-static > -Wl,-E -w -assume byterecl -DVAR_IFORT -g -traceback -static-libgcc > -static-intel -i8 -O0 CMakeFiles/dirac.x.dir/main/main.F90.o -o dirac.x > -i_dynamic lib/libdirac.a lib/libxcfun.a -ldecimal -lcilkrts -lstdc++ -lirc > ld: cannot find -lcilkrts > make[3]: *** [dirac.x] Error 1 > . > > Manual linking without the "-lcilkrts" flag works: > > il...@fe6.dcsc.sdu.dk:~/QCH_Work/qch_progs/dirac_git/trunk/build_ompi_ifort_icc_ilp64_static/./people/disk2/magnus/intel/composerxe-2011.2.137/bin/intel64/ifort > -static -Wl,-E -w -assume byterecl -DVAR_IFORT -g -traceback > -static-libgcc -static-intel -i8 -O0 CMakeFiles/dirac.x.dir/main/main.F90.o > -o dirac.x -i_dynamic lib/libdirac.a lib/libxcfun.a -ldecimal -lstdc++ -lirc > il...@fe6.dcsc.sdu.dk:~/QCH_Work/qch_progs/dirac_git/trunk/build_ompi_ifort_icc_ilp64_static/. > > The problematic "cilkrts" library is set automatically within > CMAKE_C_IMPLICIT_LINK_LIBRARIES & CMAKE_CXX_IMPLICIT_LINK_LIBRARIES > variables, as found: > > il...@fe6.dcsc.sdu.dk:~/QCH_Work/qch_progs/dirac_git/trunk/build_ompi_ifort_icc_ilp64_static/.grep > cilkrts * */* > . > CMakeFiles/CMakeCCompiler.cmake:SET(CMAKE_C_IMPLICIT_LINK_LIBRARIES > "imf;svml;m;ipgo;decimal;cilkrts;stdc++;irc;c;irc_s;dl;c") > CMakeFiles/CMakeCXXCompiler.cmake:SET(CMAKE_CXX_IMPLICIT_LINK_LIBRARIES > "imf;svml;m;ipgo;decimal;cilkrts;stdc++;irc;c;irc_s;dl;c") > . > . > > Please how to remove "cilkrts" or any other parameter from > CMAKE__IMPLICIT_LINK_LIBRARIES, > http://www.cmake.org/cmake/help/cmake-2-8-docs.html#variable:CMAKE_LANG_IMPLICIT_LINK_LIBRARIES > ? > > We have cmake version 2.8.4 and Intel is Intel(R) 64, Version 12.0.2.137 > Build 20110112. > > Yours, M.Ilias Perhaps, you might check how the offending library makes it into the CMAKE__IMPLICIT_LINK_LIBRARIES variables. IIRC, these libraries are determined by building a small test program and analyzing the link command line, so linking against the cilkrts library should basically work if it appears among the implicit link libraries. The results of the analysis are reported in CMakeFiles/CMakeOutput.log; could you post it, or the relevant part thereof, for further investigation? Regards, Michael -- 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 link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Issue with check_include_file() and GL/glxproto.h
On 11/11/2011 12:42 PM, GOUJON Alexandre wrote:
> On 11/11/2011 04:13 AM, Michael Hertling wrote:
>> On 11/10/2011 11:22 PM, Eric Noulard wrote:
>>> If this is the case then it is a "GL/glxproto.h" design mistake
>>> not CMake mistake.
>> Absolutely, try to compile the following program by hand; it's
>> the same the CHECK_INCLUDE_FILE() macro tries to compile, too:
>>
>> #include
>> int main(void){return 0;}
>>
>> It will fail with the same error message, i.e. the GL/glxproto.h header
>> is not self-sufficient; if intentionally or accidentally, I don't know.
>> It's this failure that makes CHECK_INCLUDE_FILE() report the header as
>> non-existent, or better as "not compilable".
> I just sent them an e-mail so that they will be aware of the issue.
Is the GL/glxproto.h header a public one or is it private, i.e. is it
meant to be included explicitly by client code or not? In the latter
case, by convention, it usually needs not to be self-sufficient.
>>> This is true but the documentation tells you more about the macro
>>> cmake --help-module CheckIncludeFile
>>>
>>> says
>>> "an optional third argument is the CFlags to add to the compile line or
>>> you can use CMAKE_REQUIRED_FLAGS"
>>>
>>> which clearly states that it does a compilation.
>> Indeed, CHECK_INCLUDE_FILE() means: Check if a header is *functional*.
> Ok, will use find_file instead.
>>> The thing you want is probably
>>>
>>> if(DEFINED VARIABLE)
>>> message(FATAL_ERROR "VARIABLE already defined :<${VARIABLE}> aborting")
>>> endif()
> Yeah, thanks.
>>> I think it's not the responsability of check_include_file to do such job
>>> but you can do that in your CMakeLists.txt
>> With FIND_FILE/PATH() looking for a header, the user must have the
>> possibility to make them no-ops by presetting the result variable,
>> so these functions must not overwrite a valid path. However, with
>> CHECK_INCLUDE_FILE(), the user can't "define" a header as working;
>> thus, there is no need to protect an already defined variable from
>> being overwritten, IMO. Moreover, the user must have the chance to
>> reuse the same variable for this purpose again without having the
>> configuration terminate. OTOH, one usually uses an individually
>> named variable for each header, e.g. HAVE_GL_GLXPROTO_H, as you
>> do, which is most certainly not reused for anything at all.
> Ok but as I didn't understand why check_include_file was failing, I
> tried many things like simple then double quoting GL/glxproto.h and also
> tried a different variable name. I took HAVE_UNISTDE_H because I knew
> HAVE_UNISTD_H was working. With HAVE_UNISTDE_H, check_include_file
> seemed to work (it wasn't true, this variable name was simply defined
> before elsewhere) so in the end, I believed some variable names were
> allowed and others not. So to avoid the same mistake, I thought a
> message (at least a STATUS one) wouldn't hurt.
IF("${VARIABLE}" MATCHES "^${VARIABLE}$") fails : is it intended ?
>>> I do not understand
>>> In which case does it fail?
> Actually, every time.
> Here is the beginning of my modified CheckIncludeFile.cmake :
>
> MACRO(CHECK_INCLUDE_FILE INCLUDE VARIABLE)
> message(STATUS "${VARIABLE}")
>IF("${VARIABLE}" MATCHES "^${VARIABLE}$")
> message(STATUS "${VARIABLE} matches ^${VARIABLE}$")
>
> and I only have the following output
> -- HAVE_SYS_TIME_H
> -- HAVE_SYS_TYPES_H
> -- HAVE_SYS_RESOURCE_H
> -- HAVE_SYS_STAT_H
> -- HAVE_UNISTD_H
> -- HAVE_FCNTL_H
> -- HAVE_GL_GLXPROTO_H
> CMake Error at CMakeLists.txt:117 (message):
> [..]
>
> So the first IF is failing, skipping the whole macro.
> If I add a # before this IF (and the corresponding ENDIF),
> check_include_file does its jobs and even finds the other headers :
> [...]
> -- HAVE_FCNTL_H
> -- HAVE_FCNTL_H matches ^HAVE_FCNTL_H$
> -- Looking for fcntl.h
> -- Looking for fcntl.h - found
> -- HAVE_GL_GLXPROTO_H
> -- HAVE_GL_GLXPROTO_H matches ^HAVE_GL_GLXPROTO_H$
> -- Looking for GL/glxproto.h
> -- Looking for GL/glxproto.h - not found
>
> Any idea ?
Sorry, I talked nonsense in my previous reply. Obviously, the line
IF("${VARIABLE}" MATCHES "^${VARIABLE}$")
serves to prevent the macro's re-execution if the result variable is
already defined, i.e. if the macro has most certainly been called
before with the same parameters. E.g., with VARIABLE equaling
"HAVE_XYZ_H", this line expands to
IF(HAVE_XYZ_H MATCHES ^HAVE_XYZ_H$)
and due to the implicit evaluation of variables on the left-hand
side of the IF() command's MATCHES clause, it finally looks like
IF(TRUE MATCHES ^HAVE_XYZ_H$)
or
IF(FALSE MATCHES ^HAVE_XYZ_H$)
provided the macro has been called before, i.e. HAVE_XYZ_H is either
TRUE or FALSE. Of course, these latter conditions are false, so the
macro isn't executed again. OTOH, if the variable HAVE_XYZ_H is un-
defined, i.e. the macro has not been called yet, the line remains
IF(HAVE_XYZ_H MATCHES ^HAVE_XYZ_H$)
which is true, so the macro is executed. Therefore, the macro is
skipped if
Re: [CMake] /usr/bin/gcc -o tcl2c++ -rdynamic \n gcc: fatal error: no input files
On 11/12/2011 02:48 PM, YunQiang Su wrote:
> I do an cmake program, but encount an stranger problem.
>
> 1. mkdir tmp; cd tmp
> 2. tar -zxvf ../cmake-test.tar.gz
> 3. mkdir build; cd build
> 4. cmake ..; make
>
> I got an error:
> /usr/bin/gcc-o tcl2c++ -rdynamic
> gcc: fatal error: no input files
>
> Then
> 1. cd ..
> 1. head -51 CMakeLists.txt >CMakeLists.txt.tmp
> 2. mv CMakeLists.txt.tmp CMakeLists.txt
> 3. cd build
> 4. rm -fr *
> 5. cmake ..; make
>
> It works now.
>
> Why?
Because of the MAIN_DEPENDENCY clause in the custom command; it's just
meant as a hint for Visual Studio, but not to establish a dependency,
and apparently, the Makefile generators are tangled when seeing this
clause. Actually, you don't need to explicitly declare a dependency
on the tcl2c++ executable at all; using the target name suffices.
The attached patch makes your project build on my system.
Regards,
Michael
--- CMakeLists.txt.bak 2011-11-13 01:51:16.981958217 +0100
+++ CMakeLists.txt 2011-11-13 01:51:55.492364967 +0100
@@ -95,16 +95,13 @@
set(CONSOLE_FILES ${LIBRARY_TK}/console.tcl)
-set(TCL2CPP ${CMAKE_CURRENT_BINARY_DIR}/tcl2c++)
-
add_custom_command(OUTPUT embedded-tcl.cc embedded-tk.cc embedded-tclobj.cc
- COMMAND ${TCL2CPP} ARGS et_tcl ${TCL_LIBRARY_FILES} > embedded-tcl.cc
+ COMMAND tcl2c++ et_tcl ${TCL_LIBRARY_FILES} > embedded-tcl.cc
COMMAND "sed -i -e 's/package require -exact T/package require T/g' embedded-tcl.cc"
- COMMAND ${TCL2CPP} ARGS et_tk ${TK_LIBRARY_FILES} > embedded-tk.cc
+ COMMAND tcl2c++ et_tk ${TK_LIBRARY_FILES} > embedded-tk.cc
COMMAND "sed -i -e 's/package require -exact T/package require T/g' embedded-tk.cc"
- COMMAND ${TCL2CPP} ARGS et_tclobject tcl-object.tcl tcl-import.tcl tcl-http.tcl > embedded-tclobj.cc
- COMMAND ${TCL2CPP} ARGS et_console ${CONSOLE_FILES} > embedded-console.cc
- MAIN_DEPENDENCY tcl2c++
+ COMMAND tcl2c++ et_tclobject tcl-object.tcl tcl-import.tcl tcl-http.tcl > embedded-tclobj.cc
+ COMMAND tcl2c++ et_console ${CONSOLE_FILES} > embedded-console.cc
)
#pkg_check_modules(OTCL REQUIRED otcl)
--
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 link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Static Library output problem
On 11/11/2011 03:42 PM, Romain LEGUAY wrote: > Ok thanks for your quick answers! It works perfectly now! > > Why don't we have just one variables for the library? > > With set_target_properties, we can define for each library the path. Because (1) ADD_LIBRARY() might lack the SHARED/STATIC keyword, and the user can decide which type of library is built via the BUILD_SHARED_LIBS variable, so an ADD_LIBRARY() command can be unalteredly used to build a shared library as well as a static one, and (2) on *nix, the outcome of ADD_LIBRARY(... SHARED ...) is a LIBRARY target whereas on Windows, the DLL part is a RUNTIME target, and the accompanying import library is an ARCHIVE target. For these reasons, the same ADD_LIBRARY() command - i.e., the same target - might generate different types of libraries, so there is a need to specify the respective *_OUTPUT_DIRECTORY individually. Regards, Michael > Le 11/11/2011 15:38, Andreas Pakulat a écrit : >> On 11.11.11 15:18:05, Romain LEGUAY wrote: >>> Hello everyone! >>> First, I need to thank you all the CMake developers for their >>> awesome work!!! >>> >>> I try to build a static and a shared libraries. I set the >>> LIBRARY_OUTPUT_DIRECTORY for each library target like this: >> See the documentation for the LIBRARY_OUTPUT_DIRECTORY, it only applies >> to shared libraries on non-dll platforms (*nix usually). For a static >> library you need to set ARCHIVE_OUTPUT_DIRECTORY. >> >> Andreas -- 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 link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Workflow of a collaborative project in Visual Studio+CMake
On Nov 12, 2011, at 11:08 AM, Bill Hoffman wrote: > On 11/12/2011 10:51 AM, John Drescher wrote: >>> It basically comes down to the inconvenience of having to do that with >>> Visual Studio being outweighed (considerably!) by the cross-platform >>> benefits of CMake. (It does help that none of our developers use Windows as >>> their primary development platform, so it only comes up when we make sure >>> things are working on Windows...) >>> >> >> I use Visual Studio 2010 daily for the last 6 months or so and the bug >> is not that difficult for me to work with at all. I do admit it is >> annoying when you get prompted 50 times to reload projects but most of >> the time it does not do that. I mean if you only add files to a single >> project it will not prompt you for the other 49. Now if I know the >> change will be big, I usually close the solution and run cmake >> externally from a script. >> > Does this solution work for VS 2010: > > There is an out of cmake solution for this. > > http://vscommands.com/ [^] > > If you install the VSCommands plugin free version, it will fix the reload > dialog to only ask once. > > -Bill > > -- So with CMake 2.8.6 and the vscommands installed with VS 2010 I will get ONLY a single dialog asking me to reload the VS solution file? If that is true I can handle that as an added requirement. Thanks Mike Jackson -- 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 link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Workflow of a collaborative project in Visual Studio+CMake
On Sat, Nov 12, 2011 at 11:08 AM, Bill Hoffman wrote: > On 11/12/2011 10:51 AM, John Drescher wrote: >>> >>> It basically comes down to the inconvenience of having to do that with >>> Visual Studio being outweighed (considerably!) by the cross-platform >>> benefits of CMake. (It does help that none of our developers use Windows >>> as >>> their primary development platform, so it only comes up when we make sure >>> things are working on Windows...) >>> >> >> I use Visual Studio 2010 daily for the last 6 months or so and the bug >> is not that difficult for me to work with at all. I do admit it is >> annoying when you get prompted 50 times to reload projects but most of >> the time it does not do that. I mean if you only add files to a single >> project it will not prompt you for the other 49. Now if I know the >> change will be big, I usually close the solution and run cmake >> externally from a script. >> > Does this solution work for VS 2010: > > There is an out of cmake solution for this. > > http://vscommands.com/ [^] > > If you install the VSCommands plugin free version, it will fix the reload > dialog to only ask once. > I have not tried that. I will do so and report back in around 2 weeks. I am leaving for a vacation at 4:00 AM tomorrow and I do not think I will have any time to test this.. John -- 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 link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Workflow of a collaborative project in Visual Studio+CMake
On 11/12/2011 10:51 AM, John Drescher wrote: It basically comes down to the inconvenience of having to do that with Visual Studio being outweighed (considerably!) by the cross-platform benefits of CMake. (It does help that none of our developers use Windows as their primary development platform, so it only comes up when we make sure things are working on Windows...) I use Visual Studio 2010 daily for the last 6 months or so and the bug is not that difficult for me to work with at all. I do admit it is annoying when you get prompted 50 times to reload projects but most of the time it does not do that. I mean if you only add files to a single project it will not prompt you for the other 49. Now if I know the change will be big, I usually close the solution and run cmake externally from a script. Does this solution work for VS 2010: There is an out of cmake solution for this. http://vscommands.com/ [^] If you install the VSCommands plugin free version, it will fix the reload dialog to only ask once. -Bill -- 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 link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Workflow of a collaborative project in Visual Studio+CMake
> It basically comes down to the inconvenience of having to do that with > Visual Studio being outweighed (considerably!) by the cross-platform > benefits of CMake. (It does help that none of our developers use Windows as > their primary development platform, so it only comes up when we make sure > things are working on Windows...) > I use Visual Studio 2010 daily for the last 6 months or so and the bug is not that difficult for me to work with at all. I do admit it is annoying when you get prompted 50 times to reload projects but most of the time it does not do that. I mean if you only add files to a single project it will not prompt you for the other 49. Now if I know the change will be big, I usually close the solution and run cmake externally from a script. John -- 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 link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Workflow of a collaborative project in Visual Studio+CMake
That's what we do to. It basically comes down to the inconvenience of having to do that with Visual Studio being outweighed (considerably!) by the cross-platform benefits of CMake. (It does help that none of our developers use Windows as their primary development platform, so it only comes up when we make sure things are working on Windows...) I really wish Microsoft would integrate support for CMake projects into Visual Studio the way KDevelop has, although I suppose that's right up there probability wise with hoping they'll integrate clang... Cheers, CY On Sat, Nov 12, 2011 at 7:39 AM, David Cole wrote: > For reference, the bug Mike refers to is this one: > > http://public.kitware.com/Bug/view.php?id=11258 > > I always use the manual technique of shutting down VS, running CMake, > and then re-opening VS. It's really not that bad, once you get used to > it. > > > David C. > > > On Fri, Nov 11, 2011 at 5:48 PM, Michael Jackson > wrote: > > It is worse and better. > > > > 1: CMake will generate the VS projects and solutions every time it needs > to run. DO NOT EDIT the generated VS projects and solutions. Add the > requirements to the CMake files. > > > > 2: If you are on VS2007/VS2008 and you do a "git pull" and then switch > to VS and click build a cmake check is run FIRST. If anything is different > the new solution and project files are generated and then the build > continues. You will get a dialog asking if you want to reload all of the > projects. Things are pretty nice. > > > > 3: If you are on VS2010 there is now a long standing bug that seems to > have no solution where you basically have to do the following: > > Close the VS solution > > git pull > > run cmake to regenerate the solution and projects > > Open the Solution and Compile. > > > > Yep. Sucks. Purchased VS2010 last year and have yet to use it because of > that bug. If we (the cmake community**) were to actually figure out how to > solve the problem then VS2010 would be as seamless as VS2008. Here is > hoping for the future. > > > > ** I have kept track of the bug. Kitware and others have put a lot of > time into trying to fix the bug. It just seams to be one of those elusive > fixes that there just may not be a solution to. > > -- > > Mike Jackson > > > > On Nov 11, 2011, at 5:30 PM, David Doria wrote: > > > >> I typically work in KDevelop which has CMake support, so if another > >> developer pushes some new files and changes to the CMakeLists.txt of > >> my project, I simply 'git pull' the project and then click "Build" and > >> it knows exactly what to do - it runs CMake and then builds the > >> project. > >> > >> However, when working with Visual Studio, do I have to 'git pull', > >> then go open cmake-gui from the VS2010E terminal, re-configure and > >> re-generate the project, then reimport the VS2010E project, then > >> build? This seems horribly awkward. And the reverse appears to have > >> the same problem - if working inside VS I add a file to the VS > >> project, how do I 'export' this addition back to the git repo? > >> > >> Thanks, > >> > >> David > >> -- > > > > -- > > > > 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 link to subscribe/unsubscribe: > > http://www.cmake.org/mailman/listinfo/cmake > > > -- > > 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 link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake > -- 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 link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Workflow of a collaborative project in Visual Studio+CMake
On 12 November 2011 12:39, David Cole wrote: > For reference, the bug Mike refers to is this one: > > http://public.kitware.com/Bug/view.php?id=11258 > > I always use the manual technique of shutting down VS, running CMake, > and then re-opening VS. It's really not that bad, once you get used to it. Actually, there is no need to completely shut down VS. File -> Close Solution or quick keyboard shortcut/accelerators use: Alt + F -> t then run cmake then File -> Recent Projects -> reopen yours or quick shortcut Alt + F -> j -> 1 Using keyboard makes this operation unnoticeable effort. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- 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 link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] /usr/bin/gcc -o tcl2c++ -rdynamic \n gcc: fatal error: no input files
I do an cmake program, but encount an stranger problem. 1. mkdir tmp; cd tmp 2. tar -zxvf ../cmake-test.tar.gz 3. mkdir build; cd build 4. cmake ..; make I got an error: /usr/bin/gcc-o tcl2c++ -rdynamic gcc: fatal error: no input files Then 1. cd .. 1. head -51 CMakeLists.txt >CMakeLists.txt.tmp 2. mv CMakeLists.txt.tmp CMakeLists.txt 3. cd build 4. rm -fr * 5. cmake ..; make It works now. Why? -- YunQiang Su cmake-test.tar.gz Description: GNU Zip compressed data -- 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 link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] QtCreator generator?
On Fri, Nov 11, 2011 at 6:05 PM, David Doria wrote: > On Fri, Nov 11, 2011 at 5:56 PM, John Drescher wrote: >>> There should have been a "*.sln" file that you open.? >>> >> >> Not for a "Code Blocks -NMake Makefile" project. >> >> John > > Ok, I guess I am getting my two threads confused. > > To use QtCreator > The consensus is to use the "Code Blocks - NMake Generator". This has > generated successfully a .cbp file (Code Block Project, I'm assuming). > However, QtCreator seems unaware that this is a project and just opens it as > plain text? How do I now open this project in QtCreator? > > To use Visual Studio 2010 Express > If the VS "PlatformSDK" that David Cole mentioned is installed properly, > does a "Visual Studio 2010 Express" generator appear in the list of > generators? If not, which one am I supposed to use? > > Thanks, > > David > > -- > > 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 link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake > There is no difference in the generator w.r.t. "Express" vs. non-"Express" -- just use "Visual Studio 10" -- 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 link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Workflow of a collaborative project in Visual Studio+CMake
For reference, the bug Mike refers to is this one: http://public.kitware.com/Bug/view.php?id=11258 I always use the manual technique of shutting down VS, running CMake, and then re-opening VS. It's really not that bad, once you get used to it. David C. On Fri, Nov 11, 2011 at 5:48 PM, Michael Jackson wrote: > It is worse and better. > > 1: CMake will generate the VS projects and solutions every time it needs to > run. DO NOT EDIT the generated VS projects and solutions. Add the > requirements to the CMake files. > > 2: If you are on VS2007/VS2008 and you do a "git pull" and then switch to VS > and click build a cmake check is run FIRST. If anything is different the new > solution and project files are generated and then the build continues. You > will get a dialog asking if you want to reload all of the projects. Things > are pretty nice. > > 3: If you are on VS2010 there is now a long standing bug that seems to have > no solution where you basically have to do the following: > Close the VS solution > git pull > run cmake to regenerate the solution and projects > Open the Solution and Compile. > > Yep. Sucks. Purchased VS2010 last year and have yet to use it because of that > bug. If we (the cmake community**) were to actually figure out how to solve > the problem then VS2010 would be as seamless as VS2008. Here is hoping for > the future. > > ** I have kept track of the bug. Kitware and others have put a lot of time > into trying to fix the bug. It just seams to be one of those elusive fixes > that there just may not be a solution to. > -- > Mike Jackson > > On Nov 11, 2011, at 5:30 PM, David Doria wrote: > >> I typically work in KDevelop which has CMake support, so if another >> developer pushes some new files and changes to the CMakeLists.txt of >> my project, I simply 'git pull' the project and then click "Build" and >> it knows exactly what to do - it runs CMake and then builds the >> project. >> >> However, when working with Visual Studio, do I have to 'git pull', >> then go open cmake-gui from the VS2010E terminal, re-configure and >> re-generate the project, then reimport the VS2010E project, then >> build? This seems horribly awkward. And the reverse appears to have >> the same problem - if working inside VS I add a file to the VS >> project, how do I 'export' this addition back to the git repo? >> >> Thanks, >> >> David >> -- > > -- > > 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 link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake > -- 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 link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Multiple source directory scenario and cdt generator
On Saturday 12 November 2011, Dan Kegel wrote: > In http://www.cmake.org/pipermail/cmake/2011-November/047250.html > I wrote > > "I can't reorganize the source tree on the developers, > so I'm making do by putting the enclosing CMakeLists.txt next to all > the projects: >toplevel/trunk/CMakeLists.txt > which is checked out to >toplevel/CMakeLists.txt > It does >add_subdirectory(../libfoo libfoo) >add_subdirectory(../libbar libbar) >add_subdirectory(../baz baz) > This has the possible advantage that one can have multiple > "top levels" (say, one for server code, and one for client). > I don't know how many shops suffer from this svn layout, but I'll probably > add an example covering it anyway for completeness once I'm sure > it doesn't explode in practice." > > Right, well, I found out where it explodes in practice. Here's an example: > http://code.google.com/p/winezeug/source/browse/trunk/cmake_examples/ex7/ > > The problem comes when using the cdt generator. We can't use > -DECLIPSE_CDT4_GENERATE_SOURCE_PROJECT=TRUE > since there are more than one source project, but the > source project that generates is really trivial, so I generate > one for each source directory myself with a bit of shell: > > for dir in demo libsrc > do > sed "s/PROJNAME/_$dir/" < ../skeleton.project > ../$dir/.project > done > > before or after running cmake. > > It all works great, the source projects all show up, the project builds... > BUT when you edit a source file and tell eclipse to rebuild, it just > sits there. It doesn't know that the source projects are related to > the build project. > > It looks like adding a link does the trick: > > --- .project.old 2011-11-11 22:51:56.797674441 + > +++ .project 2011-11-11 22:52:25.380913484 + > @@ -113,5 +113,11 @@ > 2 > > /home/dank/winezeug/cmake_examples/ex7/demo > > + > + [Source directory 2] > + 2 > + /home/dank/winezeug/cmake_examples/ex7/libsrc > + > + > > > > After I add those lines to the .project, saved changes in libsrc do seem > to cause a rebuild the next time you click "build project". > > So, I guess to support this style of project, the cdt generator > should call cmExtraEclipseCDT4Generator::AppendLinkedResource() > once for each call in my outer CMakeLists.txt like > add_subdirectory(../libsrc libsrc). Ok. So two things: * please give current cmake master a try, it has several improvements. * please create a ticket in the cmake bug tracker for this, improved source- project generator for Eclipse, or something like this. My goal is to have no open bugs for Eclipse when 2.8.7 wil be released. Alex -- 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 link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cdt generator and subclipse?
On Friday 11 November 2011, Dan Kegel wrote: > On Fri, Nov 11, 2011 at 9:42 PM, Alexander Neundorf > > wrote: > > So you imported the source project (and the build project), and now svn > > works for the source project ? > > Right (I think). The symptom was that the source project would not import. > Now it does, reliably. > > > Or does it also work in the build project, e.g. in the "[Source > > directory]" linked resource ? > > Nope, wasn't using the linked resource. > > I'm running into a new problem related to multiple source projects, though; > I'll post about that soon. > - Dan Btw. yesterday I closed the last open Eclipse-related bug in the cmake bug tracker, so 2.8.7 will be nice for Eclipse users :-) Alex -- 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 link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
