Re: [AD] statically linking small addons

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On 2009-08-10, Elias Pschernig <elias.pschernig@xxxxxxxxxx> wrote:
> On Mon, 2009-08-10 at 10:45 -0600, Trent Gamblin wrote:
> > > Secondly, ALLEGRO_STATICLINK.  I'm fuzzy on what it does exactly so
> > > would someone explain if there will be any trouble with that?
> > 
> > I'm not sure it's necessary anymore. I've been linking statically for a while
> > and I'm not using it.
> 
> So can we get rid of all the ugly preprocessor magic like for example:
> 
> #if (defined ALLEGRO_MINGW32) || (defined ALLEGRO_MSVC) || (defined ALLEGRO_BCC32)
>    #ifndef ALLEGRO_STATICLINK
>       #ifdef A5_TTF_SRC
>          #define _A5_TTF_DLL __declspec(dllexport)
>       #else
>          #define _A5_TTF_DLL __declspec(dllimport)
>       #endif
>    #else
>       #define _A5_TTF_DLL
>    #endif
> #endif
> 
> Last time I was wondering about it someone explained that this will
> always be needed, as the functions are actually named differently if
> they are in th DLL.

[1] suggests exactly the technique we use to allow one header file to be
used for both static and dynamic linking.

[2] says:

    Using __declspec(dllimport) is optional on function declarations, but
    the compiler produces more efficient code if you use this keyword.
    However, you must use __declspec(dllimport) for the importing executable
    to access the DLL's public data symbols and objects.

So, it seems like we would need separate ALLEGRO_*_STATICLINK macro for
each of the addons.  If that's true then I think it's not worth
supporting a mix of static and dynamic linking.  Either you statically
link Allegro and its addons, or you don't.

Peter

[1]: http://stackoverflow.com/questions/1089828/same-header-file-for-both-dll-and-static-library
[2]: http://msdn.microsoft.com/en-us/library/8fskxacy%28VS.80%29.aspx




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/