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... -- 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
