gendef and building mico in Windows

[Felipe Magno de Almeida]

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]

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

Post by Felipe Magno de Almeida
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]

Hi,

Post by Karel Gardas
Hi,
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

Because I have to run gendef on files and use the result with the
def-file, but I must only do this when building a shared library on
windows. This is hardly a easy process.
Also, I'm having problems with gendef exporting too much, including
inline symbols and the resulting DLL doesn't work for some reason.
(msvc-9.0)

That's strange. I don't know about any such issue on current sources.
Could you be so kind and test with the latest, i.e.
http://www.mico.org/snapshots/mico-100813.tar.bz2 snapshot? Also please
use this as a basis for your hacking! This way any merge in the future
is much more easier...

Post by Karel Gardas
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.

The version I'm working (2.3.12), the headers produced from idl files that
are part of the bootstrap process* that are distributed already processed by
the idl compiler do not use dllexport.
So we have a problem where building the idl compiler requires these headers,
but re-creating these files with appropriate dllexport requires the
idl compiler.
Also, for me, some member-functions are not prepended with MICO_EXPORT.
For example _narrow functions.

Again, please recheck with the latest snapshot.

Post by Karel Gardas
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.

I have read about gcc. I do know there are some syntactic differences
between gcc visibility support and msvc declspec, IIRC. But I'm not
yet sure what they are.

Post by Karel Gardas
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.

You mean you don't intent to use -fvisibility-hidden by default. This
is a good choice, since it is common on Unix to export all symbols.
And if the user is educated enough to want -fvisibility-hidden because
of its position-independent optimizations and smaller footprint he can
look the option up and use it.

Yes, certainly this will be in the first release after the support is
merged in. The another one will have this feature enabled by default on
platforms supporting it especially if it is that beneficial as one can
read about it. I'm just asking that you consider this Unix support and
keep at least functionality of GNU C++ and Sun C++ in mind while working
on Windows support. So if possible please provide generic solution
rather than platform specific, at least that's what highly appreciated here.

Thanks,
Karel