On 16. Jul, 2009, at 15:46, Eric Noulard wrote:
2009/7/16 Michael Wild <[email protected]>:
GCC even supports that feature:
http://gcc.gnu.org/wiki/Visibility
in particular you may read "2.2 Export Control" in
http://people.redhat.com/drepper/dsohowto.pdf
I don't say that this is evil. I only say that REQUIRING it is
really bad.
OK I missed that point.
It breaks perfectly valid, standard-compliant code... Now, if the
MSVC
compiler offered an option to export all symbols by default (as
mingw-gcc
does), it would be a different story. But introducing stuff like
#ifdef SUPERLIB_EXPORTS
# define SUPERLIB_API __declspec(dllexport)
#else
# define SUPERLIB_API __declspec(dllimport)
#endif
into a code with roughly 5000 source files (many of which contain
complicated templates, so figuring out where to actually put these
SUPERLIB_API things is not trivial), from which 60 DLL's should be
built, is
just very painful.
OK and I do fully agree with.
I did this for porting a C++ code on WIn32 and it was painfull even
for far less files and DLL.
Note that theoretically you may specify the export/import rules in a
separate .def file
http://msdn.microsoft.com/en-us/library/28d6s79h(VS.71).aspx
http://msdn.microsoft.com/en-us/library/d91k01sh(VS.80).aspx
However I did not have enoough time to do it this way so I did
go for the #ifdef etc...
Actually, I'm planning on doing this with the .def files. But then,
maintaining them might also become a nightmare.
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
