[CMake] Fake dependencies of executables to static libs

[Shoaib Meenai]

Could you share more details about your CMake version, the platform you're on, and the generator you're using?

I haven't run into this issue (and it's pretty counter to how I'd expect CMake to behave). The only similar setting I'm aware of is https://cmake.org/cmake/help/latest/prop_tgt/LINK_DEPENDS_NO_SHARED.html, but that's for shared libraries, not static libraries.

As an experiment, I used the following CMakeLists.txt:

cmake_minimum_required(VERSION 3.4.3)
project(cmtest C)
add_library(mylib STATIC source.c)
add_executable(mytest test.c)
target_link_libraries(mytest mylib)

I'm running CMake 3.12.3 on macOS 10.14.1, and I tried both the Makefile and Ninja generators. With both, any modification to source.c causes mytest to be rebuilt, as I'd expect (and unlike what you're seeing).

If you're able to provide a small self-contained CMakeLists.txt that reproduces the issue, that'd also be helpful for debugging.

Thanks,
Shoaib Meenai

From: CMake <cmake-bounces at cmake.org> on behalf of Stephan Menzel <stephan.menzel at gmail.com>
Date: Wednesday, April 3, 2019 at 10:56 PM
To: cmake <cmake at cmake.org>
Subject: Re: [CMake] Fake dependencies of executables to static libs

Hello again,

no ideas so far? Perhaps I can elaborate. I have tried multiple approaches over the years. Most recently adding the source files of the lib explicitly as dependencies to the created executable.

Like this:

set (SRC
MySource1.cpp
MySource2.cpp
)

set (HDR
MySource1.hpp
MySource2.hpp
)

add_library(mylib STATIC ${SRC} ${HDR})

add_executable(myexecutable main.cpp)
target_link_libraries(myexecutable
mylib
)

add_dependencies(myexecutable ${SRC})

This leads to errors though:

CMake Error at CMakeLists.txt:79 (add_dependencies):
  The dependency target "MySource1.cpp" of target "myexecutable" does not exist.

Obviously, I cannot simply state a filename and treat it as a target. I have however seen something similar been done when it comes to code generation. I have also seen explicit subtargets for files being created and then depend on those subtargets. But I don't really know how to do this the right way.

Alternatively I would also appreciate input about what exactly the problem with depending on static libs is. The explanations I remember from my last efforts to tackle this weren't really satisfying. If I understood in more detail why this isn't possible I may be able to better craft a workaround on my own.

Really, anything helps. I am losing time and nerve every day because of this and have been paying this price for so many years that I think it really is time to come up with a solution.

Cheers,
Stephan






On Tue, Apr 2, 2019 at 5:54 AM Stephan Menzel <stephan.menzel at gmail.com<mailto:stephan.menzel at gmail.com>> wrote:
Hello List,

In our projects we are using static linkage on Windows (MSVC) and Linux. A number of static libs are created and then linked into executables, such as unit tests, tools and the actual production artifacts. Very normal stuff.

add_library(mylib STATIC mysources)
add_excecutable(mytest mytest.cpp)
target_link_libraries(mytest mylib)

Now although I don't understand the exact reasons behind that, over the years came to accept that depedencies between the lib and the resulting artifcats are not working. Like, when I change a source file to mylib, the lib will get rebuilt but the resulting test tool won't be relinked.
For test driven development or busy change cycles that can put quite a strain on effort, especially on windows. My normal workflow is that I always click in mytest.cpp, add and remove a space to mark it dirty as quickly as possible and thereby cause the rebuild. But sometimes I forget this and this caused me quite a bit of extra work.
My question is, can I fake that dependency somehow? Perhaps by some hack or using some workaround?

What I want to achieve is that when I change the lib, the unit test (or any other test tool using it) that depends on it will be relinked, even if it has not changed.

Is that possible somehow?

Cheers,
Stephan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190404/88f7c9db/attachment-0001.html>