Switch the order of your add_subdirectory calls. If your main depends on your library, then your add_subdirectory for the library should be first, and then the one for your main which depends on the first one.
HTH, David C. On Fri, Oct 3, 2014 at 3:55 AM, Jakub Zakrzewski <[email protected]> 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:[email protected]] On Behalf Of Bill Greene > Sent: Freitag, 3. Oktober 2014 01:58 > To: Michael Jackson > Cc: [email protected] > 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 > <[email protected]> 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 [email protected] > BlueQuartz Software www.bluequartz.net > Principal Software Engineer Dayton, Ohio > > > > On Thu, Oct 2, 2014 at 3:38 PM, Bill Greene <[email protected]> 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 > > > > > > > -- > > 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 -- 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
