We drive the build of a library product using CMake, and generate binaries for the various platforms. generate_export_header() produces an export header file so that we can maintain control of symbol visibility across MSVC and GCC/Clang. So far so normal.
Our problem is that the export header file is tied to a specific compiler, and we want to distribute the headers, along with some wrapper source code, for customers, and actually doing that as a CMake Config package is currently not an option. (We do distribute the binaries with a Config package, but the export header file there has already been generated by the time that package is created.)
We’d like to distribute a single version of that header file which can be used whatever compiler you’re using.
Is there a way to do this without running CMake on Windows for MSVC, and running it on a GCC host and then manually combining the output?
I’ve been over the docs and it doesn’t seem obvious, but maybe other people have had the same problem and have a better solution…
Correct me if I am wrong, but if you are distributing the binaries, are they not different for each compiler anyway. So there should not be a problem to include an export header for each compiler together with each binary.
The remainder of the headers can probably be put into a general location. Your cmake config for the binaries can handle loading the correct version of the export for each.
If you are distributing the headers separately for some reason, so without binaries and without sources, and without cmake. Then theoretically the export header is mute. So you could just create an empty one that defines all the macros as empty.
For the rest, I must agree that I don’t see from the documentation any way to create a ‘universal’ header file from cmake. Building it once manually would be an option. Normally that header does not change, so it would be a one time job.
We are supplying the correct header with the binaries (so, per-compiler), it’s the wrapper-source-only release where we’d like it be universal. There are users who have a cross-compilation toolchain that uses those sources to build with MSVC and GCC and have a separate packaging solution for the binaries (they’re dlopen()ing them, so their packaging requirements are different anyway).
Unfortunately, we do need the export header - the macros it defines set symbol visibility for the wrappers which are being compiled into a shared library to be dlopen()ed.
It’s all a little messy, but good to have confirmation I don’t need to keep wasting time poking at generate_export_header(). A manual process is probably it for the short term…