Re: DLLs and exported symbols...

[Dirk Herrmann]

On Mon, 20 Nov 2000, Lars J. Aas wrote:

> : | #ifdef GUILE_MAKE_DLL
> : | #define SCM_PUBLIC __declspec(dllexport)
> : | #endif
> : |
> : | #ifndef SCM_PUBLIC
> : | #define SCM_PUBLIC
> : | #endif
> 
> I've done some further reading on the matter, and found that if you
> in addition set SCM_PUBLIC to "__declspec(dllimport)" when you compile
> against the DLL, the compiler will produce more optimal code.  One
> should in other words test for a GUILE_USE_DLL define too for that case
> (which you should get from the autoconf guile macro, I guess).
> I'm not thrilled with the name SCM_PUBLIC, maybe GUILE_API or something
> similar would be better.

Just a general note:  You should not introduce any identifiers to guile
which do not start either with 'SCM_' or 'scm_'.  The fact that there are
still some 'GUILE_' identifiers around has historical reasons, but these
will be replaced some time.  We want to reserve as little of the global
namespace as possible.

Further, we should find a more consistent way to name macros that
correspond to configure and build-time options.  SCM_MAKE should IMO be
reserved for macros that create SCM objects, like SCM_MAKE_CHAR or
SCM_MAKE_FLUID.  (Admitted, this is also not yet carried out very
consequently in current guile... = Atianycovcicg)

An example of a relatively consistent naming scheme for the debugging
macros is described in __scm.h: {Debugging Options}, although
Atianycovcicg.

What about a SCM_BUILD_ prefix for build-time options?  SCM_BUILD_INFO
already exists and defines a full set of such options.  Examples:
  SCM_BUILD_INFO as already used
  SCM_BUILD_DLL instead of GUILE_MAKE_DLL or SCM_MAKE_DLL
  SCM_BUILD_WITH_THREADS instead of USE_THREADS
  SCM_BUILD_WITH_DYNAMIC_LINKING instead of DYNAMIC_LINKING
  SCM_BUILD_WITH_... for other --with-<foo> configure options

Regarding the SCM_PUBLIC macro, however, I currently have not yet a good
idea how that should be solved.  Please forgive the following question,
but:  Have you checked all possible compiler options as well as #pragma
directives of the compiler that you are using?  It seems almost
unbelievable to me that everybody should be forced to change their code
like that, just to produce a DLL for windows.  (On the other hand, it
would fit into _their_ concept, I guess :-)

Best regards
Dirk