[CMake] Main program not getting rebuilt when library changes.

Bill Greene w.h.greene at gmail.com
Fri Oct 3 09:07:32 EDT 2014


Thanks for the link and the suggestions. I read through the posting several
times to try to understand the
issues.

I added these lines:

SET_SOURCE_FILES_PROPERTIES(
    cmTestMain.cpp PROPERTIES OBJECT_DEPENDS
    ${CMAKE_BINARY_DIR}/cmTestLib/Debug/cmTestLib.lib
)

to the CMakeLists.txt for the main program. (I checked to make sure the
path to the library
is correct). Unfortunately, this didn't fix the build problem.

As I mentioned in my original post, it looks to me like the VS solution
generate by cmake *should*
be doing the right thing but there is some VS subtlety that is coming into
play here ;-(


On Fri, Oct 3, 2014 at 3:55 AM, Jakub Zakrzewski <jzakrzewski at e2e.ch> wrote:

>  Hi,
>
>
>
> if I'm not mistaken, the build system only tracks source dependencies, so
> unless the changed code is shared by both library and main, it'll not
> rebuild the main.
>
>
>
> One solution could be:
>
>
>
> SET_SOURCE_FILES_PROPERTIES(
>
>     cmTestMain.cpp PROPERTIES OBJECT_DEPENDS
>
>     ${CMAKE_CURRENT_BINARY_DIR}/cmTestLib/libcmTestLib.a
>
> )
>
>
>
> As described here:
> http://www.cmake.org/pipermail/cmake/2010-November/041049.html
>
> (I might have used wrongpaths but you get the idea)
>
>
>
>
>
> --
>
> Gruesse,
>
> Jakub
>
>
>
>
>
>
>
> *From:* CMake [mailto:cmake-bounces at cmake.org] *On Behalf Of *Bill Greene
> *Sent:* Freitag, 3. Oktober 2014 01:58
> *To:* Michael Jackson
> *Cc:* cmake at cmake.org
> *Subject:* Re: [CMake] Main program not getting rebuilt when library
> changes.
>
>
>
> I replaced the CMakeLists.txt for the library (cmTestLib) with simply this:
>
>
>
> add_library (cmTestLib STATIC MySub.cpp MySub.h)
>
>
>
> And I see exactly the same problem with the main program not getting
> rebuilt.
>
> So I believe the GLOB issue is irrelevant to this particular problem.
>
>
>
> Bill
>
>
>
> On Thu, Oct 2, 2014 at 6:55 PM, Michael Jackson <
> mike.jackson at bluequartz.net> wrote:
>
> This probably is not completely your issue but I am sure it has something
> to do with it. From the help for the "FILE" command:
>
>
>
> GLOB will generate a list of all files that match the globbing
>
> expressions and store it into the variable.  Globbing expressions are
>
> similar to regular expressions, but much simpler.  If RELATIVE flag is
>
> specified for an expression, the results will be returned as a
>
> relative path to the given path.  (We do not recommend using GLOB to
>
> collect a list of source files from your source tree.  If no
>
> CMakeLists.txt file changes when a source is added or removed then the
>
> generated build system cannot know when to ask CMake to regenerate.)
>
>
>
> Take away: Do NOT use GLOB to find source files. List them out one by one
> in the CMake file.
>
>
>
> Try that and let us know if it works as you would expect it to.
>
>
>
> Mike Jackson
>
>
>  _________________________________________________________
> Mike Jackson                  mike.jackson at bluequartz.net
> BlueQuartz Software                    www.bluequartz.net
> Principal Software Engineer                  Dayton, Ohio
>
>
>
> On Thu, Oct 2, 2014 at 3:38 PM, Bill Greene <w.h.greene at gmail.com> wrote:
>
>   Hi,
>
>
>
> I'm trying to build a trivial project with cmake 3.0 and Visual Studio
> 2013.
>
> The project has a top-level directory, a sub-directory with the main
> program,
>
> and a sub-directory that builds a static library that the main program
> depends on.
>
> It all builds fine the first time. Then I change a routine in the library
> and rebuild.
>
> The static library gets rebuilt but the main program does not get
> re-linked.
>
>
>
> I have perused the cmake-built VS project for hours and it looks fine to
> me; the
>
> main program depends on the library as expected. I can't figure out why
> the main
>
> program is not being rebuilt.
>
>
>
> More embarrassing, I can easily build a similar VS project by hand that
> behaves as
>
> expected but I can' find the significant difference between the two that
> is causing the
>
> problematic behavior.
>
>
>
> If anyone has any insights on this I would be very appreciative.
>
>
>
> Here are my three CMakeLists.txt files:
>
>
>
> top level:
>
> -----------
>
> cmake_minimum_required (VERSION 2.8)
>
> project(cmTest)
>
> add_subdirectory (cmTestMain)
>
> add_subdirectory (cmTestLib)
>
>
>
> cmTestLib
>
> --------------
>
> FILE(GLOB SRC *.cpp)
>
> FILE(GLOB H_FILES *.h)
>
> add_library (cmTestLib STATIC ${SRC} ${H_FILES})
>
>
>
> cmTestMain
>
> ----------------
>
> include_directories (${cmTest_SOURCE_DIR}/cmTestLib)
>
> add_executable (cmTestMain cmTestMain.cpp)
>
> target_link_libraries (cmTestMain cmTestLib)
>
>
>
> Thanks.
>
>
>
> Bill
>
>
>
> --
>
> 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://public.kitware.com/mailman/listinfo/cmake
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141003/0e95fd33/attachment-0001.html>


More information about the CMake mailing list