Hi, there are two things to discuss here:
1) I don't understand why using gendef makes maintenance of your Jamfile harder and preserve a needs for manual patching of it in the future 2) dllexport/dllimport support is interesting question. In the past I was strongly against this. The reason was that it cluttered source code with proprietary tags supported only on one OS. Now, the situation changed a lot, since we do have visibility symbols support available also in GNU C++ and also in some commercial Unix compilers (Sun C++ for example), so I'm slightly inclined to put a green flag for this effort. The only requirement is that for non-Windows we strongly requires building in a way all visibility support is disabled and all symbols from DSO are exported like they are now. Also please note that we do have already support for this done for IDL compiler produced C++ files, so you will just need to tweak hand-written files. I would also like to ask you if you read carefully something about GNU C++[1] and Sun C++[2] visibility support in order to make this feature as platform independent as possible while doing as smallest change in the source code as possible. On Unix I plan to keep this support disabled by default and either enable it with configure option (e.g. --enable-visibility) or enable it automatically when C++ compiler supports it. Anyway, please note that this is strongly MICO 2.3.15 material as I wouldn't like to destabilize source tree with this just before 2.3.14 release (which I plan to do probably at the end of this or next month) Thanks, Karel [1]: http://gcc.gnu.org/wiki/Visibility [2]: http://developers.sun.com/solaris/articles/symbol_scope.html On 08/02/10 19:39, Felipe Magno de Almeida wrote: > Hi, > > I'm writing a boost.build v2 Jamfile for building mico so that I integrate > mico > better in my build system. > I'm hitting a problem that mico needs to run gendef to generate a .def file > for > building mico as a DLL with msvc. > I would like to propose modifying mico and sending patches that allow building > mico as DLL with msvc using macros that define __declspec(dllexport/dllimport) > when appropriate. That should probably easier building mico as DLL and static > library in Windows with the current build system as well. > I would like to know if there's any interest in this patches for mico. > That would > easier maintenance for my Jamfile in the long run as well, since newer > versions > wouldn't have to be patched manually. > > Regards, -- Karel Gardas kgar...@objectsecurity.com ObjectSecurity Ltd. http://www.objectsecurity.com ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm _______________________________________________ Mico-devel mailing list Mico-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mico-devel
