On 16. Jul, 2009, at 15:26, Eric Noulard wrote:
2009/7/16 Michael Wild <[email protected]>:
May be there is some equivalent on Windows platform too
http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx
[just pointing the link, I'm really no windows expert and ....
don't want to become one :-) ]
Seriously, that platform is just plain broken if you ask me.
__declspec(dllimport), __declspec(dllexport)?! What were they
thinking?
Visibility control in shared libs may not be considered as evil,
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. 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.
Just my 2 cents.
And
DLL-exported C++ template instantiations with member templates
simply don't
work. Sometimes I marvel at why so many people go trough the pains of
writing software for such a broken system...
This is another story :-)
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
_______________________________________________
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
