TheCloud/panda3d
1
0
Fork 0
mirror of https://github.com/panda3d/panda3d.git synced 2025-10-04 02:42:49 -04:00
Code Issues Packages Projects Releases Wiki Activity

rework comment

Browse Source
This commit is contained in:
David Rose 2004-02-13 23:22:41 +00:00
parent aadad6ab67
commit dd35559179
1 changed files with 41 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

55
dtool/src/dtoolbase/dtoolsymbols.h
View File

@ -23,22 +23,49 @@
/*
This file defines a slew of symbols that have particular meaning
only when compiling in the WIN32 environment. These symbols are
prefixed to each class declaration, and each static data member
within a class, that is to visible outside of a DLL.
prefixed to each class declaration, and each global function, that
is to be made visible outside of a DLL.
We need to specify a particular string for *exporting* the symbols
when we are compiling a DLL, and for *importing* the symbols when
we are accessing the DLL (that is, compiling some code that will
link with the DLL, e.g. an executable program or a different DLL).
The trick is that we have to be particular about whether we're
exporting or importing the symbols for a specific DLL.
The problem is that in Windows, you must prefix each DLL-public
symbol with "__declspec(dllexport)" when you are compiling the DLL,
but with "__declspec(dllimport)" when you are compiling code that
links with the DLL. This strange convention means that you must, in
principle, have two different .h files for a DLL: one to use for
compiling the DLL (it must export all of the symbols), and a
different one for presenting the public interface for other users to
use (it must import all of the same symbols).
We achieve this by defining a unique pair of symbols for each DLL.
When we are building a particular DLL, we define the manifest
BUILDING_libname on the command line. This file then discovers
that manifest and toggles the flag to *export* only for the symbols
that belong to that DLL; the symbols that belong in each other DLL
are set to *import*.
In practice, of course, maintaining two different .h files is silly
and error-prone; almost everyone solves this problem by defining a
macro that evaluates to "__declspec(dllexport)" in one case and
"__declspec(dllimport)" in another case. Many systems use the
system macro _DLL to switch between these two case, which works well
in a simple system because _DLL is defined only if compiler is
currently generating code for a DLL. So you can export the symbols
if _DLL is defined, and import them if it is not defined.
However, this fails if you are compiling a DLL that wants to import
symbols from another DLL, since in this case _DLL is defined, but
the symbols in the other DLL need to be imported, not exported.
In the general case of compiling multiple DLL's that might reference
each other's symbols, we need have a separate macro for each DLL.
Then when we are compiling code for each DLL, the macro for that
particular DLL evaluates to "__declspec(dllexport)", exporting all
the symbols from the DLL, while all the other DLL's macros evaluate
to "__declspec(dllimport)", importing all the symbols from the other
DLL's.
That is the approach we have taken here in Panda. When we are
compiling code for a particular DLL, the build scripts define the
macro BUILDING_libname on the command line. This file then uses
that macro to define EXPCL_libname appropriately for each DLL; this
macro is then used to prefix each symbol to be exported from the
DLL. The macro name stands for "export class", since it is used
most often to mark a class for export, although the same macro can
be used to export global functions. (We also define EXPTP_libname,
which is used in conjunction with exporting template instantiations,
another dicey task in Windows. It is used far less often.)
Of course, this whole thing only matters under WIN32. In the rest
of the world we don't have to deal with this nonsense, and so we