[cmake-developers] [CMake 0013289]: In some cases, add_library(name OBJECT src ...) failure with unexpected warnings.
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13289 == Reported By:monaka Assigned To: == Project:CMake Issue ID: 13289 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-06-09 03:03 EDT Last Modified: 2012-06-09 03:03 EDT == Summary:In some cases, add_library(name OBJECT src ...) failure with unexpected warnings. Description: In case TARGET_SUPPORT_SHARED_LIBS is false, Calling add_library(... OBJECT ...) will get warnings below. ADD_LIBRARY for library foobar is used with the MODULE option, but the target platform supports only STATIC libraries. Building it STATIC instead. This may lead to problems. And type is forced to cmTarget::STATIC_LIBRARY. Actually adding object library will succeed even if its target isn't support shared libs. The current implementation is unsuitable, I think. == Issue History Date ModifiedUsername FieldChange == 2012-06-09 03:03 monaka New Issue == -- 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
On 09.06.2012 01:29, Óscar Fuentes wrote: Peter Kümmelsyntheti...@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. Many thanks for testing! I'm glad it mostly works. I assume the tablegen commands are some scripts and not compiler calls, maybe it can't find the generated one. Could you make a verbose run (-v) and post one rebuild? Peter -- 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
On 09.06.2012 03:28, Bill Hoffman wrote: fails in a new way: http://open.cdash.org/viewConfigure.php?buildid=2345213 FAILED: CMAKE_CMCLDEPS_EXECUTABLE-NOTFOUND testCXXCompiler.cxx CMakeFiles\cmTryCompileExec4166421573.dir\testCXXCompiler.cxx.obj.d CMakeFiles\cmTryCompileExec4166421573.dir\testCXXCompiler.cxx.obj Note: including file: C:\PROGRA~2\MICROS~1.0\VC\bin\cl.exe /nologo /DWIN32 /D_WINDOWS /W3 /Zm1000 /EHsc /GR /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 /TP /FoCMakeFiles\cmTryCompileExec4166421573.dir\testCXXCompiler.cxx.obj /FdcmTryCompileExec4166421573.pdb -c testCXXCompiler.cxx CreateProcess failed: The system cannot find the file specified. For testing your system is better than any build server ;) I did a FIND_PROGRAM for setting CMAKE_CMCLDEPS_EXECUTABLE, now cmake.exe in CMAKE_COMMAND is simply replaced by cmcldeps.exe. But it seems I have also to switch to a patch with spaces. Peter -- 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
On 09.06.2012 09:10, Peter Kümmel wrote: On 09.06.2012 01:29, Óscar Fuentes wrote: Peter Kümmelsyntheti...@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. Does clang has another build system which supports ninja? Then we could compare the generated files. Peter -- 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
Hi Peter,
I agree, we need your/our changes at upstream!
I will switch to our github:
https://github.com/syntheticpp/ninja
On little more about ninja bootstrap:
Original bootstrap.py generated target rule:
ninja -t clean
does a really distclean. The re2c generted files are removed too!
To be save, I added a rule to build/update them if needed:
#
set (RE2C_FOUND FALSE)
find_program (RE2C_EXECUTABLE re2c)
if (RE2C_EXECUTABLE)
set (RE2C_FOUND TRUE)
set (RE2C_FLAGS -b -i --no-generation-date)
# build src/depfile_parser.cc: re2c src/depfile_parser.in.cc
# build src/lexer.cc: re2c src/lexer.in.cc
foreach(_in depfile_parser.in.cc lexer.in.cc)
string(REGEX REPLACE .in.cc .cc _out ${_in})
message(STATUS Generate re2c src/${_in} -o src/${_out})
# CMake atrocity: if none of these OUTPUT files is used in a
target in
# the current CMakeLists.txt file, the ADD_CUSTOM_COMMAND is
plainly
# ignored and left out of the make files.
add_custom_command(OUTPUT ${srcdir}/${_out}
COMMAND ${RE2C_EXECUTABLE} ${${RE2C_FLAGS}} -o ${srcdir}/$
{_out} ${srcdir}/${_in}
DEPENDS ${srcdir}/${_in}
)
endforeach()
endif (RE2C_EXECUTABLE)
claus-kleins-macbook-pro:build clausklein$ ninja -d explain
ninja: no work to do.
claus-kleins-macbook-pro:build clausklein$ touch ../src/lexer.in.cc
claus-kleins-macbook-pro:build clausklein$ ninja -d explain
ninja explain: restat of output ../src/lexer.cc older than inputs
ninja explain: ../src/lexer.cc is dirty
ninja explain: ../src/lexer.cc is dirty
ninja explain: CMakeFiles/ninja_lib.dir/src/lexer.cc.o is dirty
ninja explain: libninja_lib.a is dirty
ninja explain: ninja is dirty
ninja explain: libninja_lib.a is dirty
[4/4] Linking CXX executable ninja
claus-kleins-macbook-pro:build clausklein$
//Regards
Claus
On 08.06.2012, at 23:13, Peter Kümmel wrote:
Will it merged later?
Can you please apply my time-stamp patch?
More interesting would be to bring it upstream.
P.S.
I tried to compile it with your CMakeLists.txt file, but it needs
love on linux (UNIX) build hosts.
Oh, yes, thanks. The last day I'm only on windows.
//Regards
Claus
--
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
On 09.06.2012 10:02, Claus Klein wrote:
Hi Peter,
I agree, we need your/our changes at upstream!
I will switch to our github:
https://github.com/syntheticpp/ninja
In times of git there is no our repository any more.
You could simply fork martine/ninja and push you changes
into your fork. Then, when you think something should go
upstream, create a merge request.
You could track multiple repositories by using git remote,
for instance in my cmake dir it looks like this:
$ git remote -v
origin git://cmake.org/cmake.git (fetch)
origin git://cmake.org/cmake.git (push)
pcc https://github.com/pcc/CMake.git (fetch)
pcc https://github.com/pcc/CMake.git (push)
polrop https://github.com/polrop/CMake.git (fetch)
polrop https://github.com/polrop/CMake.git (push)
stage g...@cmake.org:stage/cmake.git (fetch)
stage g...@cmake.org:stage/cmake.git (push)
steveires git://gitorious.org/~steveire/cmake/steveires-cmake.git (fetch)
steveires git://gitorious.org/~steveire/cmake/steveires-cmake.git (push)
syntheticpp g...@github.com:syntheticpp/CMake.git (fetch)
syntheticpp g...@github.com:syntheticpp/CMake.git (push)
On little more about ninja bootstrap:
Original bootstrap.py generated target rule:
ninja -t clean
does a really distclean. The re2c generted files are removed too!
Yes, you have to checkout again. When you don't have changes checkout -f
is the fasted way.
To be save, I added a rule to build/update them if needed:
Mostly I use my cmake file. Their python scripts are a bit sub-optimal.
#
set (RE2C_FOUND FALSE)
find_program (RE2C_EXECUTABLE re2c)
if (RE2C_EXECUTABLE)
set (RE2C_FOUND TRUE)
set (RE2C_FLAGS -b -i --no-generation-date)
# build src/depfile_parser.cc: re2c src/depfile_parser.in.cc
# build src/lexer.cc: re2c src/lexer.in.cc
foreach(_in depfile_parser.in.cc lexer.in.cc)
string(REGEX REPLACE .in.cc .cc _out ${_in})
message(STATUS Generate re2c src/${_in} -o src/${_out})
# CMake atrocity: if none of these OUTPUT files is used in a target in
# the current CMakeLists.txt file, the ADD_CUSTOM_COMMAND is plainly
# ignored and left out of the make files.
add_custom_command(OUTPUT ${srcdir}/${_out}
COMMAND ${RE2C_EXECUTABLE} ${${RE2C_FLAGS}} -o ${srcdir}/${_out}
${srcdir}/${_in}
DEPENDS ${srcdir}/${_in}
)
endforeach()
endif (RE2C_EXECUTABLE)
claus-kleins-macbook-pro:build clausklein$ ninja -d explain
ninja: no work to do.
claus-kleins-macbook-pro:build clausklein$ touch ../src/lexer.in.cc
claus-kleins-macbook-pro:build clausklein$ ninja -d explain
ninja explain: restat of output ../src/lexer.cc older than inputs
ninja explain: ../src/lexer.cc is dirty
ninja explain: ../src/lexer.cc is dirty
ninja explain: CMakeFiles/ninja_lib.dir/src/lexer.cc.o is dirty
ninja explain: libninja_lib.a is dirty
ninja explain: ninja is dirty
ninja explain: libninja_lib.a is dirty
[4/4] Linking CXX executable ninja
claus-kleins-macbook-pro:build clausklein$
//Regards
Claus
Nice, never tried -d explain.
Peter
--
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
On 09.06.2012, at 10:25, Peter Kümmel wrote: On 09.06.2012 10:02, Claus Klein wrote: Hi Peter, I agree, we need your/our changes at upstream! I will switch to our github: https://github.com/syntheticpp/ninja In times of git there is no our repository any more. Yes, I know, I meant your repo... (clone) You could simply fork martine/ninja and push you changes into your fork. Then, when you think something should go upstream, create a merge request. I work with git not so long, but its cool and I will do this! ;-) Thanks, Claus-- 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
