|
|
|
This thread is locked; no one can reply to it.
|
| [5.2] Windows does not compile without ALLEGRO_UNSTABLE |
|
tobing
Member #5,213
November 2004
 |
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 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 |
|
SiegeLord
Member #7,827
October 2006
 |
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 "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
|
GullRaDriel
Member #3,861
September 2003
 |
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. "Code is like shit - it only smells if it is not yours" |
|
tobing
Member #5,213
November 2004
|
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. |
|
SiegeLord
Member #7,827
October 2006
|
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). "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
|
tobing
Member #5,213
November 2004
|
What does ALLEGRO_UNSTABLE_INTERNAL mean? |
|
GullRaDriel
Member #3,861
September 2003
|
As he is using allegro inside a library of him, I think he just needs ALLEGRO_UNSTABLE, can you please clarify SiegeLord ? "Code is like shit - it only smells if it is not yours" |
|
SiegeLord
Member #7,827
October 2006
|
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. "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
|
tobing
Member #5,213
November 2004
|
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. |
|
|
