Re: [CMake] Problem using VS 2012 Express and CMake
Aaron Nowack aaronbnow...@gmail.com writes: Has anyone been able to get the newest cmake release (2.8.11.2) working with Visual Studio 2013 Express RC? Since yesterday, the newest cmake release is 2.8.12. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Setting compiler for cmake
outro pessoa outro.pes...@gmail.com
writes:
Did it require any extra options outside of: clang bin/, clang lib/ , and
the implicit link list when you started using clang-is-compiler?
It can be as easy as:
CC=clang CXX=clang cmake ...
or alternatively
cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ...
Use a full path to clang/clang++ if they are installed on custom
directories outside of PATH.
If you wish tho use libc++ or other goodies I suppose(*) that you can
add the options in your CMakeLists.txt:
if( ${CMAKE_CXX_COMPILER_ID} MATCHES Clang )
...
endif()
[*] I don't use those libraries, so never checked that the above works.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Setting compiler for cmake
[Please CC the cmake user's mailing list] outro pessoa outro.pes...@gmail.com writes: I'm looking at CMakeDetermineCompilerABI_C.bin and the path to /usr/local/lib/gcc46 is plain text in the elf file. Besides needing to eliminate some log files, is there a cmake argument that can be passed to clear all caches and keep the progress at the current point? Thanks muchly. Don't reuse a build directory when switching compilers. Start with an empty one. Are you experiencing difficulties with the instructions I gave you? You shouldn't care about the scripts that comes with CMake for building with Clang. The task does not require changes on those scripts. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Setting compiler for cmake
outro pessoa outro.pes...@gmail.com writes: The problem is this: I am trying to port traverso-daw to FreeBSD-10.x. I have to edit the CMake variables. Since the project is not mine, I need to work with a patched version. I have tried getting in contact with the original developer. Okay, do I need to clear out the CMakeTmp files? If you started with an empty build directory and set the compiler to clang, no, you don't need to clean anything. Why should you do? Is clang/clang++ the default compiler for FreeBSD-10? Maybe the cmake version you are using does not know about that fact and insists on using gcc/g++. If that's the problem, set CC and CXX environment variables (or CMAKE_C_COMPILER and CMAKE_CXX_COMPILER cmake variables ) as I explained on a previous message upon your *first* invocation of cmake on a clean build directory and it should just work. If it doesn't, please show the exact command you executed and its output. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Setting compiler for cmake
outro pessoa outro.pes...@gmail.com writes: If I edit the file to use clang as the compiler instead of gcc, will the version number be necessary or can I skip that? The libraries are for 3.2 and 3.3. Do you mean something like: cmake -DCAMKE_C_COMPILER=clang-3.3 . ? The version number there helps when you have more than one version of clang installed. Otherwise, you can omit it. BTW, please send this type of questions only to the user's list. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Setting compiler for cmake
outro pessoa outro.pes...@gmail.com writes: No. In the $PROJECT/CMakeFiles/2. 8.10.2 CMakeCCompiler.cmake 2 KB 10/01/13 03:42:34 [image: File:] CMakeCXXCompiler.cmake 2 KB 10/01/13 03:42:35 [image: File:] CMakeDetermineCompilerABI_C.bin 6 KB 10/01/13 03:42:34 [image: File:] CMakeDetermineCompilerABI_CXX.bin 6 KB 10/01/13 03:42:35 [image: File:] CMakeSystem.cmake 1 KB 10/01/13 03:42:31 CompilerIdC 10/01/13 03:42:32 CompilerIdCXX Sooner than later, we will need to see what and what does not build with clang. I have 2 version numbers: 3.2 3.3 Sorry, but stil is not clear to me what you are asking. If you mean if CMake works with Clang as the C and C++ compiler, yes it does. I'm using it for C++ projects since a few years ago (at least Jan 2011) so there should be no problem with Clang 3.2. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake Code Beautifier
Alan W. Irwin ir...@beluga.phys.uvic.ca writes: I use the emacs mode to reformat CMake code. I use that as well, but the problem is that appears to be the only choice and some developers (although very few, of course :-) ) don't use emacs. You can write a script a script that invokes Emacs in batch mode. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Ninja and *.i targets
Bill Hoffman bill.hoff...@kitware.com writes: On 1/5/2013 3:49 PM, Óscar Fuentes wrote: With the `Unix Makefiles' generator, a foo.i target is generated for foo.cpp. That's very convenient. However, ninja doesn't list such targets under `ninja help' and `ninja foo.i' complains about unknown target. This is a missing feature. Can you create a feature request for it in the bug tracker? Done: http://public.kitware.com/Bug/view.php?id=13838 Thanks. -- 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] Ninja and *.i targets
Stephen Kelly steve...@gmail.com writes: While at it, you comb this thread to see if there are other feature requests there which are not in the bug tracker: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3471/focus=3475 Good idea. Apart from the .i targets, the only non-controversial unimplemented feature I see is the generation of .s targets. Created a feature request here: http://public.kitware.com/Bug/view.php?id=13839 -- 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] Ninja and *.i targets
With the `Unix Makefiles' generator, a foo.i target is generated for foo.cpp. That's very convenient. However, ninja doesn't list such targets under `ninja help' and `ninja foo.i' complains about unknown target. Is this feature missing from the ninja generator? Is it because is hard to implement or just lack of time? I'm using cmake 2.8.9 and ninja 1.0.0 on Linux. -- 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-developers] lua bindings?
Brad King brad.k...@kitware.com writes: [snip] As for your first option, a zero-impact wrapper, what do you envision would be the benefits? [I'm not the OP] Something I sorely miss on CMake is a way to express algorithms in a clear way and to process large amounts of data efficiently. For an example that could benefit from a cleaner and more expressive language, see function explicit_map_components_to_libraries in http://www.llvm.org/viewvc/llvm-project/llvm/trunk/cmake/modules/LLVM-Config.cmake?revision=145355view=markup On the same project, there was several perl scripts that I'll like to implement on CMake (and hence drop the Perl requirement.) Those scripts walked through all defined and referenced symbols on all libraries on the project for creating library dependencies. On another instance, a similar taks would be performed on Visual C++ for creating .def files and dll's. On both cases I stumbled on the language's lack of expresiveness, minimal support for data structures and on an apparent O(n^2) time complexity on some list operations (including the append operation, IIRC) -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake, Xcode 4.4, and Mountain Lion
Brad King brad.k...@kitware.com writes: On 07/31/2012 03:43 PM, Brad King wrote: Thanks for pointing us to that. I just merged a fix to next: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=27b74445 Well, that caused major test failures on almost every OS X build during nightly testing. I had to revert it: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ea56c232 See revert commit message for an explanation. I'll think about other solutions. For C++ projects, this heuristics may work: - Find the C++ compiler. - Unless the user asked for a specific C compiler, chose it depending on the C++ compiler found (c++ for cc, g++ for gcc, clang for clang++, etc) Also, I'll propose that if CMake fails to find a matching C compiler on the second step above, the process shall error out. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake, Xcode 4.4, and Mountain Lion
Ho Cheung hocheun...@gmail.com writes: [snip] Since Xcode uses clang but CMAKE_C_COMPILER is set to gcc, the gcc compiler flags are being passed to clang. Something related to this issue is being commented on the LLVM ml rigth now: while searching for compilers, CMake prefers gcc over cc and that is causing trouble: http://comments.gmane.org/gmane.comp.compilers.llvm.devel/52263 -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[CMake] Choosing the right compiler
On a machine with both MinGW and VS installed, some generators (Ninja, for instance) will use MinGW by default. The only way I know of instructing cmake to use VS instead is cmake -G Ninja -DCMAKE_CXX_COMPILER=cl -DCMAKE_C_COMPILER=cl ... This is quite verbose and triggers some bugs. Is there a cleaner way to tell cmake to use VS instead of MinGW with a given generator? -- 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-developers] -GNinja on Windows
Peter Kümmel syntheti...@gmx.net writes: ninja -d explain shows the files which are dirty, and having a look at the .d files shows that ninja couldn't parse them. (\\../) I've switched to slashes in .d files and this fixes it. All in stage/next, or https://sourceforge.net/projects/cmakescript/files/ ninja/master is ok when don't have spaces in your paths, otherwise ninja must be patched. After updating to the latest binaries everything seems ok. Thanks! On Linux, cmake+gmake is fast enough even for middle-sized projects like LLVM+Clang, but on Windows with Visual Studio, the available options such as msbuild, devenv, nmake and jom are annoyingly slow and inefficient while ninja is extremely fast, so I'm very happy to see this project maturing. Thanks again. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
Peter Kümmel syntheti...@gmx.net writes: Does clang has another build system which supports ninja? Then we could compare the generated files. No, AFAIK. What does work is all other build tools supported by cmake (VS project files, nmake/jom). The command looks good. It is a custom command that runs a tool previously generated by the build (llvm-tblgen.exe). After looking that the ouptput of ninja -v, the problem is that ninja is recompiling some of the source files of llvm-tblgen.exe, which regenerates the llvm-tblgen.exe executable, which in turn triggers the regeneration of the files produced using that tool. Here, the first chunk of output of ninja -v, whith comments: # Ninja starts recompiling some of the source files of llvm-tblgen.exe. This is wrong, because everything is up to date: [1/71] C:/apps/CMake2.8ninja/bin/cmcldeps.exe D:\dev\llvm\llvm\utils\TableGen\ DisassemblerEmitter.cpp utils\TableGen\CMakeFiles\llvm-tblgen.dir\DisassemblerEm itter.cpp.obj.d utils\TableGen\CMakeFiles\llvm-tblgen.dir\DisassemblerEmitter.cp p.obj Note: including file: C:\ARCHIV~1\MICROS~2.0\VC\bin\cl.exe /nologo /D WIN32 /D_WINDOWS /W3 /Zm1000 /EHsc /GR /MD /O2 /Ob2 /D NDEBUG -Iutils\TableGen - ID:\dev\llvm\llvm\utils\TableGen -Iinclude -ID:\dev\llvm\llvm\include-wd4146 -wd4180 -wd4224 -wd4244 -wd4267 -wd4275 -wd4291 -wd4345 -wd4351 -wd4355 -wd4503 -wd4551 -wd4624 -wd4715 -wd4800 -wd4065 -wd4181 -w14062 -D_CRT_SECURE_NO_DEPRE CATE -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WAR NINGS -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D__STDC_CONSTANT_MAC ROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS /TP /Foutils\TableGen\CMakeFile s\llvm-tblgen.dir\DisassemblerEmitter.cpp.obj /Fdbin\llvm-tblgen.pdb -c D:\dev\l lvm\llvm\utils\TableGen\DisassemblerEmitter.cpp [2/71] C:/apps/CMake2.8ninja/bin/cmcldeps.exe D:\dev\llvm\llvm\utils\TableGen\ X86DisassemblerTables.cpp utils\TableGen\CMakeFiles\llvm-tblgen.dir\X86Disassemb lerTables.cpp.obj.d utils\TableGen\CMakeFiles\llvm-tblgen.dir\X86DisassemblerTab les.cpp.obj Note: including file: C:\ARCHIV~1\MICROS~2.0\VC\bin\cl.exe /nol ogo /DWIN32 /D_WINDOWS /W3 /Zm1000 /EHsc /GR /MD /O2 /Ob2 /D NDEBUG -Iutils\Tabl eGen -ID:\dev\llvm\llvm\utils\TableGen -Iinclude -ID:\dev\llvm\llvm\include- wd4146 -wd4180 -wd4224 -wd4244 -wd4267 -wd4275 -wd4291 -wd4345 -wd4351 -wd4355 - wd4503 -wd4551 -wd4624 -wd4715 -wd4800 -wd4065 -wd4181 -w14062 -D_CRT_SECURE_NO _DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_ NO_WARNINGS -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D__STDC_CONSTA NT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS /TP /Foutils\TableGen\CMa keFiles\llvm-tblgen.dir\X86DisassemblerTables.cpp.obj /Fdbin\llvm-tblgen.pdb -c D:\dev\llvm\llvm\utils\TableGen\X86DisassemblerTables.cpp [3/71] C:/apps/CMake2.8ninja/bin/cmcldeps.exe D:\dev\llvm\llvm\utils\TableGen\ X86RecognizableInstr.cpp utils\TableGen\CMakeFiles\llvm-tblgen.dir\X86Recognizab leInstr.cpp.obj.d utils\TableGen\CMakeFiles\llvm-tblgen.dir\X86RecognizableInstr .cpp.obj Note: including file: C:\ARCHIV~1\MICROS~2.0\VC\bin\cl.exe /nologo /DWIN32 /D_WINDOWS /W3 /Zm1000 /EHsc /GR /MD /O2 /Ob2 /D NDEBUG -Iutils\TableGe n -ID:\dev\llvm\llvm\utils\TableGen -Iinclude -ID:\dev\llvm\llvm\include-wd4 146 -wd4180 -wd4224 -wd4244 -wd4267 -wd4275 -wd4291 -wd4345 -wd4351 -wd4355 -wd4 503 -wd4551 -wd4624 -wd4715 -wd4800 -wd4065 -wd4181 -w14062 -D_CRT_SECURE_NO_DE PRECATE -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_ WARNINGS -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D__STDC_CONSTANT_ MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS /TP /Foutils\TableGen\CMakeF iles\llvm-tblgen.dir\X86RecognizableInstr.cpp.obj /Fdbin\llvm-tblgen.pdb -c D:\d ev\llvm\llvm\utils\TableGen\X86RecognizableInstr.cpp # Now invokes the linker for producing llvm-tblgen.exe : [4/71] cmd.exe /c cd. c:\apps\CMake2.8ninja\bin\cmake.exe -E vs_link_exe C:\A RCHIV~1\MICROS~2.0\VC\bin\cl.exe /nologo utils\TableGen\CMakeFiles\llvm-tblgen. dir\AsmMatcherEmitter.cpp.obj utils\TableGen\CMakeFiles\llvm-tblgen.dir\AsmWrite rEmitter.cpp.obj utils\TableGen\CMakeFiles\llvm-tblgen.dir\AsmWriterInst.cpp.obj utils\TableGen\CMakeFiles\llvm-tblgen.dir\CallingConvEmitter.cpp.obj utils\Tabl eGen\CMakeFiles\llvm-tblgen.dir\CodeEmitterGen.cpp.obj utils\TableGen\CMakeFiles \llvm-tblgen.dir\CodeGenDAGPatterns.cpp.obj utils\TableGen\CMakeFiles\llvm-tblge n.dir\CodeGenInstruction.cpp.obj utils\TableGen\CMakeFiles\llvm-tblgen.dir\CodeG enRegisters.cpp.obj utils\TableGen\CMakeFiles\llvm-tblgen.dir\CodeGenTarget.cpp. obj utils\TableGen\CMakeFiles\llvm-tblgen.dir\DAGISelEmitter.cpp.obj utils\Table Gen\CMakeFiles\llvm-tblgen.dir\DAGISelMatcherEmitter.cpp.obj utils\TableGen\CMak eFiles\llvm-tblgen.dir\DAGISelMatcherGen.cpp.obj utils\TableGen\CMakeFiles\llvm- tblgen.dir\DAGISelMatcherOpt.cpp.obj utils\TableGen\CMakeFiles\llvm-tblgen.dir\D
Re: [cmake-developers] visual studio usage
J Decker d3c...@gmail.com writes: I mean using cmake --build . and/or getting BUILD_COMMAND from cmake which comes back as devenv which is then used to build projects. I had a bunch of cmake projects that built from a batch file, then I made a cmakelists that does the same thing, so I have one cmakelists.txt which builds all other top level cmakelists. cmake -DCMAKE_MAKE_PROGRAM=msbuild . ? -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] -GNinja on Windows
Peter Kümmel syntheti...@gmx.net writes: It is not getting that far. It is not even running cmcldeps. :) The command= line is bad, so nothing builds, and we get no .d files. I added parentheses around cmcldeps, it should work now. With your binaries from 2 hours ago, changes on header files are correctly detected on my C++ projects. Thanks! LLVM builds fine, although re-running ninja results on re-executing all tablegen commands. Even with all those 70 or so tablegen invocations, ninja does a no-op rebuild in 16 seconds, which is faster than a true no-op rebuild with jom and much faster than msbuild. Windows XP SP3 32 bits, Visual Studio 2010. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] ninja status
Peter Kümmel syntheti...@gmx.net writes:
I know ninja should not be enabled on other platforms than Linux, and it
wasn't,
even with my patch. This was not a try the enable ninja through the backdoor!
I've fixed it and changed the message so it could not happen again:
http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=2a081a2b3a3064530fe173a2930828e2232e844b
There is a typo on the patch:
SET(CMAKE_ENABLE_NINJA ${_CMAKE_DEFAULT_NINJA_VALUE} CACHE BOOL
-Enable the ninja generator for CMake. On Windows and OSX broken FORCE)
+Enable the ninja generator for CMake. On Windows and OSX broken)
[...]
ELSE()
- MESSAGE(STATUS Ninja generator disabled, enforce with -DENABLE_NINJA=ON)
+ MESSAGE(STATUS Ninja generator disabled, enforce with -DCMAKE_USE_NINJA=ON)
You mention CMAKE_USE_NINJA on the last message, when it should be
CMAKE_ENABLE_NINJA.
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Ninja/VS: fixed PDB name
The compile and link commands executed by ninja contains the same option: /FdTARGET_PDB (TARGET_PDB here is literal text, not a placeholder.) This is a simplified excerpt from a .ninja.log file: 596911219 0 driver\CMakeFiles\foo.dir\foo.cpp.obj C:/Archivos de programa/Microsoft Visual Studio 10.0/VC/bin/cl.exe /nologo /DWIN32 /D_WINDOWS /W3 /Zm1000 /EHsc /GR /MD /O2 /Ob2 /D NDEBUG /TP /Fodriver\CMakeFiles\foo.dir\foo.cpp.obj /FdTARGET_PDB -c ..\..\..\..\driver\foo.cpp 11219 11922 0 foo.exe cmd.exe /c cd . c:/apps/cmake/bin/cmake.exe -E vs_link_exe C:/Archivos de programa/Microsoft Visual Studio 10.0/VC/bin/cl.exe /nologo driver\CMakeFiles\foo.dir\foo.cpp.obj /Fefoo.exe /FdTARGET_PDB -link /version:0.0 /STACK:1000 /machine:X86 /INCREMENTAL:NO /subsystem:windows cd . Please note how the compile command also has /FdTARGET_PDB, which makes no sense. For executables, using the same /FdTARGET_PDB causes build failures when two or more executables are linked at the same time and the linker tries to create and lock the file TARGET_PDB for each of those executables. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Some numbers on cmake+ninja+VS on Windows
Setup: Windows XP SP3 32 bits running on VMWare Workstation 8.0.1 with 4
real cores (no HT) assigned out of 4 available on the host machine,
which is Kubuntu 11.08 64 bits (kernel version 3.0.0-16-generic).
Visual Studio 2010 Ultimate. JOM 0.9.4 (that's an old version, but on my
experience newer versions are slower).
CMake was taken from https://github.com/syntheticpp/CMake.git, branch
ninja-generator-pr-win revision fa9ce5e, plus this patch:
diff --git a/Modules/Platform/Windows-cl.cmake
b/Modules/Platform/Windows-cl.cmake
index bc9..be6abb6 100644
--- a/Modules/Platform/Windows-cl.cmake
+++ b/Modules/Platform/Windows-cl.cmake
@@ -37,7 +37,7 @@ SET(CMAKE_COMPILE_RESOURCE rc FLAGS /foOBJECT SOURCE)
# that is automatically copied into try_compile directories
# by the global generator.
SET(MSVC_IDE 1)
-IF(CMAKE_GENERATOR MATCHES Makefiles)
+IF(CMAKE_GENERATOR MATCHES Makefiles OR CMAKE_GENERATOR MATCHES Ninja)
SET(MSVC_IDE 0)
IF(NOT CMAKE_VC_COMPILER_TESTS_RUN)
SET(CMAKE_VC_COMPILER_TESTS 1)
@@ -125,7 +125,7 @@ IF(CMAKE_GENERATOR MATCHES Makefiles)
ENDIF(CMAKE_COMPILER_RETURN)
MAKE_DIRECTORY(${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp3)
ENDIF(NOT CMAKE_VC_COMPILER_TESTS_RUN)
-ENDIF(CMAKE_GENERATOR MATCHES Makefiles)
+ENDIF(CMAKE_GENERATOR MATCHES Makefiles OR CMAKE_GENERATOR MATCHES Ninja)
IF(MSVC_C_ARCHITECTURE_ID MATCHES 64)
SET(CMAKE_CL_64 1)
diff --git a/Source/cmNinjaTargetGenerator.cxx
b/Source/cmNinjaTargetGenerator.cxx
index e48ac12..034aefe 100644
--- a/Source/cmNinjaTargetGenerator.cxx
+++ b/Source/cmNinjaTargetGenerator.cxx
@@ -230,9 +230,13 @@ cmNinjaDeps cmNinjaTargetGenerator::ComputeLinkDeps() const
if(!cli)
return cmNinjaDeps();
- const std::vectorstd::string deps = cli-GetDepends();
- cmNinjaDeps result(deps.size());
- std::transform(deps.begin(), deps.end(), result.begin(), MapToNinjaPath());
+ cmNinjaDeps result;
+ for(unsigned i = 0; i cli-GetItems().size(); ++i) {
+if( cli-GetItems()[i].Target ) {
+ result.push_back( cli-GetItems()[i].Target-GetName() );
+}
+ }
+
return result;
}
Ninja was taken from https://github.com/syntheticpp/ninja.git, branch
token-splitter revision 335e08e.
I worked with some internal projects and with LLVM revision f340a29
taken from LLVM's official git mirror: http://llvm.org/git/llvm.git
First, some quick recap of the build tool I used so far with VS:
NMake: no support for parallel jobs.
MSBuild (equivalent to VS IDE): platform checks very slow, tricky
support for parallel jobs (one knob /m:JOBS at MSBuild.exe level and
another indepent one /MP at the compiler driver level; it's easy to end
with starved cores or with dozens of compile jobs competing for the
available cores.) On addition, CMake+MSBuild suffers from a nasty bug
that consists on not being able to use the regenerated project files
when CMake is invoked from within the build because some CMakeLists.txt
changed. There more issues with MSBuild when it is used as a
replacement of `make' but those described so far are enough to motivate
anyone to search for a better alternative.
Jom: no support for building more than one top-level target in
parallel. This was reported to the author time ago as a feature request
and was closed as wontfix.
Now, for the numbers.
Build LLVM with -DCMAKE_BUILD_TYPE=Release:
ninja -j 4: 6m55s
MSBuild (cmake --build .): 38m17s (*)
jom: 10m45s
(*): this very long time may be due to the lack of top-level
parallelization (no /m:JOBS was used for invoking msbuild.exe) and/or a
slower console when executing on VMWare for showing all the text output
that msbuild emits.
No-op build (best of two consecutive runs):
ninja -j 4: 0.4s
MSBuild: 11s
jom: 53s
`ninja -t clean' takes less than a second.
On an internal project here, a full build with ninja requires half the
time of jom/msbuild (35s vs 1m20s) while a no-op build is instantaneous
with ninja (0.1s) while reasonably fast with msbuild (2.3s) and
annoyingly slow with jom (8.5s). That project consists on a shared
library with ~30 cpp files plus 10 small (typically 1 cpp file) shared
libraries or executables that depends on the big shared library. On this
scenario, Ninja's correct handling of parallel jobs makes a lot of a
difference over jom and msbuild.
CMake + Ninja looks like a perfect match for people building with VC++
outside of the IDE.
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] CMake + Ninja
Clifford Yapp cliffy...@gmail.com writes: On Sat, Jan 14, 2012 at 3:25 PM, Peter Collingbourne pe...@pcc.me.uk wrote: I managed to test these changes on a Mac and it fixed all but 7 test failures, so I rolled it into the ninja-generator-pr branch. In terms of applications I didn't have time to try building anything other than CMake itself and LLVM/Clang (both successfully), but please let me know if there are any other problems with BRL-CAD. Confirmed - working now on Mac building BRL-CAD - thanks! Does anyone know what changes are required to make the Ninja generator work on Windows? I know nothing about the CMake C++ base nor I see anything obvious on the source code of the Ninja generator but, maybe, with a starting point, something could be done with some hours I can devote to that task. I mailed Peter Collingbourne some weeks ago but received no response. -- 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] MSBuild and automatic project file regenation
Michael Hertling mhertl...@online.de writes: But aren't the issues related at least? Dunno. If I understand correctly, cmake --build invokes MSBuild which - loads the solution file and the project files, - reinvokes CMake via the ZERO_CHECK project/target to regenerate them if CMakeLists.txt has been modified, - does *not* use the regenerated ones for building, so the affected projects/targets are left inherently out-of-date. Yep. Moreover, even an additional subsequent cmake --build command doesn't rebuild; in fact, it does nothing, as though there is no dependency of a project/target on its own project file. That doesn't happen here. The next cmake --build works fine (cmake 2.8.4, VS 10) AFAICS for now, it's solely David's hint, i.e. cmake . cmake --build ., that results in the project being actually rebuilt after CMakeLists.txt has changed, unless one uses the --clean-first option. If so, I would strongly support a feature request in this respect since, IMO, it's actually quite confusing that CMake's --build command does anything but rebuilding. I agree. Do you file a feature request / bug report? Nope. Personally, I'd like to be sure that after a cmake --build command, everything is up-to-date as it is with Makefiles, provided it can be realized with MSBuild at all. Obviously, how MSBuild works when the project files are regenerated on the fly is a bug. I have no idea about how hard is to fix it, though. Try http://www.cmake.org/pipermail/cmake/2011-November/047802.html. Hmmm... After reading your example, I can't say for sure that when `cmake --build' worked the second time here it didn't cointain changes on the source files too. CMake with VS 10 and/or MSBuild is pesky, apart from the problems MSBuild has on its own. I'm looking at using other generators that support parallel builds. JOM is not truly parallel (it only builds a toplevel target at once). Ninja looks like the right thing, but doesn't work on MS Windows. -- 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] MSBuild and automatic project file regenation
Michael Hertling mhertl...@online.de writes: On 01/09/2012 02:34 PM, David Cole wrote: No trick, but to avoid this, perhaps we should change the --build handler to run the cmake configure generate step before calling out to MSBuild. You can easily do this yourself from the command line by adopting the pattern: cmake . cmake --build . --config Release Fortunately my cmake scripts are simple enough so the extra invocation does not add much to the build. Thanks David. This is a good idea for a feature request. Not sure if we should just always do that by default and provide a way to turn off with a --no-regenerate, or vice-versa with a --please-generate-first ... :-) The effect of --no-regenerate would be the same as the current buggy behavior (MSBuild.exe uses outdated project files). IMHO the --please-generate-first is the right thing. Just out of curiosity: In [1], item (1), I reported on the fact that one can modify a project's CMakeLists.txt, and cmake --build will reconfigure/regenerate, but not rebuild. Is this the same issue the OP asks about? No. If so, I would strongly support a feature request in this respect since, IMO, it's actually quite confusing that CMake's --build command does anything but rebuilding. I agree. [1] http://www.mail-archive.com/cmake@cmake.org/msg39596.html This returns 404. -- 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] MSBuild and automatic project file regenation
When MSBuild.exe is used (typically by cmake --build) for building a VS2010 project generated by cmake, it correctly invokes cmake for regenerating the project files if changes to the CMakeLists.txt files are detected. However, the build does not restart nor abort, so MSBuild continues using the outdated project files that it previously read, ending some time later with lots of error messages from the compiler or linker, hence wasting time, causing confusion and making difficult to notice that a regeneration had happened. Is there any trick for stopping MSBuild as soon as cmake ends regenerating the project files? -- 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] License of Wiki code snippets is not Debian-compatible
The Creative Commons BY 2.5 license used on the Wiki is not compatible with Debian. LLVM contains a macro taken from it and the Debian guys filed a bug report: http://llvm.org/bugs/show_bug.cgi?id=9739 They suggest upgrading to 3.0. CC also suggests using 3.0 instead of 2.5, see the bottom of http://creativecommons.org/licenses/by/2.5/ Is it possible to upgrade the Wiki license to 3.0? ___ 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] DLL and EXE with same base name: clash in VS.
Michael Wild them...@gmail.com writes: On 04/06/2011 09:21 AM, Alexey Livshits wrote: We have a clang.exe and a clang.dll. While building, VS creates clang.pdb (for the executable) and clang.pdb (for the dll) which obviously is not right. Is there a way to tell VS to use a different name for the PDB? You can use different project name for exe and set the output name via OUTPUT_NAME property. CMake uses prefix+base+.pdb to generate the PDB file name, however I didn't dig deep enough to find out what `base' is, just that it is obtained with cmTarget::GetName(). Whether that refers to the target name or the OUTPUT_NAME, I couldn't find out easily, so you'll have to experiment ;-) It is OUTPUT_NAME. The target name for clang.dll is libclang and the build creates clang.pdb (and clang.ilk ...) If I understand correctly what Michael says, the .pdb file name is hardcoded. ___ 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] Platform tests counts as errors.
Consider this custom_command:
add_custom_command(OUTPUT ${CX_NATIVE_TG_DIR}/CMakeCache.txt
COMMAND ${CMAKE_COMMAND} -DCMAKE_BUILD_TYPE=Release ${FOO_SOURCE_DIR}
WORKING_DIRECTORY ${CX_NATIVE_TG_DIR})
When it is executed from a Makefile-based generator, no
problem. However, when it is executed from the VS 2008 IDE, failed
platform tests are signaled as errors:
2-- Looking for sys/dir.h
2CheckIncludeFile.c
2CheckIncludeFile.c(1) : fatal error C1083: Cannot open include file:
'sys/dir.h': No such file or directory
2-- Looking for sys/dir.h - not found
At the end, the custom_command is signaled as failed by the IDE because
of those errors.
First of all, why
2CheckIncludeFile.c
2CheckIncludeFile.c(1) : fatal error C1083: Cannot open include file:
'sys/dir.h': No such file or directory
is shown in the middle of the usual
2-- Looking for sys/dir.h
2-- Looking for sys/dir.h - not found
?
Second, what can I do so the IDE does not interpret failed platform
tests as errors?
___
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] No LANG_FLAGS_CONFIG target property.
Hendrik Sattler p...@hendrik-sattler.de writes: Zitat von Óscar Fuentes o...@wanadoo.es: There are target properties such as LINK_FLAGS and LINK_FLAGS_CONFIG, but I don't see properties for setting compiler flags. This makes impossible to build two targets on the same CMakeLists.txt with different compiler flags (I was told that the last value of CMAKE_LANG_FLAGS_CONFIG applies to all targets on that CMakeLists.txt). So why no per-target compile flags? RTFM? The following line is directly derived from the words in your question: set_target_properties(myTarget PROPERTIES COMPILE_FLAGS -foo -bar) Or maybe your question was wrong? The COMPILE_FLAGS property sets additional compiler flags used to build sources within the target. So it *adds* flags. I want to *set* flags, i.e. replace the existing ones. ___ 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] No LANG_FLAGS_CONFIG target property.
Michael Wild them...@gmail.com writes: On 03/14/2011 12:42 AM, Óscar Fuentes wrote: There are target properties such as LINK_FLAGS and LINK_FLAGS_CONFIG, but I don't see properties for setting compiler flags. This makes impossible to build two targets on the same CMakeLists.txt with different compiler flags (I was told that the last value of CMAKE_LANG_FLAGS_CONFIG applies to all targets on that CMakeLists.txt). So why no per-target compile flags? You could misuse COMPILE_DEFINITIONS and COMPILE_DEFINITIONS_CONFIG for that... I think that that is the same case as COMPILE_FLAGS property: it just adds its contents to whatever CMAKE_*_FLAGS* has. I'm afraid of compiler errors warnings of the sort of option -foo is incompatible with option -bar So as it seems that there is no way of replacing the compiler flags at the target level, is it an omission worth a bug report or is it something that was decided? ___ 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] No LANG_FLAGS_CONFIG target property.
Hendrik Sattler p...@hendrik-sattler.de writes: The COMPILE_FLAGS property sets additional compiler flags used to build sources within the target. So it *adds* flags. I want to *set* flags, i.e. replace the existing ones. So you add global compiler flags which are not meant to be global? A usual person would say: then do not set them globally!. It's really that simple... No, I want to replace those automatically setted by 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] No LANG_FLAGS_CONFIG target property.
Michael Hertling mhertl...@online.de writes: So you add global compiler flags which are not meant to be global? A usual person would say: then do not set them globally!. It's really that simple... No, I want to replace those automatically setted by CMake. AFAIK, CMake doesn't set compilation flags by itself, perhaps unless a specific toolchain/platform file enforces this. Rather, the flags are roughly set up as follows - for C compilations: 1) CMAKE_C_FLAGS for all configurations; explicitly set or initialized by the CFLAGS environment variable when CMake is run initially. 2) Addition of CMAKE_C_FLAGS_CONFIG for the configuration. 3) Addition of COMPILE_FLAGS source/target properties. If you set neither CFLAGS/CMAKE_C_FLAGS nor CMAKE_C_FLAGS_CONFIG nor COMPILE_FLAGS, your source files should be compiled without any flags, Say CMake, say a toolchain/platform file, once a project is started it comes with the standard flags for compiling in the chosen mode (debug, release, ...) and, IIRC, in some cases some other flags which are deemed as good to have are added too. so the art is to specify the latters such that each source file will be compiled with the correct/desired set of them. However, you're right insofar that there's no possibility to specify flags which will be used solely for a certain target *and* a certain configuration, but in my experience, this is almost never necessary. Do you have a special problem in this regard, i.e. a flag that must be activated for one target in one configuration only? Generally speaking, I had a case for building the same sources with different flags. One project I maintain (LLVM) compiles an utility that is used to generate files later in the same build. The problem is VC++ in Debug configurations: the debug VC++ runtime makes the utility to perform excruciatingly slow. Someone was annoyed enough by that to create a patch that builds the utility and one library it uses in optimized mode when the user activates an option. The ugly part of the patch was a trick for building the library used by the utility twice: one with the usual Debug configuration (required because that library is used by everything else on the project) and another with optimization flags. He resorted to creating an extra directory for building the optimized version, because CMAKE_C*_FLAGS* affects all targets defined on the same CMakeLists.txt file. Fortunately our problem can be easily solved on a totally different way, but I was surprised by the lack of target properties for setting the compiler flags. [snip] Finally, if you really need to drop a flag from a compilation command and can't avoid its addition by other means, you could use one of the RULE_LAUNCH_COMPILE properties to intercept the compiler command and adjust the command line to whatever is necessary [2]. Regrettably, this is restricted to the Makefile generators. IDE support is required. Whenever I see a feature restricted to Makefile generators, I know it is not useful to me. I wish the docs showed this restriction at the top of the description of the feature :-/ Alternatively, you might modify the CMAKE_C_COMPILE_OBJECT rule variable within the affected directories, especially w.r.t. the FLAGS placeholder, see [3]. I cannot access the link because gmane mangled it, but I guess that CMAKE_C_COMPILE_OBJECT has the same restriction as CMAKE_C_FLAGS (it acts with the same value over all targets defined on the same CMakeLists.txt). [snip] ___ 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] No LANG_FLAGS_CONFIG target property.
There are target properties such as LINK_FLAGS and LINK_FLAGS_CONFIG, but I don't see properties for setting compiler flags. This makes impossible to build two targets on the same CMakeLists.txt with different compiler flags (I was told that the last value of CMAKE_LANG_FLAGS_CONFIG applies to all targets on that CMakeLists.txt). So why no per-target compile flags? ___ 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] CMake performs search for includes/libs in non-default compiler search paths.
Michael Wild them...@gmail.com writes:
The point I (and Andreas) wanted to make is that you can just add it. If
it's a system directory, CMake is going to filter it out (I didn't say
duplicates, I said doesn't even show up ONCE, which means *zero* times).
This is a moot point, because /usr/local/include and several other paths
which are searched by default by cmake are not system directories in
FreeBSD.
No it's not. If you have e.g. /usr/local/include/foo.h and you do
find_path(FOO_INCLUDE_DIR foo.h)
if(FOO_INCLUDE_DIR)
include_directories(${FOO_INCLUDE_DIR})
endif()
you don't have to care, because -I/usr/local/include will show up on the
command line. If foo.h happened to be in /usr/include, things would be
(kind of) fine again, because CMake filters that one out and thus
doesn't clutter your command line.
I said that it is a moot because what you describe is, precisely, what I
was describing as problematic: the code above injects /usr/local/include
on the preprocessor search list, after that another find_path (with a
hard-coded path selected by the user) returns /home/joe/include and that
is appended to the preprocessor search list. But if the user required a
custom directory for the headers found with the second find_path
possible is because he wants to override those installed on a
system-wide directory such as /usr/local/include. If the user doesn't
check the commands executed by `make', he will not notice that the build
is using the headers stored in /usr/local/include.
After all, you do use CMake because it's smarter than your compiler.
Otherwise you could just use some dump shell script.
CMake and the compiler do very different tasks, their smartness can't be
compared.
the find_* commands and the FindXXX modules in general works hard for
finding things. I guess that if it where practical, they would be
programmed for performing a complete filesystem scan. The fact that
Unixes have a series of catch-all directories for headers and libraries
and that cmake is used by people who don't know (nor care) about how it
does its stuff and assume that it is a smart tool that does the Right
Thing, is something that makes me think that that sort of nasty problems
will happen from time to time. Unfortunately, what the Right Thing is
can't be easily decided. I'm inclined to making everything explicit and
not trying to be smart when that can cause subtle problems, but that's
just me. I understand that others may prefer everyday convenience.
And yes, CMake simplifies A B C A to A B C, which is perfectly fine
because the trailing A doesn't have any effect whatsoever.
The semantics of #include is one of the most underspecified points of
the C++ standard. It is up to the compiler vendor to decide what to do
with #include. Each vendor uses its own algorithm (unless they decided
on cloning the behavior of somebody else's compiler) and I've suffered
subtle bugs due to that fact while porting applications. IIRC the
standard says nothing about rewinding the search list for every lookup,
but I'm ready to admit that in practice removing trailing duplicates
makes no effect for all existing compilers and the vast majority of
cmake users will appreciate that feature, although I wouldn't bet my
neck on it.
That's true. But I bet that no vendor would be that insane to search the
include-directories in reverse order, or make it probabilistic, making
it more likely that a header gets picked up from a certain directory if
it is mentioned more often ;-)
:-)
Well, I must confess that when I wrote that removing trailing duplicates
on the search path can affect semantics, I was thinking that it was
actually true for some implementation, but at the same time I was unable
to recall which one. No longer:
http://www.delorie.com/gnu/docs/gcc/cpp_11.html
#include_next is like #include but it doesn't rewind the search list. I
would be quite surprised if there is no C/C++ software project that
depends on having a duplicates (even adjacent duplicates!) on the search
path.
But you could have found that out by yourself in about 20 seconds...
Please spare the inflammatory language for some other thread. Thanks.
Sorry for being snarky. I can only blame a foul mood due to a nasty cold
I caught...
No problem. It happens to me too (catching the flu and being snarky, not
necessarily at the same time.)
Have I missed something?
I reiterate Andreas' answer from yesterday. But there IS one point where
the removal of system directories could wreak potential havoc, but even
then, there's nothing CMake could do about it. Assume this situation:
[snip]
Agreed. This whole business is a can of worms. But I understand that
CMake can't do much about it, apart from applying some checks that could
alert the user that something is fishy. I'm not sure if it is worth the
effort.
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
Re: [CMake] CMake performs search for includes/libs in non-default compiler search paths.
Andreas Pakulat ap...@gmx.de writes:
On 27.01.11 16:13:09, arrowdodger wrote:
Hello. On FreeBSD everything, that distributes with system goes to /usr (i
mean includes go to /usr/includes and libs to /usr/lib) and all 3d party
stuff goes to /usr/local.
And the compiler is intentionally set to look only in /usr/include. The same
is for linker - it's looking for libs only in /usr/lib by default. So, if
user want to use some 3d-party library, he should add -I/usr/local/include
and -L/usr/local/lib to build command.
Now, i'm using find_library() and find_path() to locate 3d-party library in
such way:
find_path(FFI_INCLUDE_PATH ffi.h PATHS ${USER_DEFINED_INCLUDE_DIR})
find_library(FFI_LIBRARY_PATH ffi PATHS ${USER_DEFINED_LIB_DIR})
I'm expecting that search will not succeed until i supply CMake with
additional directories to search. But it's succeeds because
CMAKE_SYSTEM_PREFIX_PATH from Modules/Platform/UnixPaths.cmake is set to
/usr;/usr/local;/. And this file is included by
Modules/Platform/FreeBSD.cmake.
Later i'm doing:
if(${USER_DEFINED_INCLUDE_DIR})
include_directories(${FFI_INCLUDE_DIR})
endif()
On FreeBSD it leads to No such file or directory: ffi.h error. So here is
the question: Is this a CMake bug?
No, the bug is in your cmake code. You shouldn't use
USER_DEFINED_INCLUDE_DIR to decide wether to add the path to the
include-directories or not. Instead use the FFI_INCLUDE_PATH variable to
decide that, it won't hurt if FFI_INCLUDE_PATH happens to be /usr/include.
FFI_INCLUDE_PATH will evaluate to TRUE whenever find_library succeeds,
which means that the path will always be added with
include-directories. This has two consequences:
1. It pollutes the command line for the compiler. This is ugly and
inconvenient while debugging the build.
2. It affects the search order of include headers with subtle
effects. An example: if you later execute another include_directories
with a user-defined custom location for some set of headers that
override those provided by the system, you have a problem because
/usr/include already comes before the path you are adding.
The reason cmake searches in /usr/local in addition to /usr is simply a
convenience matter. Its a common prefix to have non-distribution software
installed in and for the same reason things like /opt/local, /opt/csw and
/usr/openwin are being searched for by default.
That's not a convenience here. We have to
if( we are on BSD )
add paths /usr/local/include /opt/local/include etc
same for libraries
endif()
which is ugly as hell, puts a lot of crap on the command line and may
create conflicts due to the altered search order.
IMO cmake should look by default on the directories where the compiler
automatically looks for. All other directories should be left for the
user to add, as he does while compiling something that picks a header or
library from a place not included on the default search path of the
compiler and linker.
___
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] CMake performs search for includes/libs in non-default compiler search paths.
Michael Wild them...@gmail.com writes: No, the bug is in your cmake code. You shouldn't use USER_DEFINED_INCLUDE_DIR to decide wether to add the path to the include-directories or not. Instead use the FFI_INCLUDE_PATH variable to decide that, it won't hurt if FFI_INCLUDE_PATH happens to be /usr/include. FFI_INCLUDE_PATH will evaluate to TRUE whenever find_library succeeds, which means that the path will always be added with include-directories. This has two consequences: 1. It pollutes the command line for the compiler. This is ugly and inconvenient while debugging the build. 2. It affects the search order of include headers with subtle effects. An example: if you later execute another include_directories with a user-defined custom location for some set of headers that override those provided by the system, you have a problem because /usr/include already comes before the path you are adding. The reason cmake searches in /usr/local in addition to /usr is simply a convenience matter. Its a common prefix to have non-distribution software installed in and for the same reason things like /opt/local, /opt/csw and /usr/openwin are being searched for by default. That's not a convenience here. We have to if( we are on BSD ) add paths /usr/local/include /opt/local/include etc same for libraries endif() which is ugly as hell, puts a lot of crap on the command line and may create conflicts due to the altered search order. IMO cmake should look by default on the directories where the compiler automatically looks for. All other directories should be left for the user to add, as he does while compiling something that picks a header or library from a place not included on the default search path of the compiler and linker. Sorry, but that is just a *LOT* of BS. Have you actually tried it?! Have you actually read the thread? Check out the following: [snip] That's right, -I/usr/include doesn't even show up ONCE, although I added it three times using include_directories(). Okay, cmake removes duplicated directories that already are on the list. So what? First, I hope that cmake does not optimize this series: A B C A ... to this: A B C or to this: B C A Removing adjacent duplicates is fine, but removing duplicates in general makes difficult to debug the build and may affect semantics. Second, the topic here is that we are forced to jump through hops because cmake tries to be helpful. It looks for files into places but then it is up to us to figure out if those places must be added to the list of header and library paths. That's not convenient at all, quite the contrary, it is messy and confusing, as we are experiencing. ___ 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] CMake performs search for includes/libs in non-default compiler search paths.
Michael Wild them...@gmail.com writes:
Okay, cmake removes duplicated directories that already are on the
list. So what?
First, I hope that cmake does not optimize this series:
A B C A
... to this:
A B C
or to this:
B C A
Removing adjacent duplicates is fine, but removing duplicates in general
makes difficult to debug the build and may affect semantics.
Second, the topic here is that we are forced to jump through hops
because cmake tries to be helpful. It looks for files into places but
then it is up to us to figure out if those places must be added to the
list of header and library paths. That's not convenient at all, quite
the contrary, it is messy and confusing, as we are experiencing.
The point I (and Andreas) wanted to make is that you can just add it. If
it's a system directory, CMake is going to filter it out (I didn't say
duplicates, I said doesn't even show up ONCE, which means *zero* times).
This is a moot point, because /usr/local/include and several other paths
which are searched by default by cmake are not system directories in
FreeBSD.
And yes, CMake simplifies A B C A to A B C, which is perfectly fine
because the trailing A doesn't have any effect whatsoever.
The semantics of #include is one of the most underspecified points of
the C++ standard. It is up to the compiler vendor to decide what to do
with #include. Each vendor uses its own algorithm (unless they decided
on cloning the behavior of somebody else's compiler) and I've suffered
subtle bugs due to that fact while porting applications. IIRC the
standard says nothing about rewinding the search list for every lookup,
but I'm ready to admit that in practice removing trailing duplicates
makes no effect for all existing compilers and the vast majority of
cmake users will appreciate that feature, although I wouldn't bet my
neck on it.
But you could have found that out by yourself in about 20 seconds...
Please spare the inflammatory language for some other thread. Thanks.
IMHO you're the one trying to jump through hoops that aren't even there...
Okay, so if I have this:
check_include_file(foo.h HAVE_FOO_H)
and it succeeds, I have no guarantees that a program such as this:
#include foo.h
will compile, becasue foo.h may be found on a directory not included on
the compiler's default search list.
Okay, so I have to add something like
figure_out_where_foo_h_really_is
include_directories( where_foo_h_is )
Not nice, but let's go ahead.
We end having something like /usr/local/include (or /opt/local/include
or /opt/pkg/include etc) on the search list.
We now test for the presence of some third party library (thelib). We
have an user-settable variable for using just in case we want to use an
specific install, and we use it:
cmake -DTHELIB_IS_HERE=/home/oscar/thelib .
The search mechanism for thelib looks into that directory first and
succeeds, as it should. We add the corresponding directory:
include_directories( ${THELIB_INCLUDE_PATH} )
But there is another install of thelib on /usr/local, and that install
is the one that will be used by our build because we end having this
search list:
/usr/local/include /home/oscar/thelib/include
Have I missed something?
___
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] CMake performs search for includes/libs in non-default compiler search paths.
Andreas Pakulat ap...@gmx.de writes: On 27.01.11 20:08:06, Óscar Fuentes wrote: Okay, so if I have this: check_include_file(foo.h HAVE_FOO_H) and it succeeds, I have no guarantees that a program such as this: #include foo.h will compile, becasue foo.h may be found on a directory not included on the compiler's default search list. Actually, thats wrong. If you look at the check_include_file macro you'll notice that it uses try_compile. That in turn (as documented in man cmake) creates a cmakelists.txt which only adds include dirs set via the INCLUDE_DIRECTORIES variable passed into the internal cmake call and otherwise just uses a simple add_executable() call for the source. The convenience paths are only added to things such as find_path, find_library etc. They are _not_ added to compiler invocations automatically. Hence the above check_include_file would fail if foo.h is in /usr/local/include and your compiler does not search there by default. So you'd need to either set CMAKE_REQUIRED_INCLUDES or use find_path and then add the director to include_directories(). Okay, this helps a lot. The original problem arised when a user who was trying to add support for a library reported that cmake was successfully finding the headers and library file (with find_*) without the user's help, but failing at build time because the compiler was unable to #include to headers. Then he reported that the library was located under a catch-all directory that is not part of the default search list of the compiler (/usr/local in FreeBSD) and I was reluctant to add it to include_directories, because that may cause problems like the described on my previous post if there is some library already installed on those catch-all extra directories (note that the problem does not arise if the library's headers are on /usr/include instead of /usr/local/include, because cmake takes care of /usr/include occurrences of the header search list, as Michael explained) All this is a potential source of confussion, but I understand that cmake is trying to be helpful and the problem is directly related to the established practice on Unixes. But there is another install of thelib on /usr/local, and that install is the one that will be used by our build because we end having this search list: /usr/local/include /home/oscar/thelib/include This has nothing to do with the default paths of the compiler, all you need to do with this is fix the order of include's of your target or source files. You'd run into compile problems (or compiling against the wrong lib version) no matter wether cmake searches in /usr/local/include for foo.h or not - unless you actually wanted cmake to _not_ find the foo.h header at all. If you want to ensure that /home/oscar/thelib/include is being searched before /usr/local/include then use include_directories with its BEFORE parameter so it ends up at the front of the list. This is the same thing if you'd create the compiler command yourself in a shell. When there is a series of libraries to be located and the user is allowed to give a custom location for each of them, that approach is not easy to implement. Thanks. ___ 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] Disabling exceptions and rtti on VS
If /EHs- /EHs-c- are added with add_definitions, the output of the build contains warnings: cl : Command line warning D9025 : overriding '/EHs' with '/EHs-' cl : Command line warning D9025 : overriding '/EHc' with '/EHc-' This is because cmake automatically adds /EHsc to the command line options. How can I remove /EHsc from the command line options before adding /EHs-c- ? ___ 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] Following dependencies through generated header file
Michael Hertling mhertl...@online.de writes: [snip] The basic idea is the following: The custom target foo invokes a script scandeps.cmake which uses an external dependency scanner - here, gcc's -M facility - to get the files zoo.cpp depends on. [snip] This approach works on *nix with Makefiles, but I don't know if it's suitable for other generators or IDE's. At some point on the past, the project did something similar for regenerating library dependencies on the fly. That feature was removed by someone because it was an ugly hack. And indeed it was, but it kept a working build in circunstances where now breaks. Its major drawback what that it only worked well with makefile generators. Obtaining header dependencies has the added problem that each compiler has its own method for getting them. I think that the procedure described on your previous post is the one to consider. Thanks 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] Following dependencies through generated header file
Michael Hertling mhertl...@online.de writes: It would be very convenient to inspect the header files referenced from `zoo.cpp' and associate them with `bar.inc', so when some of those header files are touched `bar.inc' (and hence `foo.cpp') is automatically re-built. Is this possible? Yes, with a bit of trickiness: [snip] Thanks for idea, Michael, sounds interesting, although having to use a library is an incovenience, mainly for the people who use IDEs. (The project I'm working on would need more than 20 such libraries) ___ 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] Following dependencies through generated header file
A file `foo.cpp' has this: #include bar.inc `bar.inc' is a generated file, and is marked as such. It is generated processing a file `zoo.cpp' with an utility executed through a custom command. It would be very convenient to inspect the header files referenced from `zoo.cpp' and associate them with `bar.inc', so when some of those header files are touched `bar.inc' (and hence `foo.cpp') is automatically re-built. Is this possible? ___ 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] CMake, JOM and multiple top-level targets
Bill Hoffman bill.hoff...@kitware.com writes: On 9/24/2010 1:03 PM, Óscar Fuentes wrote: JOM does a nice work compiling multiple files of the same top-level product (.exe, .dll etc) but for some reason it doesn't build multiple top-level targets in parallel. Here I have a project that generates several independent dlls, each based on one or two source files. JOM wont build DLL_N+1 until DLL_N is finished. This means that only one cpu core is working for a long part of the build. Is this a limitation of JOM or an oversight of CMake? This is a job limitation. What this means? ___ 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] CMake, JOM and multiple top-level targets
Bill Hoffman bill.hoff...@kitware.com writes: [snip] This is a limitation of jom, I know the maintainer of jom said he wanted to work on this as a feature, but I don't think he has done it yet... Thanks Bill. I'll open a bug report on the Qt bug tracker just to let him know that someone cares about that feature. ___ 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] CMake, JOM and multiple top-level targets
JOM does a nice work compiling multiple files of the same top-level product (.exe, .dll etc) but for some reason it doesn't build multiple top-level targets in parallel. Here I have a project that generates several independent dlls, each based on one or two source files. JOM wont build DLL_N+1 until DLL_N is finished. This means that only one cpu core is working for a long part of the build. Is this a limitation of JOM or an oversight of 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] Obtaining info about the compiler command arguments
Óscar Fuentes o...@wanadoo.es writes: How to know the compiler arguments set by include_directories, add_definitions, etc? CMAKE_LANG_FLAGS (with and whitout the uppercase build_type suffix) doesn't contain anything that was set by the cmake commands mentioned above. I guess that the lack of response indicates that there is no way to do that. Why so basic feature is missing? Something with the internals of cmake that makes it hard to implement? ___ 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] Obtaining info about the compiler command arguments
Michael Wild them...@gmail.com writes: How to know the compiler arguments set by include_directories, add_definitions, etc? CMAKE_LANG_FLAGS (with and whitout the uppercase build_type suffix) doesn't contain anything that was set by the cmake commands mentioned above. I guess that the lack of response indicates that there is no way to do that. Why so basic feature is missing? Something with the internals of cmake that makes it hard to implement? Well, your question isn't very clear. Are you interested in the compiler flag (i.e. -I or -D) or would you like to query the active include directories and definitions? I'm interested on the literal parameters as they are passed to the compiler. The former are available through the variables CMAKE_INCLUDE_FLAG_C and CMAKE_lang_DEFINE_FLAG, although AFAIK the latter may not be set and defaults to -D. The latter are available through the directory properties INCLUDE_DIRECTORIES and DEFINITIONS. But doing some RTFM would have told you that... Yes, I RTFM. My test code contained a typo on the variable's name :-( This remembers me why, being a bad typist, I try to avoid so much the languages that accept undefined variables. ___ 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] Obtaining info about the compiler command arguments
How to know the compiler arguments set by include_directories, add_definitions, etc? CMAKE_LANG_FLAGS (with and whitout the uppercase build_type suffix) doesn't contain anything that was set by the cmake commands mentioned above. ___ 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] Does the echo command use the system shell?
Michael Wild them...@gmail.com writes: The problem is, CMake has to go through the system shell. Of course, CMake could write the command to a file and then invoke a custom interpreter from the system shell, but that would probably be very inefficient and would require CMake to implement a full shell language. Another option for cmake is to appropriately quote the string so the system shell does not alter it. Consider cmake -E echo #hello cmake would put on the Unix makefile something like cmake -E echo \#hello and on windows MinGW makefile or VS project it would be cmake -E echo #hello [snip] But we still don't know what your general goal is, WHY you need this and why e.g. a simple add_definitions() isn't enough (because so far I haven't seen anything that requires you to do this stuff dynamically at build-time). This is not the issue. As mentioned on the previous posts, the question is how much confidence can I have on the platform independence of the -E commands. The stated goal is to provide platform isolation. We have seen that this is not completely true. But if you insist on knowing the context that raised the issue, it consisted on the requirement of creating a header file containing a #define with a quoted list of the names of the source files of the project. configure_file is a solution, but requires having a pre-existing .in file and I'll like to avoid polluting the source tree as much as possible. Then add_custom_command seemed a good fit. Maintenance-wise, it is simpler than configure_file+file.in or file(WRITE+configure_file and has the added feature of regenerating the file if it is deleted by mistake. So here we are. ___ 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] Does the echo command use the system shell?
Andreas Pakulat ap...@gmx.de writes: [snip] add_custom_command( OUTPUT build.h COMMAND cmake -E echo \\#define FOO \\bar\\\ build.h ) Well, it even makes sense, although it is not immediately obvious. Thanks! You can easily see your mistake by running (n)make VERBOSE=1 to see the actual cmake -E execution. IMHO if echo creates different output for the same literal string on different platforms, that's a problem. ___ 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] Does the echo command use the system shell?
Eric Noulard eric.noul...@gmail.com writes: [snip] May be I was too pushy on that, sorry. No problem. Thanks for trying to help. ___ 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] Does the echo command use the system shell?
Óscar Fuentes o...@wanadoo.es writes:
Andreas Pakulat ap...@gmx.de writes:
[snip]
add_custom_command( OUTPUT build.h
COMMAND cmake -E echo \\#define FOO \\bar\\\
build.h )
Well, it even makes sense, although it is not immediately
obvious. Thanks!
I spoke too soo. This command:
add_custom_command(OUTPUT buildobj.h
COMMAND ${CMAKE_COMMAND} -E echo \\#define BUILDOBJ \\foo bar\\\
buildobj.h
)
works fine on Windows. But on Linux it the file contents are this:
#define BUILDOBJ foo\ bar
This is quoting hell. Back to configure_file.
___
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] Does the echo command use the system shell?
Michael Wild them...@gmail.com writes: This is quoting hell. Back to configure_file. What's wrong with my solution? Doesn't even require a custom command... It is more complex than configure_file, although it has the advantage of not requiring a .in file to configure. As this code is suppossed to be understandable by people with very slim knowledge about cmake, the simplest solution wins. On that sense the add_custom_command was best, because when they see echo and the redirection to the file they immediately guess what's going on. ___ 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] Configured C header dependency problem
Eric Noulard eric.noul...@gmail.com writes: 2010/7/28 Óscar Fuentes o...@wanadoo.es: I'm using cmake 2.8.2 on Linux/make and on Windows/make-mingw32 The project configures a template config.cmake producing config.h. That header is included by all C files on the project. While building in-source, touching config.h only triggers the rebuild if config.h is included as #include config.h but not as #include config.h While building out of source, touching config.h does not trigger the rebuild of the C files not matter how the header is used. Touching any other header file triggers the rebuild of the corresponding C source files. The project follows the pattern platform macros configure config.cmake - config.h (using configure_file) add_subdirectory add_executable(foo file1.c file2.c ...) Did you try adding the config.h to your list of files in add_executable ? Do not forget to set_source_files_properties(config.h PROPERTIES GENERATED TRUE) Thanks for the suggestions. Just tried them, separately and combined. No change. OTOH, I would expect from configure_file to automatically do that, and from the depedency scanner to detect config.h. This is what I do on other projects, without problems. Any suggestion? May be config.h is found in some add_executable/add_library for those project? Nope. In the C.includescache file config.h is mentioned, twice. So the dependency scanner detects the file, but then it is ignored. The config.h file is in D:/dev/other/emacs/qbuild/src/config.h (the build directory.) This is an excerpt of C.includescache: D:/dev/other/emacs/git/src/alloc.c config.h D:/dev/other/emacs/git/src/config.h stdio.h - limits.h - setjmp.h - signal.h - pthread.h - lisp.h D:/dev/other/emacs/git/src/lisp.h process.h D:/dev/other/emacs/git/src/process.h intervals.h D:/dev/other/emacs/git/src/intervals.h puresize.h D:/dev/other/emacs/git/src/puresize.h buffer.h D:/dev/other/emacs/git/src/buffer.h window.h D:/dev/other/emacs/git/src/window.h keyboard.h D:/dev/other/emacs/git/src/keyboard.h frame.h D:/dev/other/emacs/git/src/frame.h blockinput.h D:/dev/other/emacs/git/src/blockinput.h character.h D:/dev/other/emacs/git/src/character.h syssignal.h D:/dev/other/emacs/git/src/syssignal.h termhooks.h D:/dev/other/emacs/git/src/termhooks.h setjmp.h - unistd.h - fcntl.h - fcntl.h - w32.h D:/dev/other/emacs/git/src/w32.h malloc.h - stdio.h - ___ 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] Does the echo command use the system shell?
For creating a file at build time with a content like this:
#define foo bar
I use this on Linux:
add_custom_command(OUTPUT buildobj.h
COMMAND ${CMAKE_COMMAND} -E echo \\#define foo \\\bar\\\
buildobj.h
)
but that doesn't work on Windows, because it outpus:
\#define foo bar
Removing the backslashes before `#' fixes the problem on Windows, but
then breaks the Linux build.
This looks as if `echo' was using the system shell for doing the job,
because the escapes works differently on each system.
What's the right way to write the above command so it works on all
platforms?
___
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] Does the echo command use the system shell?
Eric Noulard eric.noul...@gmail.com
writes:
[snip]
if you need build
time creation of the file then you may write a CMake script
generateMyFile.cmake which contains such commands and use
add_custom_command( ...
COMMAND ${CMAKE_COMMAND} -P generateMyFile.cmake
...)
That approach justs shifts the problem to a separate cmake script, but
it still remains.
The task here is to write a literal string containing a special
character (#) to a file, at build time. For cmake -E echo it requires
platform-dependent escape sequences. My idea about the cmake -E commands
was that they purpose is to abstract platform differences, but seems
that that is not entirely correct, as they inherit some traits from the
underlying platform. Or is it a bug?
[snip]
___
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] Configured C header dependency problem
Alexander Neundorf a.neundorf-w...@gmx.net writes: In the C.includescache file config.h is mentioned, twice. So the dependency scanner detects the file, but then it is ignored. The config.h file is in D:/dev/other/emacs/qbuild/src/config.h (the build directory.) This is an excerpt of C.includescache: D:/dev/other/emacs/git/src/alloc.c config.h D:/dev/other/emacs/git/src/config.h This looks like it decided for D:/dev/other/emacs/git/src/config.h instead of D:/dev/other/emacs/qbuild/src/config.h . What's the exact compile command (from make VERBOSE=1) ? This is from Linux: cd /home/oscar/dev/other/emacs/qbuild/src /usr/bin/gcc -Demacs -DHAVE_CONFIG_H -I. -I/home/oscar/dev/other/emacs/qbuild/src -I/home/oscar/dev/other/emacs/git/src -I/usr/include/freetype2 -o CMakeFiles/qemacs.dir/alloc.c.o -c /home/oscar/dev/other/emacs/git/src/alloc.c ___ 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] Configured C header dependency problem
Óscar Fuentes o...@wanadoo.es writes: Alexander Neundorf a.neundorf-w...@gmx.net writes: In the C.includescache file config.h is mentioned, twice. So the dependency scanner detects the file, but then it is ignored. The config.h file is in D:/dev/other/emacs/qbuild/src/config.h (the build directory.) This is an excerpt of C.includescache: D:/dev/other/emacs/git/src/alloc.c config.h D:/dev/other/emacs/git/src/config.h This looks like it decided for D:/dev/other/emacs/git/src/config.h instead of D:/dev/other/emacs/qbuild/src/config.h . What's the exact compile command (from make VERBOSE=1) ? This is from Linux: cd /home/oscar/dev/other/emacs/qbuild/src /usr/bin/gcc -Demacs -DHAVE_CONFIG_H -I. -I/home/oscar/dev/other/emacs/qbuild/src -I/home/oscar/dev/other/emacs/git/src -I/usr/include/freetype2 -o CMakeFiles/qemacs.dir/alloc.c.o -c /home/oscar/dev/other/emacs/git/src/alloc.c Since the C.includescache excerpt showed above is from MinGW, maybe it is is more clear to show the command of that build: cd D:\dev\other\emacs\qbuild\src C:\apps\msys\1.0\mingw\bin\gcc.exe -Demacs -DHAVE_CONFIG_H -DHAVE_NTGUI -g -I. -ID:/dev/other/emacs/git/nt/inc -ID:/dev/other/emacs/qbuild/src -ID:/dev/other/emacs/git/src -o CMakeFiles\qemacs.dir\alloc.c.obj -c D:\dev\other\emacs\git\src\alloc.c ___ 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] Configured C header dependency problem
Alexander Neundorf a.neundorf-w...@gmx.net writes: ...not sure about that dot here. Do you have something like include_directories ( . ) in your CMakeLists.txt ? Okay, problem solved. I was adding the directories with add_definitions(-I...) instead of include_directories(...) Thank you, Alex. [snip] ___ 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] Does the echo command use the system shell?
Eric Noulard eric.noul...@gmail.com
writes:
I think you are wrong.
May be you can try the attach script.
try:
cmake -DYOURSTRING=I like # \ it -DTHE_FILE=toto.txt -P writeany.cmake
You shouldn't have quite problem with the previous approach.
I tried this on Linux:
add_custom_command(OUTPUT ${EMACS_BUILD_DIR}/src/buildobj.h
COMMAND cmake -DYOURSTRING=#define BUILDOBJ -DTHE_FILE=buildobj.h -P
writeany.cmake
COMMENT Creating buildobj.h
)
It didn't create the file. So tried this:
add_custom_command(OUTPUT ${EMACS_BUILD_DIR}/src/buildobj.h
COMMAND cmake -DYOURSTRING=\#define BUILDOBJ -DTHE_FILE=buildobj.h -P
writeany.cmake
COMMENT Creating buildobj.h
)
It put this text on the resulting file:
#define\ BUILDOBJ
That's not quite what I wanted.
I would say that having to write and invoke a script for this trivial
task seems way too much trouble imposed by an otherwise absolute
time-saver as cmake is.
The task here is to write a literal string containing a special
character (#) to a file, at build time. For cmake -E echo it requires
platform-dependent escape sequences. My idea about the cmake -E commands
was that they purpose is to abstract platform differences, but seems
that that is not entirely correct, as they inherit some traits from the
underlying platform. Or is it a bug?
I would say a feature :-)
You do not want to have to escape some sequences
I'm happy escaping whatever as much sequences as necessary. What is not
okay is to change escape rules depending on the plataform (or worse,
depending on the shell cmake uses for the generator. Mingw Makefiles
- cmd.exe, MSYS Makefiles - sh.exe)
[snip]
More seriously I think it's complicated to avoid system specific
issues with a command like echo.
It should be possible to pass an arbitrary string (containing
backslashes if necessary) to echo and send it to the console or
redirected to a file on a platform independent way. That means avoiding
any middleman that may reinterpret certain characters as per its own
rules. If you pass the string through the shell, all hopes of platform
independence are gone.
I think that if you tell me what you would expect I may probably gives
you an example of mine were YOUR bug is a feature for ME.
I doubt that, because on the end we want the same: saying take this
string and put it on that file. We can then open the file and test
that, effectively, the string is there.
OTOH I can't think of a real application for this sort of behavior of
the echo command. That is, nothing that you could achieve invoking the
platform's shell.
That said, that's my own opinion, I may be wrong.
___
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] Does the echo command use the system shell?
Michael Wild them...@gmail.com writes: [snip] Perhaps you need to tell us what it is that you are trying to achieve, because I suspect that you are over-thinking things and that there is a much simpler solution. E.g. what should buildobj.h contain (semantically, not the exact strings), and why is it only known at build time? I solved this specific instance with configure_file. It is not as convenient as the original add_custom_command method but it works. What really concerns me is the general problem: a CMake command that acts on a platform-dependent way when the existence of those -E commands are motivated, precisely, for the cross-platform nature of CMake. Maybe I should file a bug report and see how it fares. ___ 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] Configured C header dependency problem
I'm using cmake 2.8.2 on Linux/make and on Windows/make-mingw32 The project configures a template config.cmake producing config.h. That header is included by all C files on the project. While building in-source, touching config.h only triggers the rebuild if config.h is included as #include config.h but not as #include config.h While building out of source, touching config.h does not trigger the rebuild of the C files not matter how the header is used. Touching any other header file triggers the rebuild of the corresponding C source files. The project follows the pattern platform macros configure config.cmake - config.h (using configure_file) add_subdirectory add_executable(foo file1.c file2.c ...) This is what I do on other projects, without problems. Any suggestion? ___ 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] Copying cmake generated files to another machine
Brad King brad.k...@kitware.com writes: [snip] In return for the above explanation, I request an explanation as to the restrictions that make distributing CMake so hard, particularly on machines that already have the entire GNU toolchain. Have you ever tried to build GCC 4.4 and all its dependencies from scratch? It's do-able, but the effort is much greater than installing CMake. If there is any reason not to install CMake other than it's another dependency, perhaps we can address it. If the only reason is that it's another dependency, consider that once CMake is installed it can find all the *other* dependencies automatically on most systems. My knowledge about Steve's circumstance is just a bit more detailed than what he exposed here, but I have experience on even stricter environments and can explain how the thing goes: A department's work is to certify some piece of software for some purpose (release to the public, internal use, etc). They have the source code (LLVM/clang, on this case) and hence they need a compiler (VC++). LLVM/clang has no external dependencies, it only uses the system libraries. So adding CMake to the requirements is to add a dependency where none was required before. The people who do that kind of work is very strict (anal retentive if you prefer) and will resist any change on their work routine. If Steve sneaks CMake's source code with the LLVM/clang source base and adds a script for building the whole package, maybe the clients will not care. If he adds installing CMake and invoking it for generating the VC++ project files, it is very likely that he will find a strong resistance. -- Óscar ___ 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] Copying cmake generated files to another machine
steve naroff snar...@apple.com writes: Our current thinking is to post process the cmake generated files and remove all the absolute paths (since the project files are simply text). Since cmake is a black box to me (and I am unfamiliar with it's generated 'code'), it's unclear if this a 'good' idea? Or will I bump into other gotcha's? I suggested that option to you on the past. My guess is that the VS project files generated by CMake depends less on absolute paths than the Makefiles generated for other build systems. Building in-source maybe diminishes the amount of work too. As LLVM/clang have no external dependencies, the problem is simpler. If VS is installed on C: and the LLVM source and build directories are on C: too, the problem is even simpler, because you can always replace an absolute path with a relative one. My advice is to start small: with a text editor, edit the top-level project file, then edit the project file of lib/System, which does not depend on any other file. Move the whole tree to somewhere else, open VS and build just the System library. If it works, that's good. Proceed to write a script for automating the absolute-relative path conversion. Any advice is appreciated...you have a lot more experience with this than I do! Nor really. I investigated a bit when you asked but found essentially what Eric and Brad explained on this thread. -- Óscar ___ 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] Copying cmake generated files to another machine
Bill Hoffman bill.hoff...@kitware.com writes: [snip] Even with the IDE based files if you are using install rules, then the CMake executable must be available on the machine doing the install. CMake is also used as the program to do the install commands. So, CMake is really required for a variety of reasons. Bummer. I completely forgot about this. Steve, ditch the idea about the absolute-relative path conversion. You really need to distribute CMake with the LLVM/clang sources, either as source or as binary, and add a .bat for bootstrapping the thing. Is that acceptable for your clients? [snip] -- Óscar ___ 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] Copying cmake generated files to another machine
Pau Garcia i Quiles pgqui...@elpauer.org writes: My advice is to start small: with a text editor, edit the top-level project file, then edit the project file of lib/System, which does not depend on any other file. Move the whole tree to somewhere else, open VS and build just the System library. If it works, that's good. Proceed to write a script for automating the absolute-relative path conversion. You are wasting your time. It's not going to be that easy. You will need to replace all the calls to CMake with generated stuff. Even in the improbable case you succeed, you would be giving people something which somewhat works, you would not be shipping the actual buildsystem but some kind of a pseudo-pre-geneated buildsystem. You are right. Morale: anal retentive people must learn that opening your ass to something new may make you happier. It is not so easy. Anal retentive people have the right personality traits for doing QA and certification work. -- Óscar ___ 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] Copying cmake generated files to another machine
Hello Steve and Eric. Eric Noulard eric.noul...@gmail.com writes: 2009/12/6 steve naroff snar...@apple.com: May be we can think of packaging CMake itself along with the build tree? Packaging the binaries isn't considered acceptable (we need a pure source distribution with no binary files). Sorry for being picky but you don't require a pure source. You want to have the file used by your target build system (Makefile or any other project file) to be shipped with your source tree. In the past, LLVM/clang had a manually crafted Visual Studio project file. That worked fine for the purposes of the OP. It was pure source because you obtained it directly from the svn repository along the project source code and it was ready to build with VS, no intermediate steps required. The VS project file was removed and this is causing problems to the OP, because the pure source requirement is imposed upon him by somebody else. [snip] A spin on your idea is to package the CMake source itself (and build it from scratch, prior to building llvm/clang). Unfortunately, this approach is quite heavy (but may be the cleanest given the constraints). For the others this would require: 1. build cmake. 2. invoke cmake for configuring LLVM/clang. 3. invoke VS for building the LLVM/clang. You can solve 12 with a .bat file. With cmake 2.8, you can build LLVM from the .bat file too (with the new cmake --build feature, IIRC), but I guess that them are having too much fun building LLVM with the VS IDE :-) I see. Personnally I have another point of view regarding this. Once I decided to go for a CMake build system for my project, I consider CMake to be part of the compiler suite. If I require a compiler to be installed for compiling the source of my project I do require CMake to be installed too. That is very sensible but, unfortunately, the OP can't do much about it. [snip] -- Óscar ___ 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] add_custom_command using CMAKE_CXX_FLAGS
Tyler Roscoe ty...@cryptio.net writes:
On Sun, Aug 23, 2009 at 09:03:22PM -0400, John Smith wrote:
I am using the following test case in an attempt to add a custom
command to build an assembly file. The assembly file should be
compiled with the C++ compiler driver (which in turn should invoke the
assembler after pre-processing), and I am building up a
CMAKE_CXX_FLAGS variable from separate pieces:
I think you can just hand your .S files to add_library(). Did you try
searching the ML archives or google for how to handle assembler files
with CMake?
Assembler support is broken, at least for masm/64 as some user reported
here some days ago.
enable_language(ASM_MASM)
set(sources ${sources} X86CompilationCallback_Win64.asm)
My users say that with the previous code the build pretends to compile
the assembler file as if it were a C file.
If the other assemblers are broken too, I guess this is the reason
people are trying workarounds.
[snip]
--
Óscar
___
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] OBJECT_DEPENDS and target-level dependency.
The source files of a library depend on generated files from another library on its parent directory. Let's call them libParent and libChild. For the source files on libChild I do SET_SOURCE_FILES_PROPERTIES(some_source.cpp PROPERTIES OBJECT_DEPENDS libParent) This way I try to delay the compilation of some_source.cpp until libParent is finished. But when make -j4 attempts to build some_source.cpp it fails saying that it doesn't know how to make libParent. Is this a bug on cmake or I'm using the wrong approach? cmake 6.4.4, unix makefiles, gnu make, linux. -- Óscar ___ 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] OBJECT_DEPENDS and target-level dependency.
Tyler Roscoe ty...@cryptio.net writes: On Sun, Aug 16, 2009 at 09:54:09AM +0200, Óscar Fuentes wrote: The source files of a library depend on generated files from another library on its parent directory. Let's call them libParent and libChild. For the source files on libChild I do SET_SOURCE_FILES_PROPERTIES(some_source.cpp PROPERTIES OBJECT_DEPENDS libParent) This way I try to delay the compilation of some_source.cpp until libParent is finished. Can you just use add_dependencies (libChild libParent)? Then this means that the source files of libChild will not be compiled until libParent is fully built, right? cmake 6.4.4, unix makefiles, gnu make, linux. There is no CMake 6.4.4. 2.6-patch 4 Thanks. -- Óscar Fuentes Desarrollo de Software ___ 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] OBJECT_DEPENDS and target-level dependency.
Tyler Roscoe ty...@cryptio.net writes: The source files of a library depend on generated files from another library on its parent directory. Let's call them libParent and libChild. For the source files on libChild I do SET_SOURCE_FILES_PROPERTIES(some_source.cpp PROPERTIES OBJECT_DEPENDS libParent) This way I try to delay the compilation of some_source.cpp until libParent is finished. Can you just use add_dependencies (libChild libParent)? Then this means that the source files of libChild will not be compiled until libParent is fully built, right? Yes. Is there some reason you don't want this to happen? No, that's right, although the best thing would be to create a dependency on the generated files of libParent instead of on libParent itself, but as the project is quite large, it doesn't impact parallel builds too much. Thanks again. -- Óscar ___ 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] A curiosity: cmake detects the wrong compiler when -g is used instead of -G
This held me confused for 15 minutes or so. I'm on windows with Mingw's bin directory as the first item on PATH. `cl' is *not* on the PATH. If I invoke it from the same command line the shell says that there is no such executable. Please note the -g parameter instead of -G: D:\dev\idb-llvm\lp0\build\mingw\debugcmake -g MinGW Makefiles -DLLVM_ROOT=d:/dev/llvm/svnDebugMinGW44 -DCMAKE_BUILD_TYPE=Debug ../../.. -- Check for working C compiler: cl -- Check for working C compiler: cl -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: cl -- Check for working CXX compiler: cl -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- /INCREMENTAL:NO -- Configuring done -- Generating done -- Build files have been written to: D:/dev/idb-llvm/lp0/build/mingw/debug -- Óscar ___ 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] OBJECT_DEPENDS and target-level dependency.
Tyler Roscoe ty...@cryptio.net writes: On Sun, Aug 16, 2009 at 09:18:31PM +0200, Óscar Fuentes wrote: No, that's right, although the best thing would be to create a dependency on the generated files of libParent instead of on libParent itself, but as the project is quite large, it doesn't impact parallel builds too much. Ok now I'm curious: why would a dependency on the generated files themselves be the best thing? You could still do it that way, though it's more work and I do not yet see any benefit. If the source files on the libChild depended on the generated files alone instead of the entire libParent, they could be built as soon as the generated files are delivered, instead of waiting for libParent. The generation of those files are grouped into a custom target. There is a dependency of libParent on that custom target. I guess that creating a depedency of libChild on the custom target would do the trick. The important info of this thread to me is that you don't need OBJECT_DEPENDS for creating dependencies on generated files. Just create a dependency of the library or executable on the custom target that triggers the generation of the files. The sources will not be compiled until the custom target is finished. -- Óscar ___ 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] DejaGNU.
A project has a large number of DejaGNU tests and it is unfeasible to translate them to CTest. So far I think it is possible to configure and drive DejaGNU from cmake for running all the test suite, but not parts or individual tests. Any experiences or advices on how to deal with DejaGNU from cmake is welcomed. -- Óscar Fuentes Desarrollo de Software ___ 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] CMAKE_C*_FLAGS undefined.
Philip Lowman phi...@yhbt.com writes:
CMAKE_CXX_FLAGS / CMAKE_C_FLAGS is empty by default on Linux unless
you've
modified it which may have been what happened. The build type specific
complilation flags are stored in CMAKE_CXX_FLAGS_config_type.
CMAKE_CXX_FLAGS is a base that gets prepended to all of the build
solutions.
The command pasted below works for me on CMake 2.6.4 RC3 Win32 using the
MinGW generator (it outputs the flags used to compile during a Release
build). If something like this doesn't work for you can you reply with
your
version of CMake and generator you're using?
add_custom_target(foo COMMAND C:/cygwin/bin/echo.exe flags:
${CMAKE_CXX_FLAGS} ${CMAKE_CXX_FLAGS_RELEASE})
CMAKE_CXX_FLAGS_RELEASE works, but it is not enough. It still misses the
definitions and other options which are passed to the
compiler. CMAKE_CXX_FLAGS, as noted on my previous message, is empty.
add_custom_command(OUTPUT ${LLVM_CONFIG}
COMMAND echo flags: ${CMAKE_CXX_FLAGS_DEBUG} ${CMAKE_CPP_FLAGS}
${CMAKE_C_FLAGS}
COMMAND echo 's...@llvm_cppflags@!${CMAKE_CPP_FLAGS}!' temp.sed
COMMAND echo 's...@llvm_cflags@!${CMAKE_C_FLAGS}!' temp.sed
COMMAND echo 's...@llvm_cxxflags@!${CMAKE_CXX_FLAGS}!' temp.sed
# TODO: Use general flags for linking! not just for shared libs:
COMMAND echo 's...@llvm_ldflags@!${CMAKE_SHARED_LINKER_FLAGS}!' temp.sed
COMMAND echo 's...@libs@!!' temp.sed# TODO: System
libs
COMMAND echo 's...@llvm_buildmode@!${CMAKE_BUILD_TYPE}!' temp.sed
COMMAND sed -f temp.sed ${LLVM_CONFIG_IN} ${LLVM_CONFIG}
# some stuff omitted
DEPENDS ${FINAL_LIBDEPS} ${LLVM_CONFIG_IN}
COMMENT Building llvm-config script.
)
This builds an script that knows the compiler and linker options used
for building the libraries. Later, other (third party) software can
query the script and check those options for ensuring compatibility with
the libraries.
`configure_file' is not okay because the configuration must be
executed at build time. CMAKE_CXX_FLAGS and co. are also empty at cmake
time though, so `configure_file' would have the same problem.
You might want to have a look at the COMPILE_DEFINITIONS target property.
That's interesting, but its contents is sans the -D:
_GNU_SOURCE __STDC_LIMIT_MACROS __STDC_CONSTANT_MACROS
instead of
-D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS
This can be overcomed with string manipulation. But the docs says that
only flags beginning with -D or /D are added to this property. Where the
rest of the flags go?
add_definitions(-DFOO -Wl,s -save-temps)
will put FOO into the COMPILE_DEFINITIONS property, bug how can I access
the other flags?
Another option of course is you can use configure_file() and
As explained on my previous message, configure_file is not adequate: the
file to be configured is generated at build time.
OTOH, what happens if the user sets CFLAGS and other environment
variables that affects the build after cmake is run? I ask just out of
curiosity, as I know that the method I'm using for configuring the file
does not take into account this possibility.
[snip]
Can you attach a trivial reproducer of your problem? I guess I'm hung
up on what variables you're talking about that you think would change
between CMake configure time and building time? As far as I know the
variables in your Makefile with the sole exception of make variables
like VERBOSE=1 are all determined at CMake time. configure_file()
should make your life quite a bit easier I think.
Even if configure_file were adequate, the variables CMAKE_C_FLAGS
CMAKE_CXX_FLAGS etc are empty, when I expect them to have the full
compiler options for the current build type, including the stuff
introduced with add_definitions.
I can't believe that there is not a simple method for knowing such a
basic piece of information as which compiler switches and options are
used for compiling source files of language X? so it seems that I'm
missing something.
--
Oscar
___
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] CMAKE_C*_FLAGS undefined.
Philip Lowman phi...@yhbt.com writes:
[snip]
One suggestion would be if you have non-definition flags you want to add to
every compilation you make, simply use CMAKE_C_FLAGS or CMAKE_CXX_FLAGS.
if(CMAKE_COMPILER_IS_GNU_CC)
set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -Wl,s -save-temps)
endif()
Wouldn't this conflict with the cache?
add_definitions() was originally intended for preprocessor definitions
only. If you're using it to non-definition compilation flags I have no idea
how you'll be able to pull those out again.
As per my interpretation of the docs, add_definitions is the recommended
way of adding extra compiler options. I may wrong.
OTOH, what happens if the user sets CFLAGS and other environment
variables that affects the build after cmake is run? I ask just out of
curiosity, as I know that the method I'm using for configuring the file
does not take into account this possibility.
You can set CFLAGS and/or CXXFLAGS but they only work before the first
configure. After that they are ignored. If you need to change
CFLAGS/CXXFLAGS after that the best way is to modify CMAKE_C_FLAGS and
CMAKE_CXX_FLAGS in the CACHE.
Thanks.
I can't believe that there is not a simple method for knowing such a
basic piece of information as which compiler switches and options are
used for compiling source files of language X? so it seems that I'm
missing something.
There might be a better way to do this I'm not aware of. If so hopefully
someone else can chime in.
Okay. Thanks for your help so far Philip.
--
Oscar
___
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] CMAKE_C*_FLAGS undefined.
I have this:
add_custom_command(OUTPUT ${LLVM_CONFIG}
COMMAND echo flags: ${CMAKE_CXX_FLAGS} ${CMAKE_CPP_FLAGS} ${CMAKE_C_FLAGS}
more stuff
When the custom command executes, this is the output:
flags:
i.e. the variables are empty, although I previously used add_definitions
to add flags and the makefile uses the optimization flags that
corresponds to the selected build type.
How can I access the effective values of the flags used when the
makefile is generated?
--
Oscar
___
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] CMAKE_C*_FLAGS undefined.
Hi Philip.
Philip Lowman phi...@yhbt.com writes:
I have this:
add_custom_command(OUTPUT ${LLVM_CONFIG}
COMMAND echo flags: ${CMAKE_CXX_FLAGS} ${CMAKE_CPP_FLAGS}
${CMAKE_C_FLAGS}
more stuff
When the custom command executes, this is the output:
flags:
i.e. the variables are empty, although I previously used add_definitions
to add flags and the makefile uses the optimization flags that
corresponds to the selected build type.
How can I access the effective values of the flags used when the
makefile is generated?
CMAKE_CXX_FLAGS / CMAKE_C_FLAGS is empty by default on Linux unless you've
modified it which may have been what happened. The build type specific
complilation flags are stored in CMAKE_CXX_FLAGS_config_type.
CMAKE_CXX_FLAGS is a base that gets prepended to all of the build solutions.
The command pasted below works for me on CMake 2.6.4 RC3 Win32 using the
MinGW generator (it outputs the flags used to compile during a Release
build). If something like this doesn't work for you can you reply with your
version of CMake and generator you're using?
add_custom_target(foo COMMAND C:/cygwin/bin/echo.exe flags:
${CMAKE_CXX_FLAGS} ${CMAKE_CXX_FLAGS_RELEASE})
CMAKE_CXX_FLAGS_RELEASE works, but it is not enough. It still misses the
definitions and other options which are passed to the
compiler. CMAKE_CXX_FLAGS, as noted on my previous message, is empty.
I'm using 2.6.1 on Linux, gnu makefiles.
Also, to possibly anticipate your next question: On Makefile generators you
should be able to get the current build type being used by the end user by
referencing CMAKE_BUILD_TYPE.
CMAKE_BUILD_TYPE contains the correct build type.
To expand a bit, this is what I'm trying to do:
add_custom_command(OUTPUT ${LLVM_CONFIG}
COMMAND echo flags: ${CMAKE_CXX_FLAGS_DEBUG} ${CMAKE_CPP_FLAGS}
${CMAKE_C_FLAGS}
COMMAND echo 's...@llvm_cppflags@!${CMAKE_CPP_FLAGS}!' temp.sed
COMMAND echo 's...@llvm_cflags@!${CMAKE_C_FLAGS}!' temp.sed
COMMAND echo 's...@llvm_cxxflags@!${CMAKE_CXX_FLAGS}!' temp.sed
# TODO: Use general flags for linking! not just for shared libs:
COMMAND echo 's...@llvm_ldflags@!${CMAKE_SHARED_LINKER_FLAGS}!' temp.sed
COMMAND echo 's...@libs@!!' temp.sed# TODO: System libs
COMMAND echo 's...@llvm_buildmode@!${CMAKE_BUILD_TYPE}!' temp.sed
COMMAND sed -f temp.sed ${LLVM_CONFIG_IN} ${LLVM_CONFIG}
# some stuff omitted
DEPENDS ${FINAL_LIBDEPS} ${LLVM_CONFIG_IN}
COMMENT Building llvm-config script.
)
This builds an script that knows the compiler and linker options used
for building the libraries. Later, other (third party) software can
query the script and check those options for ensuring compatibility with
the libraries.
`configure_file' is not okay because the configuration must be
executed at build time. CMAKE_CXX_FLAGS and co. are also empty at cmake
time though, so `configure_file' would have the same problem.
Thanks for looking into this.
--
Oscar
___
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] How to deal with make uninstall ?
Group [EMAIL PROTECTED] writes: [snip] When I use make install, everything do as I wanted. But I can't use make uninstall. How to deal with it? http://www.cmake.org/Wiki/CMake_FAQ#Can_I_do_.22make_uninstall.22_with_CMake.3F And I hope you can give me more links about cmake tutorial. http://www.cmake.org/Wiki/CMake#Tutorials -- Oscar ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Convenience lib vs static library
James Mansion [EMAIL PROTECTED] writes: [snip] I think Oscar is wrong here: A convenience library works as an object file at link time: it is included on the final executable as any other object file. Or at least, that's an unnecessarily limited view. The terminology is debatable. The view can be limited and the terminology debatable, but the mentioned usage of the convenience library is not wrong. [snip] -- Oscar ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Convenience lib vs static library
Andreas Pakulat [EMAIL PROTECTED] writes: Huh? I'm not aware of that as a limitation - you *do* need the objects in the static library to be position-independant or otherwise compiled as objects to go into a shared library. Thats ok on linux, to get it working on 64 bit systems (32 bit don't need -fPIC). However on some systems this is not supported at all, i.e. the linker simply doesn't support creating a shared library from static libs. I think one of those systems is windows, or rather MSVC. You can use a .def file on MSVC for telling the linker what to export while creating the dll file. -- Oscar ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Convenience lib vs static library
Sean Soria [EMAIL PROTECTED] writes: cmake claims to not support convenience libraries. Isn't building a static library and then linking it into other libraries the same as a convenience library? A convenience library works as an object file at link time: it is included on the final executable as any other object file. A static library does not have this quality: the linker picks the library's contents only if there is something elsewhere that requires it (i.e. a reference to a symbol defined on some object file contained on the library). -- Oscar ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to associate a command with a auto-generated target?
Hello, Alex.
Alexander Neundorf [EMAIL PROTECTED]
writes:
I wish to execute a command when the `clean' target is invoked. That is,
my command shall execute on addition of the normal target action.
Doesn't work, you have to do it the other way round: create a custom target
my-special-clean, do what you need, and also execute something like
${CMAKE_MAKE_COMMAND} directories etc clean
Sadly, this is not acceptable. People complain about having to learn
cmake and I want to avoid giving them a reason for complaining about
having to learn project-specific ways of doing standard things.
BTW, CMAKE_MAKE_COMMAND is not listed on --help-variables. You mean
CMAKE_BUILD_TOOL, don't you?
--
Oscar
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to associate a command with a auto-generated target?
Alexander Neundorf [EMAIL PROTECTED]
writes:
Doesn't work, you have to do it the other way round: create a custom
target my-special-clean, do what you need, and also execute something
like ${CMAKE_MAKE_COMMAND} directories etc clean
Sadly, this is not acceptable.
Setting the ADDITIONAL_CLEAN_FILES directory property is not powerful enough
for you ?
I guess you mean ADDITIONAL_MAKE_CLEAN_FILES. That was not what you
proposed on your previous message :-)
For this case, where a directory must be deleted together with all its
contents, it works.
Thank you, Alex.
--
Oscar
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Avoid nested cmake invocation taking parent's info.
While cross-compiling, I'm trying to avoid depending on previously built
executables, that is, the cross-compile build should create the native
utilities it needs. For this, I'm trying
execute_process(
COMMAND ${CMAKE_COMMAND} -DCMAKE_BUILD_TYPE=Release ${CMAKE_SOURCE_DIR}
WORKING_DIRECTORY ${CX_NATIVE_TG_DIR}
)
where CX_NATIVE_TG_DIR is a new directory where the native build is
performed. Later,
add_custom_command(OUTPUT ${LLVM_TABLEGEN}
COMMAND ${CMAKE_BUILD_TOOL} -C ${CX_NATIVE_TG_DIR}/utils/TableGen
COMMENT Building native TableGen...)
add_custom_target(NativeTableGen DEPENDS ${LLVM_TABLEGEN})
The problem is in execute_process. The cmake process created by it is
taking variable values from the enclosing cmake, so it uses the same
compiler, configure variables, etc.
How can this be avoided? I want the nested cmake to work as if the
enclosing cmake didn't existed.
--
Oscar
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] How to associate a command with a auto-generated target?
I wish to execute a command when the `clean' target is invoked. That is, my command shall execute on addition of the normal target action. -- Oscar ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Avoid nested cmake invocation taking parent's info.
Eric NOULARD [EMAIL PROTECTED]
writes:
The problem is in execute_process. The cmake process created by it is
taking variable values from the enclosing cmake, so it uses the same
compiler, configure variables, etc.
What do you mean by variables?
CMake one or
Environment one?
When cmake is invoked with -DCMAKE_TOOLCHAIN_FILE=foo, the nested cmake
runs as invoked with this definition as well. It takes config-assigned
variables from the parent cmake, too. For instance, while
cross-compiling from Linux to Windows/MinGW, the parent cmake correctly
sets HAVE_WINDOWS_H, but the child cmake sets it too, and so on.
[snip]
May be it would be possible to reset the cross-compile
setup using appropriate CMAKE_TOOLCHAIN_FILE?
Or you may reverse your scheme,
Always run a native build for building native tool
and make the native build invoke the Cross build using
EXECUTE_PROCESS(
COMMAND ${CMAKE_COMMAND} CMAKE_TOOLCHAIN_FILE=
...
)
Both suggestions seems good, but the idea is to lessen the burden on the
users and make things as simple as possible for them. Both methods
require specific instructions for this project that goes away from the
usual cmake practice and the work they save is negligible.
After some experimentation, using -UCMAKE_TOOLCHAIN_FILE on the
invocation of the nested cmake *sometimes* produces the right
thing. This sequence of commands does the trick:
work $ cmake -DCMAKE_TOOLCHAIN_FILE=mytoolchainfile path/to/source
# the above configures and generates the native build on the `native'
# subdirectory. The native build inherits the variables from the parent
# one.
work $ rm -R -f native/ # Delete the native build dir
# we re-execute cmake:
work $ cmake -DCMAKE_TOOLCHAIN_FILE=mytoolchainfile path/to/source
Now, the native build is correctly configured. On this last invocation
the configure phase for the cross-compile build is skipped, because it
is cached from the previous build. However, the native configure is
re-executed because we deleted it.
--
Oscar
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Knowing the name of the linker.
Hello. On some circunstances I need to explicitly invoke the linker, which happens to be `ld'. But this is no longer true when cross-compiling. How to know the name of the linker? I see cmake variables containing command lines for linking, but not the linker command name itself. -- Oscar ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Knowing the name of the linker.
Alexander Neundorf [EMAIL PROTECTED] writes: On some circunstances I need to explicitly invoke the linker, which happens to be `ld'. But this is no longer true when cross-compiling. How to know the name of the linker? I see cmake variables containing command lines for linking, but not the linker command name itself. Does CMAKE_LINKER have what you want ? Yes, thank you. It is not mentioned on --help-variables. I'm using 2.6.1. -- Oscar ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Omitted dependencies.
A project named Bar includes other source trees like this: add_subdirectory(../Foo) It seems that dependencies on Foo's header files are being ignored. When a header file in Foo's source tree is modified, C++ files on Bar that includes that header are not rebuilt. I'll like to investigate this. What's the file where cmake stores header file dependencies? Using 2.6.1 on Linux with Unix makefiles. -- Oscar ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Generated file and parallel build.
Hello, Brad.
Brad King [EMAIL PROTECTED] writes:
Óscar Fuentes wrote:
Several libraries depends on a generared header file. For enabling
parallel builds I need to state that dependency, and I do it with
set_source_files_properties. This happens inside a macro:
macro(add_llvm_library name)
if( LLVM_SOURCE_COMMON_DEPENDS )
set_source_files_properties( ${ARGN}
PROPERTIES OBJECT_DEPENDS ${LLVM_SOURCE_COMMON_DEPENDS}
)
endif( LLVM_SOURCE_COMMON_DEPENDS )
add_library( ${name} ${ARGN} )
where LLVM_SOURCE_COMMON_DEPENDS contains the name of the custom target
that is used to trigger the custom command that generates the file:
You're mixing up file-level dependencies with target-level dependencies.
The OBJECT_DEPENDS property only specifies file-level dependencies. I
see its documentation is lacking. I'll commit improved documentation
for it. The add_dependencies command is used to create extra
inter-target dependencies:
macro(add_llvm_library name)
add_library(${name} ${ARGN})
add_dependencies(${name} ${LLVM_SOURCE_COMMON_DEPENDS})
endmacro()
This doesn't work. The generation of the header file must be completed
before compiling the library's source files, and add_dependencies is not
for this. If my understanding is right, add_dependencies means that the
targets listed on LLVM_SOURCE_COMMON_DEPENDS must be built before
invoking `ar', but doesn't mean that the compilation of the library's
source files must be delayed until the targets listed on
add_dependencies are completed.
Just make sure the LLVM_SOURCE_COMMON_DEPENDS variable contains only
target names and not files.
add_custom_command(OUTPUT ${path_to_intrinsics_gen}
COMMAND tblgen -gen-intrinsic ... -o ${path_to_intrinsics_gen}
DEPENDS tblgen
COMMENT Building intrinsics.gen...)
add_custom_target(intrinsics_gen ALL
DEPENDS ${path_to_intrinsics_gen})
set(LLVM_SOURCE_COMMON_DEPENDS ${LLVM_SOURCE_COMMON_DEPENDS} intrinsics_gen )
This is correct.
--
Oscar
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Generated file and parallel build.
Óscar Fuentes [EMAIL PROTECTED] writes:
macro(add_llvm_library name)
add_library(${name} ${ARGN})
add_dependencies(${name} ${LLVM_SOURCE_COMMON_DEPENDS})
endmacro()
This doesn't work.
My wrong. This works.
--
Oscar
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Generated file and parallel build.
Several libraries depends on a generared header file. For enabling
parallel builds I need to state that dependency, and I do it with
set_source_files_properties. This happens inside a macro:
macro(add_llvm_library name)
if( LLVM_SOURCE_COMMON_DEPENDS )
set_source_files_properties( ${ARGN}
PROPERTIES OBJECT_DEPENDS ${LLVM_SOURCE_COMMON_DEPENDS}
)
endif( LLVM_SOURCE_COMMON_DEPENDS )
add_library( ${name} ${ARGN} )
where LLVM_SOURCE_COMMON_DEPENDS contains the name of the custom target
that is used to trigger the custom command that generates the file:
add_custom_command(OUTPUT ${path_to_intrinsics_gen}
COMMAND tblgen -gen-intrinsic ... -o ${path_to_intrinsics_gen}
DEPENDS tblgen
COMMENT Building intrinsics.gen...)
add_custom_target(intrinsics_gen ALL
DEPENDS ${path_to_intrinsics_gen})
set(LLVM_SOURCE_COMMON_DEPENDS ${LLVM_SOURCE_COMMON_DEPENDS} intrinsics_gen )
This doesn't work. The parallel build tries to compile the sources
that depends on intrinsics_gen before executing the custom command. I've
tried to use ${path_to_intrinsics_gen} (that is, the custom command
output) instead of intrinsics_gen, to no avail.
What I'm doing wrong?
CMake 2.6.1 -G Unix Makefiles.
--
Oscar
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [CMAKE]make uninstall
Micha Renner [EMAIL PROTECTED] writes: but what is with make uninstall? How can I uninstall my installation? http://www.cmake.org/Wiki/CMake_FAQ#Can_I_do_.22make_uninstall.22_with_CMake.3F -- Oscar ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMake erases targets at regeneration.
I'm observing something very strange with the MSYS Makefiles
generator: after some CMakeLists.txt file is altered, on the next 'make'
cmake is automatically invoked for regenerating the makefiles. Well,
after this is done, some target files are deleted. This is the macro
that creates the targets:
macro(add_partially_linked_object lib)
if( MSVC )
add_llvm_library( ${lib} ${ARGN})
else( MSVC )
set(pll ${CMAKE_ARCHIVE_OUTPUT_DIRECTORY}/${lib}.o)
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/temp_lib)
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/temp_lib)
add_library( ${lib}_tmp STATIC ${ARGN})
add_custom_command(OUTPUT ${pll}
MESSAGE Building ${lib}.o...
DEPENDS ${lib}_tmp
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/temp_lib
COMMAND echo ${lib}
COMMAND echo ${pll}
COMMAND ar x
${CMAKE_STATIC_LIBRARY_PREFIX}${lib}_tmp${CMAKE_STATIC_LIBRARY_SUFFIX}
COMMAND ld -r *${CMAKE_CXX_OUTPUT_EXTENSION} -o ${pll}
COMMAND rm -f *${CMAKE_CXX_OUTPUT_EXTENSION}
)
add_custom_target(${lib} ALL DEPENDS ${pll})
set( llvm_libs ${llvm_libs} ${pll} PARENT_SCOPE)
endif( MSVC )
endmacro(add_partially_linked_object lib)
where `add_llvm_library' is not relevant, as we are working with
MSYS/g++ (anyways, it is just a wrapper for add_library). The macro is
used as:
add_partially_linked_object(LLVMInterpreter
Execution.cpp
ExternalFunctions.cpp
Interpreter.cpp
)
and creates lib/LLVMInterpreter.o
There are three files that are created with this method. Two are deleted
after the regeneration and one not. This one depends on a custom target.
I can post the sources upon request.
The problem does not happen on Linux (Unix Makefiles).
--
Oscar
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re-executing CMake from the Makefile.
[Sorry for the late response. Supposedly, it is vacation here :-)]
Brad King [EMAIL PROTECTED] writes:
Óscar Fuentes wrote:
thinking on a two-phase build, something like this:
$ cmake -G Unix Makefiles # as llvm-config is not available, the
executables are ignored.
$ make # this builds the libs and llvm-config and stops.
$ make # This implicitly invokes cmake, which now can use llvm-config for
determining dependencies and build the executables.
It would be a good thing if the second `make' were not necessary.
You can do this in one build by splitting it into two projects in terms
of CMakeLists.txt file layout. [snip]
What I'm doing now is to invoke cmake from the command that builds the
script:
add_custom_command(OUTPUT ${LLVM_CONFIG}
COMMAND ... builds the script ...
COMMAND cd ${LLVM_BINARY_DIR}
${CMAKE_COMMAND} -U HAVE_LLVM_CONFIG ${LLVM_MAIN_SRC_DIR}
DEPENDS ...
)
where HAVE_LLVM_CONFIG is the variable that says if the script exists.
This works, at least on MSYS/MinGW, and it is simpler than splitting the
project.
I can provide more help if you need it.
This is very much appreciated, Brad. I have experience dealing with you
long time ago with gcc-xml and seeing your name related to CMake was one
of the main reasons for choosing it.
Thanks,
--
Oscar
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Building system triplet
How can I determine the system triplet with CMake (something like i686-pc-mingw32 or i686-pc-linux-gnu) -- Oscar ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re-executing CMake from the Makefile.
Bill Hoffman [EMAIL PROTECTED] writes: Óscar Fuentes wrote: Currently, when `make' is executed and a CMakeList.txt file is out of date, `cmake' is automatically invoked and then `make' continues. Is it possible to do this (on a reliable way) with an arbitrary file? I need to re-execute `cmake' whenever certain file changes. I wonder if is possible to do this from `make' itself, so the user does not need to remember that he must execute `cmake' first. If the file you depend on is part of the input to cmake then cmake will do that automatically. You could use the configure_file command to do this. If you did something like this: configure_file(/my/file/input dummyout) Then when ever /my/file/input changed cmake would re-run at make time. Will this work if /my/file/input is the output of some intermediate `make' execution? I mean: $ make # invoke make, which may modify /my/file/input at some point Will `make' invoke `cmake' on the fly and keep running with the new makefiles regenerated by `cmake'? If this is not possible, I would like to stop `make' when /my/file/output changes, possibly showing some message to the user instructing him to invoke `make' again. All this is because /my/file/input actually is an script that is used for determining which libraries the executables depends on. The current build system builds the libraries, then the script and finally the executables. As initially it is impossible for `cmake' to stablish dependencies between libraries and executables, I wish the build to stop or restart once the script is built and re-execute cmake so it can use the script for inquiring what the dependencies are, re-generate the makefiles and continue the build. -- Oscar ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re-executing CMake from the Makefile.
Bill Hoffman [EMAIL PROTECTED] writes: If this is not possible, I would like to stop `make' when /my/file/output changes, possibly showing some message to the user instructing him to invoke `make' again. You could just return an error code from the command that builds the /my/file/output, that should stop make from running. Okay. All this is because /my/file/input actually is an script that is used for determining which libraries the executables depends on. The current build system builds the libraries, then the script and finally the executables. As initially it is impossible for `cmake' to stablish dependencies between libraries and executables, I wish the build to stop or restart once the script is built and re-execute cmake so it can use the script for inquiring what the dependencies are, re-generate the makefiles and continue the build. Why does the script need to be constructed at make time? Seems like you could push a bit more of the work into the script itself and all should be good. The script examines library interdependencies dumping the symbol definitions and references they contain. For this, you need to build the libraries first. Later on the build, the executables just provide names of components, the script maps this names to actual libraries and returns the full list of needed libraries on the correct order for using it on the link command. If you know an elegant way to handle this with CMake, I'll like to hear it. BTW, this is for the Low Level Virtual Machine (LLVM) www.llvm.org Thanks, Bill. -- Oscar ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re-executing CMake from the Makefile.
Hello, Brad. Brad King [EMAIL PROTECTED] writes: Óscar Fuentes wrote: The script examines library interdependencies dumping the symbol definitions and references they contain. For this, you need to build the libraries first. Later on the build, the executables just provide names of components, the script maps this names to actual libraries and returns the full list of needed libraries on the correct order for using it on the link command. If you know an elegant way to handle this with CMake, I'll like to hear it. BTW, this is for the Low Level Virtual Machine (LLVM) www.llvm.org I assume you're refering to this script: http://llvm.org/svn/llvm-project/llvm/trunk/utils/GenLibDeps.pl This analyzes the dependencies. This is appended to llvm-config: http://llvm.org/svn/llvm-project/llvm/trunk/tools/llvm-config/llvm-config.in.in This script is executed within the link command (with shell backquotes) to obtain the libraries for certain set of components: $ llvm-config -libs jit native interpreter $ ./bin/llvm-config --libs jit native interpreter /d/dev/lib/llvm-git/mingw/lib/LLVMInterpreter.o /d/dev/lib/llvm-git/mingw/lib/LLVMX86.o -lLLVMLinker -lLLVMArchive /d/dev/lib/llvm-git/mingw/lib/LLVMJIT.o -lLLVMExecutionEngine -lLLVMipo -lLLVMSelectionDAG -lLLVMCodeGen -lLLVMScalarOpts -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMTarget -lLLVMBitReader -lLLVMVMCore -lLLVMSupport -lLLVMSystem It seems to rely on certain output from nm. Does this work with any windows compilers? No. Windows linkers (like MSVC's) are much simpler to handle. They are not sensitive to library specification order on the command line. Neither there is a need for partial linking. At least until shared libraries are supported on MSVC, just passing all libraries on the command line is enough. Inferring dependencies among already-built static libraries is not a design goal for CMake as it tries not to depend on any low-level details of native tools. However, given an explicit list of static libs and their *direct* dependencies, CMake will chain them automatically and handle the circular cases. It seems there are Unix linkers that can't handle circular cases. This is why some libraries are partially linked as object files. I think in the long run LLVM should just explicitly declare its dependencies. They can't be *that* complicated. LLVM is made of components. At configure time, you choose the components you want. This affects what libraries are built and how they depends one on another. It affects the libraries every executable depend on, too. The job of `llmv-config' is hiding all this complexity when you need to link an executable with the LLVM libraries. See below for output I got from building llvm. Would it really be so bad to list that by hand? It's 18 lines that could be distributed throughout each library's build files. The executables already list their direct dependencies explicitly. I'm afraid that listing library dependencies by hand would be seen as a unaceptable regression wrt the current build system. However, I'm thinking on a two-phase build, something like this: $ cmake -G Unix Makefiles # as llvm-config is not available, the executables are ignored. $ make # this builds the libs and llvm-config and stops. $ make # This implicitly invokes cmake, which now can use llvm-config for determining dependencies and build the executables. It would be a good thing if the second `make' were not necessary. Thanks for looking into this, Brad. -- Oscar ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
