Daniel Stenberg wrote:

> On Mon, 1 Nov 2004, Russ Freeman wrote:
>
>> Maybe so...but I thought def files are compiler/vendor indendent
>
>
> It is? That would of course be a big reason to keep it.

I at least "thought" they were.

>
>> easy to maintain - but the declspec directive is not.
>
>
> I beg to differ. The .def file has been lagging behind numerous times
> because of the fact that it is a list of functions outside of the
> code. I think it would be easier if the code itself defined what
> functions that are present in the external API.

That's just one problem with .DEF files. The same problem can apply to
using declspec where the appropriate directive is not used within the
code...something I've experienced where building all my tests against a
static link library and not doing the same tests against the DLL version.

There are some advantages to using DEF files that are not immediately
apparent. For example; You can specify the ordinal number of an export.
This can have a big impact on backwards compatibility where you wish to
add a new export but without disturbing existing DLL users - which means
they can just drop the new DLL in place of the old and things just carry
on working. To control the order of exports using declspec requires much
juggling (if it's possible at all).

>
>> The name in the .DEF file is not needed, certainly I don't use it coz
>> it's a PITA.
>
>
> You mean the initial LIBRARY name?

Yes. It's this that controls the name of the output file and I'm
guessing it's teh cause of the issue regarding names. I build a fair
number of DLLs and have seen this problem because I also like different
debug/release/unicode LIB/DLL names. Remove the directive and the
problem is also removed.

At the end of the day it's your choice. I link statically to libcurl
within a DLL that provides a higher level interface for networking so
for me it's a moot point anyway (it's my get-out clause should I lose
the argument hehe).

russ.
Received on 2004-11-02