[CMake] GenerateExportHeader macrr for CMake?

Marcus D. Hanwell marcus.hanwell at kitware.com
Sun Jun 5 18:30:46 EDT 2011


On Sun, Jun 5, 2011 at 3:47 PM, Alexander Neundorf
<a.neundorf-work at gmx.net> wrote:
> On Sunday, June 05, 2011 08:43:02 PM Hendrik Sattler wrote:
>> Am Sonntag, 5. Juni 2011, 18:16:03 schrieb Michael Wild:
>> > On 06/05/2011 05:34 PM, Hendrik Sattler wrote:
>> > > Am Sonntag, 5. Juni 2011, 11:45:20 schrieb Stephen Kelly:
>> > >> Hendrik Sattler wrote:
>> > >>> Really why? There is no dynamic content in such a header file.
>> > >>
>> > >> I'm not sure what you mean? Could you be more specific?
>> > >
>> > > This header file only contains static content. You don't even one
>> > > definition per library, it's the same for each anyway. I find it
>> > > strange to create a file that will always contain the same content.
>> > > The difference of MSVC vs. gcc4 can be fully handled in the export
>> > > header file. So why do you need CMake for that?
>> > >
>> > > HS
>> >
>> > That's not quite true. Each library will have it's own (hopefully
>> > unique) XXX_EXPORTS define (the DEFINE_SYMBOL property), otherwise the
>> > whole thing won't work.
>>
>> You mean something like:
>> #ifdef FOO_EXPORTS
>> #include "export.h"
>> #define FOO_DLLEXPORT DLLEXPORT
>> #endif
>>
>> This still makes export.h very static content. As I said in the old thread,
>> CMake is a build system, not a code-generator.
>
> Well, one could also say that cmake is a tool to make building software easy
> :-)
> In that sense it is useful to put stuff which you more or less always need
> when you build a library into cmake.
>
That was my line of thinking too. This seems like something I do for
virtually every project I work on that wants to generate libraries. It
would provide for a standard way of doing it, but certainly would not
preclude projects from doing their own thing if preferred.

Marcus


More information about the CMake mailing list