Re: [CMake] GenerateExportHeader macrr for CMake?
Am Samstag, 4. Juni 2011, 21:17:49 schrieb Stephen Kelly: Hi, I came up with an idea to simplify the creation of export headers for hidden visibility by using configure_file. After implementing it I saw that the idea has come up before :) http://www.mail-archive.com/cmake@cmake.org/msg27058.html Please see the attached proof of concept. Could we get something like GenerateExportHeader.cmake and exportheader.cmake.in into CMake 2.8? Alex tells me I'd have to maintain it, respond to bugs, and keep source compatibility, so I guess I can say I'll do that :). I know there are other special cases for other compilers, but I thought I'd put the implementation of the concrete idea here for discussion at this point. Really why? There is _no_ dynamic content in such a header file. HS ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] GenerateExportHeader macrr for CMake?
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? ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] GenerateExportHeader macrr for CMake?
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 ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] GenerateExportHeader macrr for CMake?
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. Michael ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] GenerateExportHeader macrr for CMake?
On Sat, Jun 4, 2011 at 3:17 PM, Stephen Kelly steve...@gmail.com wrote: Hi, I came up with an idea to simplify the creation of export headers for hidden visibility by using configure_file. After implementing it I saw that the idea has come up before :) http://www.mail-archive.com/cmake@cmake.org/msg27058.html Please see the attached proof of concept. Could we get something like GenerateExportHeader.cmake and exportheader.cmake.in into CMake 2.8? Alex tells me I'd have to maintain it, respond to bugs, and keep source compatibility, so I guess I can say I'll do that :). I have been working on similar functionality in the Titan project, and wrote some abstraction for VTK's handling of symbol import/export logic. As we modularize VTK we will be doing what Titan has now been doing for quite some time. http://www.vtk.org/gitweb?p=VTK.git;a=blob;f=Common/vtkABI.h From reading the documentation, even though GCC 4.0 didn't necessarily do the right thing it does know about the visibility attribute. I know there are other special cases for other compilers, but I thought I'd put the implementation of the concrete idea here for discussion at this point. I think this is a great idea, and something that would be good to provide some utility functionality around. Marcus ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] GenerateExportHeader macrr for CMake?
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. If you can do something without CMake easily, why should you use CMake in a more complicated way to do the same thing? HS ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] GenerateExportHeader macrr for CMake?
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. Alex ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] GenerateExportHeader macrr for CMake?
On Sun, Jun 5, 2011 at 3:47 PM, Alexander Neundorf a.neundorf-w...@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 ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
