Hi Simon,
> How about this module? I use something similar in many of my projects.
> For an example of when a *.def file is useful, see "Using the GnuTLS DLL
> from your Visual Studio program" on <http://josefsson.org/gnutls4win/>.
Again, I advocate for a module name that makes people understand when the
module is useful for them. 99% of the developers have never heard of the
ld option --output-def, therefore naming the module 'ld-output-def' will
not ring a bell.
I proposed to rename
ld-version-script -> symbol-versions or lib-symbol-versions
and
visibility -> symbol-visibility or lib-symbol-visibility
The purpose of this module here is to be compatible with Microsoft's
Visual C++ compilers, as I understand. So I how about calling this module
'lib-msvc-compat' ?
> ... used to generate DEF files,
> +which can be useful for Windows users when they want to generate an
> +import library for your DLL.
"can be useful"? Not always useful? It seems there are three ways to
deal with these .def files:
1) Let the distributor of the DLL ship a .def file; this is what you
are advocating.
2) Let the user create the .def file, using the Microsoft DUMPBIN
tool [1].
3) Let the user create the .def file, using the 'impdef' tool. [2]
How do the approaches compare? I've been providing MSVC or mingw
support in GNU libiconv for 8 or 9 years now, and no one asked me for
a .def file. I have to conclude that the users were using approach
2) or 3).
Bruno
[1] http://support.microsoft.com/kb/131313/en-us
[2] http://sei.pku.edu.cn/~caodg/course/c/reference/win32/tools/dlltool.html
