[cmake-developers] [CMake 0014646]: Test for TARGET return TRUE if it exists rather than if it has been built or imported.
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=14646
==
Reported By:hobbes1069
Assigned To:
==
Project:CMake
Issue ID: 14646
Category: CMake
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2013-12-12 23:29 EST
Last Modified: 2013-12-12 23:29 EST
==
Summary:Test for TARGET return TRUE if it exists rather than
if it has been built or imported.
Description:
I believe this is a regression from 2.8.11. I had this working although there
have been changes to the cmake configuration so it's impossible to be sure.
I have a project that uses wxWidgets. Because wxWidgets uses a custom script to
generate linker and include flags it must be built before my project can even be
configured. I worked around this by adding a bootstrap option that will download
and build static libraries of wxWidgets, then cmake/make is run again after the
needed configuration script is available.
Ever since updating to 2.8.12 (currently 2.8.12.1), cmake skips the
configuration and build of wxWidgets.
Additional Information:
Here is a summarized version of the logic in my cmake configuration but also
includes some debug info I added to verify the problem:
if(BOOTSTRAP_WXWIDGETS)
message(STATUS "Adding wxWidgets build target...")
include(cmake/BuildWxWidgets.cmake)
if(TARGET wxWidgets)
message(STATUS "wxWidgets target exists.")
endif()
endif(BOOTSTRAP_WXWIDGETS)
The externalproject target is added in BuildWxWidgets.cmake. Per the
documentation "if(TARGET wxWidgets)" should only test TRUE once the target is
built but the cmake output includes output indicating it's testing TRUE once the
target is added.
For reference, here is the contents of BuildWxWidgets.cmake:
set(WXWIDGETS_TARBALL "wxWidgets-2.9.4")
include(ExternalProject)
ExternalProject_Add(wxWidgets
URL http://downloads.sourceforge.net/wxwindows/${WXWIDGETS_TARBALL}.tar.bz2
BUILD_IN_SOURCE 1
INSTALL_DIR external/dist
CONFIGURE_COMMAND ./configure --disable-shared
--prefix=${CMAKE_BINARY_DIR}/external/dist
BUILD_COMMAND $(MAKE)
INSTALL_COMMAND $(MAKE) install
)
set(WXCONFIG "${CMAKE_BINARY_DIR}/external/dist/bin/wx-config")
set(WXRC "${CMAKE_BINARY_DIR}/external/dist/bin/wxrc")
==
Issue History
Date ModifiedUsername FieldChange
==
2013-12-12 23:29 hobbes1069 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
[cmake-developers] define_property deprecated? (was: CMakeParseArguments: Do not skip empty arguments)
On 2013-12-03 11:59, Brad King wrote: I'd like to avoid new uses of define_property if possible. It is a legacy from the old builtin documentation system. Sorry to go off on a tangent, but this triggered a question in my mind... I have a wrapping utility file that declares some (CMake) helper functions/macros to automatically generate Python bindings for a C++ library. There is some dependency logic that uses custom target properties under the hood. Right now I am using define_property to declare those. Should I (can I) not do that? Loosely related: is there a way to make export() and install(EXPORT) set these properties for exported targets? -- Matthew -- 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 build does too much work
On Thu, Dec 12, 2013 at 11:46:24 -0500, Matthew Woehlke wrote: > Actually... back up for a moment. Since we're talking about dynamic > libraries here (none of this applies to static I think; in that case > you must always relink), how would a non-ABI change in liba.so cause > the result of linking to be different? I didn't think dynamic linking > involved *copying* symbols from liba into libb? True. Thinking about it more, I do agree with Bill that pretty much any intentional ABI change is going to have something in a header change in common code; you could certainly *try* and break this pretty easily by removing implementations of functions or template specializations, creating symbol collisions, and probably more. However, these sound like errors that would occur anyways with fairly explicit errors at runtime (maybe not duplicate symbols). What I'm worried about are problems where a link would have resolved it, but it's some weird, subtle, error at runtime. Also, how would this interact with link-time optimization? I don't seem much on how (if at all) LTO works with shared linking, but there do seem to be bugs[1][2]. --Ben [1]http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200 [2]http://stackoverflow.com/questions/19593919/lto-and-virtual-destructor-weirdness-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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake build does too much work
On 12/12/2013 11:46 AM, Matthew Woehlke wrote: Where template.hpp changes (testing with 2.8.12.1 shows that touching template.hpp triggers a rebuild with Ninja, but not Unix Makefiles), That sounds like a bug :-). Yes, this is a bug. ninja and make should be the same. -- 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 build does too much work
On 2013-12-11 20:00, Ben Boeckel wrote: On Wed, Dec 11, 2013 at 19:38:21 -0500, Matthew Woehlke wrote: I don't think this is relevant? In these cases, a header is changing, which will (hopefully) lead to the source files using that header being rebuilt, which will cause the library to relink anyway. (And if the sources *aren't* rebuilt, I don't think relinking will help?) I'm concerned about this: (external) (internal) template.hpp <-- A.cpp --> header.h ^^ || |\- liba.so | ^ | | \-- B.cpp <-- libb.so Where template.hpp changes (testing with 2.8.12.1 shows that touching template.hpp triggers a rebuild with Ninja, but not Unix Makefiles), That sounds like a bug :-). internal_header.h changes and A.cpp gets recompiled, liba.so relinked and libb.so skipped because the ABI hasn't changed. The problem is that if something inlined from template.hpp is incompatible with what B.cpp has inlined, things need recompiled. Yes. What I am missing is how re*linking* libb.so would help here? Don't you need to re*compile* B.o for this case? Actually... back up for a moment. Since we're talking about dynamic libraries here (none of this applies to static I think; in that case you must always relink), how would a non-ABI change in liba.so cause the result of linking to be different? I didn't think dynamic linking involved *copying* symbols from liba into libb? What am I missing? -- Matthew -- 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] [CMake 0014645]: exec_program and execute_process don't capture output when it does not end in a newline
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14645 == Reported By:Nathan Climer Assigned To: == Project:CMake Issue ID: 14645 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-12-12 11:46 EST Last Modified: 2013-12-12 11:46 EST == Summary:exec_program and execute_process don't capture output when it does not end in a newline Description: When trying to capture output of a process, if the stream does not end in a new line, these commands cannot capture the output. Steps to Reproduce: The following batch script shows the problem nicely MESSAGE(STATUS "Outputting captured newline") EXEC_PROGRAM(printf ARGS "\"output is shown\\n\"") MESSAGE(STATUS "Outputting without newline") EXEC_PROGRAM(printf ARGS "\"output is not shown\"") == Issue History Date ModifiedUsername FieldChange == 2013-12-12 11:46 Nathan Climer 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
[cmake-developers] [CMake 0014644]: FindJPEG.cmake doesn't honour JPEG_ROOT_DIR
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14644 == Reported By:Marcel Metz Assigned To: == Project:CMake Issue ID: 14644 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-12-12 13:24 CET Last Modified: 2013-12-12 13:24 CET == Summary:FindJPEG.cmake doesn't honour JPEG_ROOT_DIR Description: According to Modules/readme.txt Find* modules should honour the Xxx_ROOT_DIR variable to locate separate installations of a library. However the FindJPEG modules doesn't use such a variable or a suitable alternative. Therefor it is impossible to select a jpeg library that isn't installed in a well known directory. == Issue History Date ModifiedUsername FieldChange == 2013-12-12 13:24 Marcel MetzNew Issue 2013-12-12 13:24 Marcel MetzFile Added: FindJPEG.cmake.patch == -- 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 build does too much work
Ben Boeckel wrote: > On Thu, Dec 12, 2013 at 00:00:42 +0100, Stephen Kelly wrote: >> You opposed a sensible default for CMAKE_LINK_DEPENDS_NO_SHARED: >> >> https://www.mail-archive.com/cmake-developers@cmake.org/msg06169.html >> >> I continue to consider the default value of that to be a mistake. > > How would a relink be forced with the default of "ON" when the ABI does > break? Would I need to invoke the targets manually? That sounds painful > to me. I'm not certain you read the whole thread. If you did, please be more specific. Thanks, Steve. -- 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
