[CMake] Main program not getting rebuilt when library changes.
Bill Greene
w.h.greene at gmail.com
Sat Oct 4 11:34:11 EDT 2014
I believe I may have stumbled on a work-around for this problem.
I simply added these two lines to the top-level CMakeLists.txt:
SET(LIBRARY_OUTPUT_PATH ${PROJECT_BINARY_DIR})
SET(EXECUTABLE_OUTPUT_PATH ${PROJECT_BINARY_DIR})
They obviously tell cmake to generate a VS solution that puts the
exe files and libs in the same directory. This is what happens when
you manually create a solution in Visual Studio and (apparently)
changes the way VS deals with dependencies between exe projects and
the lib projects they depend on.
I haven't experimented with more complex projects but, at least, it
fixes this simple case.
Bill
On Fri, Oct 3, 2014 at 9:07 AM, Bill Greene <w.h.greene at gmail.com> wrote:
> 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/20141004/d4b4c839/attachment.html>
More information about the CMake
mailing list