[CMake] How can I compile and link modular code into a single DLL with MSVC?

Jason Heeris jason.heeris at gmail.com
Wed Jun 27 18:18:55 EDT 2018


On Thu, 28 Jun 2018 at 04:16, Innokentiy Alaytsev <alaitsev at gmail.com>
wrote:
> I don't quite understand why are you using object libraries all over the
project.

Mainly because I tried a lot of things, and with the release of 3.12 I
figured I'd try object libs again.

> If those modules are not intended to be used outside of the final shader
library, then why not to make them static libraries?

I thought I'd previously tried that with no success, but I tried it just
now and it seemed to work! (Maybe I did try it, but on an older version
where things worked a bit differently. Or maybe I got confused because the
build info never shows module3 being linked to the other sources or
libraries. They ARE listed as references in the generated VS project of
course.)

I'll test it on the real thing and see how that goes. The only problem I
encountered was that the final shared library complains about having "NO
SOURCES given to target: module3_dll". I can add "module3.c" as a source,
even though technically the static lib should already contain everything
from there. I'm not sure why that's an issue though.

In the real project *any* module can be a top level module, so each module
will need multiple targets: the static library (so other dependant modules
can link against it) and the shared library (for building it as a top level
thing); there's also Mex (Matlab) and other Linux-specific targets. But I
think that's easily managed by storing common info (ie. direct
dependencies) in a variable and maybe writing a function to produce the
targets in a structured way.

> Also, I have an important note about the structure of the project: It may
be better to have all the dependencies defined before they are used, i.e.
you should not be able to use the target_link_libraries() with an undefined
target as a linked library.

I have no idea how I'd achieve this though, with so many subdirectories. I
think CMake is perfectly happy to resolve these links at generate time
rather than as the configuration is parsed though?

Cheers,
Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180628/7d91631e/attachment.html>


More information about the CMake mailing list