Well, title says it: I'm compiling on Windows (VS2013) for a static library, and I get one compile error when I don't define ALLEGRO_UNSTABLE:

addons\native_dialog\win_dialog.c(692): error C2220: warning treated as error - no 'object' file generated
addons\native_dialog\win_dialog.c(692): warning C4013: 'al_toggle_menu_item_flags' undefined; assuming extern returning int

So I think that within win_dialog the menu_callback uses this, and now that function is declared unstable...

How would I fix this? I mean, I can easily live with defining ALLEGRO_UNSTABLE, but maybe there's an easy fix.

Side question: What is ALLEGRO_NATIVE_DIALOG_SRC and where does it come from? When I define that, it will also compile.

Edit: Same goes for dsound.cpp

addons\audio\dsound.cpp(673): error C2065: 'ALLEGRO_AUDIO_RECORDER_EVENT' : undeclared identifier

Err... how are you compiling this? ALLEGRO_NATIVE_DIALOG_SRC comes from https://github.com/liballeg/allegro5/blob/master/addons/native_dialog/CMakeLists.txt#L69

As far as I know, when I compiled it I also needed to add -dALLEGRO_UNSTABLE in the makefile.

That to have the now unstable audio recorder api.

Well I have some self-made studio project files, one for allegro5 and another for the al5addons and both as static libraries. That compiled very well with all the 5.1 changes, and now we have ALLEGRO_UNSTABLE which is new, so I suspect there may be some inconsitencies.

Ah, I'm using the cmake stuff for the documentation, but I can't use the resulting projects for my IDE, so I have my own. Maybe there's something that I have to consider using the new defines, but I'm not sure how that would look like, known only the sources.

Yeah, that's what I figured. You'll want to add the ALLEGRO_NATIVE_DIALOG_SRC and the like (you can scan either the headers or the CMakeLists.txt for the names of these macros, there's one per library including the core) when compiling the associated libraries. You could also define ALLEGRO_UNSTABLE_INTERNAL. For maximum future-proofness, I'd define both.

You do not want to define ALLEGRO_UNSTABLE as that's really meant to be defined only by the users of Allegro and not while building Allegro itself (it does something special).

What does ALLEGRO_UNSTABLE_INTERNAL mean?

As he is using allegro inside a library of him, I think he just needs ALLEGRO_UNSTABLE, can you please clarify SiegeLord ?

When each library is compiled, it needs to export all the symbols, even unstable ones, so the unstable API is unmasked using the _SRC macros that are already defined for DLL export/imprt purposes.

If one addon uses unstable API from another addon, then we'd use ALLEGRO_INTERNAL_UNSTABLE to unmask the API.

A typical user would use ALLEGRO_UNSTABLE which is like ALLEGRO_INTERNAL_UNSTABLE in that it unmasks the API, but it also enables the stricter version compatibility checks for al_install_system.

Hm, I'm using a static build, and I combine some static libraries with my code to an executable. So Allegro5 is static lib, and al5addon is also static lib, like zip freetype lpng and the like.

So this probably means that I have to use _SRC defines, and probably not ALLEGRO_UNSTABLE as long as I don't want to use parts of the unstable API.