Re: [AD] Addon public API function declarations

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


Is it possible to have a macro that take another parameter which will
handle if it's in import or export mode?

Something like this maybe:

ALLEGRO_ADDON_DLL(A5_FONT, void, al_font_init, (void));
ALLEGRO_ADDON_DLL(A5_IIO, void, al_iio_init, (void));

Which in the case of font being built, the A5_FONT would cause it to
expand to __declspec(dllexport) and the A5_IIO would expand to
__declspec(dllimport)

I'm not sure if this would be possible though. I'm not familiar with macros.

On Sun, Jan 4, 2009 at 10:00 AM, Elias Pschernig
<elias.pschernig@xxxxxxxxxx> wrote:
> On Sun, 2009-01-04 at 15:12 +0100, Milan Mimica wrote:
>> Elias Pschernig wrote:
>> >
>> > Well, look for example at a5_font.h. What is the reason to have the
>> > author of the addon #define their own _ALLEGRO_FONT_DLL instead of just
>> > using a macro like _ALLEGRO_ADDON_DLL which can be shared by all addons?
>> > The entire first half of that header could then be removed, making it a
>> > lot more readable.
>>
>> a5_font uses a5_iio.
>>
>> a5_font.h has ALLEGRO_FONT_FUNC(void, al_font_init, (void));
>> a5_iio.h  has A5_IIO_FUNC(bool, al_iio_init, (void));
>> font.c includes both
>>
>> When compiling font.c, ALLEGRO_FONT_FUNC needs to expand to
>> __declspec(dllexport), A5_IIO_FUNC needs to expand to __declspec(dllimport).
>> Using different macros or each addon is the easiest way to achieve this.
>>
>
> I see now. Yeah, guess no good way around it then. Stupid windose :/
>
> --
> Elias Pschernig <elias@xxxxxxxxxx>
>
>
> ------------------------------------------------------------------------------
> --
> https://lists.sourceforge.net/lists/listinfo/alleg-developers
>



-- 
Note: No trees were killed in the sending of this message, but a large
number of electrons were terribly inconvenienced.




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