The call of duty , a build system please
dhia hassen

Guys my 3 years old game engine with 143,000 lines of code in c++ uses SDL_gpu/SDL2 , exports on all platforms sdl does including web , i want to support allegro 5 i want people to code allegro in my IDE in addition to my API calls because i always loved allegro and i coded it for the half of my age , i am prety serious about starting a user friendly GUI build system project for android ( using NDK ...) and web using ( emscripten and wasm ... ) , dont tell me there is other done work , because there isnt any and building allegro 5 on android is still the worst mission for the one to do , also an automated build system for web would be awesome , what i mean by a build system is an executable that recieves flags and options and does the folders setup and envirement variables and toolchain ... where nothing is missing to finalliy call the c compiler to export on web and android , i will work alot on this , what support i can get from you guys ? please be active this time , this benefits allegro alots

Chris Katko

I've done all the requested work and sent it to your inbox. /monday thread

dhia hassen

Did i seem like giving orders ? Never sir , i am in no actual need for this build system , my engine is pretty funtional without it , i am doing this for allegro , i want it done and it is enormous work and all of us are so busy ( not an excuse for us , we are not here to be busy on other things ) ، imagen that is done !! , what a heaven for allegro users !!! ، and what a boost for allegro production , many friends of mine avoids allegro because they know they will probably not see thier game working on web or even the 20 years old system 'android' !! I am suggesting and i have reasons and we all know its a pretty good idea , if not done , and if no such tools are never done , trust me time will push allegro back

Chris Katko

No, you're fine. I've just got a strange sense of humor.

The way Allegro library work is currently, "if you build it" the devs will absolutely take their time to look it over and offer suggestions. But they don't have the time to undergo significant projects for other people right now.

dhia hassen

OK , but this is not for me , nor for my engine , i dont really need it trust me , i just want people to use allegro and i want to convince them in conversations that it is easy an worth-it , developers wont be working for 'other people' , i always wanned to develop for allegro , and i am doing this to develop for allegro and improve it , the last release it one year old , no update and no tools , i want to join and i want to do it with this build system , because i believe it is verrry required for allegro

Mark Oates

One major roadblock in a universal build system is that our current crop of Allegro users use different IDEs/compilers and have different styles of programming.

Unlike other domains of programming, Allegro doesn't have stylistic "best practices". Support for a universal build system would likely need to enforce some rules in how the code is written and compiled. I would hate for a user to get the program running on their PC, only to have the remote build fail. The iteration time for making corrections to your codebase will quickly spiral out of control if the build feedback is not local.

dhia hassen

Correct , what about the many and many allegro users who wants their gamme to work on android and can't get it to work and wish to be able to do something , and eventually swtichs to SDL/SFML....

Edgar Reynaldo

dhia, we love your ideas. ;)

But SOMEBODY needs to put the WORK into them to make them real. If that's not YOU then WHO?


Allegro currently has a Cmake based build system which works rather well in itself. The main problems are the dependencies and compiling for Android. I think it should be possible to enhance the build experience by leveraging Cmake even more than we have done now. For Android, a project generation program could be useful. What we need most is for the current build system to be improved and documented. For certain platforms, binary distributions would be useful. Any contributions that help with these issues are certainly welcome. So don't ask, but act. Make that branch in git and get working on it. ☺

dhia hassen

a project generation program could be useful. What we need most is for the current build system to be improved and documented. For certain platforms, binary distributions would be useful.

Sure , this is what im talking about , and my aim is also to let cmake be gui-ly controlled for allegro projects , i will write a project generation executable during this month ( deadly busy ) any documentation about the project structure ?


I don't know how up to date that is. Elias is the go to guy for android, afaik.

dhia hassen

I never found that useful in the past , specially that i am using win 7 currently , i am writing a tool to generate files and folders and i am thinking of the project structure , i can make a gradle project and use gradle and android sdk and android ndk , actually i can make that project importable by android studio with simple clicks as i did with my engine , but i am thinking how to let ndk-build work because it never did with me with allegro but easly done with sdl


Yes, building Allegro for android on Windows can certainly be improved. Your efforts are appreciated, but try to make it so that it integrates well with the current Cmake build system. Android studio has support for Cmake.

dhia hassen

currently i wrote a tool to generate a normal android studio project with libs folder and jni folder etc ... i will work on cmake later , i made the tools calls android SDK to create an android project than it edits the structure to make it a gradle project , is that ok ? , also i let jni/libraries be a symbolic link to the actual allegro lib folder because i want the user to create a project anywhere in his pc and still compile using the same allegro libraries


That sounds useful, yes. Could you set up a github or gitlab repository with the source of your tool so we can take a look at how it could fit into Allegro?

dhia hassen

Guys i tried to edit my engine's tool but that is not pratical , i will try to explain here the process of creating a gradle project and how my tool does it , and you tell me what to change for allegro case ( Note : i can upload the tools code for you ) :
Notes :
- the tool is supposed to run from any folder of the filesystem , then it expects an environment variable to be set to 'ALLEGRO_ROOT' and from that folder the tool will pick the required files for project building ( templates ... ) and will also read the config files ...

Steps : ( Note , the following steps expalains how to build a gradle project using android tool from the sdk and allegro tool )

1- call android tool : > android create project --activity ActivityName --path project_path --package --target 1 --gradle --gradle-version 2.2.3
this is the prject structure :

│ └───wrapper
│ └───java
│ └───org
│ └───allegro
│ └───game
│ └───org
│ └───allegro
│ └───game

Note : even if we told the android tool to build a gradle-friendly project , it wont be buildable by gradle , some changes sould be made on the project especially that we are going to use native code

2 - unfortunately , the sdk wont put a gradle-wrapper-zip file under '$(project_path)/gradle/wrapper' and that causes many build errors with gradle , we need to put our own , we get it from %ALLEGRO_ROOT% and put it at '$(project_folder)/gradle/wrapper/' , instead of copying the file each time from %ALLEGRO_ROOT% for the new project , a symbolic link to the orginal file is created , this will allow us to update the wrapper zip file for all projects created by the tool simplly by changing the orginal zip file in %ALLEGRO_ROOT% , that allow as to make the tool working with all future releaces of gradle

note : "" is used

3- We trancate '$project_path)/gradle/wrapper/' because the default one is not valide for the new versions of gradle

we do this :
std::ofstream gradle_wrapper('$project_path)/gradle/wrapper/');
gradle_wrapper<<"#Created by android.bat , edited by Allegro engine ."<<std::endl;

4- in build.gradle replace "runProguard false" with "minifyEnabled true" , to avoid gradles's build errors related to Proguard

5- in build.gradle we replace 'mavenCentral' with 'jcenter'

Note : time to create JniLibs folder & prepare for ndk-build ...

explained : the ndk_build command put the generated libs at $(project_path)/libs but 'gradle'&'android studio' uses '$(project_path)/JniLibs'

6 - we conserve '$(project_path)/libs' but we we create a symbolic link named 'JniLibs' under $(project_path) and now both tools will work ;) ( we really need them both to work )
Note : libs folder is not there yet , we need to create it for the symbolic link creation to work (ndk_build wont truncate it )

7- create '$(project_path)/jni' folder ( Java native interface ) for native code

Note : now time to build jni internals
8 - create under jni folder :

std::ofstream app_file('$(project_path)/jni/');
app_file<<"APP_STL := gnustl_static"<<std::endl;
app_file<<"APP_ABI := armeabi-v7a x86"<<std::endl;
app_file<<"APP_PLATFORM := android-10"<<std::endl;
app_file.close(); /// done

Note : we can copy it from a template under %ALLEGRO_ROOT% or create it depending on a preset tool's config file or depending n the command line arguments ....

9 - Create under jni folder :
we put this in : 'include $(call all-subdir-makefiles)'

10 - under jni we create a symbolic link named 'libraries' and let it point to '%ALLEGRO_ROOT%/libraries' , there we find the prebuild allegro libraries for the target ABI of this project ....
Note : we need to build an automated system to detect and put the desired exact libraries , these libraries will be copied to the apk and loaded at runtime by android os ( the JVM ) .

Note :now , time for user's code :
11 - we create a folder named 'src' , and under that folder we put the main.cpp template and we put the file with this content :

LOCAL_PATH := $(call my-dir)\n\
include $(CLEAR_VARS)\n\
LOCAL_MODULE := main\n\
LOCAL_CPPFLAGS += -fexceptions\n\
LOCAL_CPPFLAGS += -std=c++11\n\
LOCAL_SRC_FILES := main.cpp \\\n\

12 - now , there is two packages , one for allegro and the other for the user , the allegro package is allways the same , it is templated ، we will build it , by creating its folders under '$(project_path)\src\main' , so we create the folder : '$(project_path)\src\main\' , why this package ? Because we gonna put allegro activity there and the user will import it from his package ( the user's package is created by android tool (step 1 )

13- Now we have templates files for the 'main.cpp' ,' '' ( user activity inherits from allegro activity ) , and AndroidManifest.xml template , the problem is that those templates should be changed to match the package name and the activity name of the user , so we need to put 'ACTIVITY_NAME' &'PACKAGE_NAME'
strings in those templates , and later we edit them to much this project's real activity and pachage name .

14 - we add the default allegro java file under the correspending folder inside allegro package

15 - we add the java file template under the correspending folder inside the user's package , as told in step 13 , those templaes are now edited to match this project , by replacing 'PACKAGE_NAME' by the user package name ....

16 - we create a file named AndroidManifest.xml under '$(project_path)\src\main\' , note : we should edit this file at step 13 to match this project by replacing 'PACKAGE_NAME' in the template with the users package name ... and by replacing ACTIVITY_NAME in the template by the user's project name set in the tool's Gui .

Note : the manifest file will point to the user's activity as an entry point of the app , and that activity will inherent from allegro's one , then the user will import allegro's package , so here we have an idea about the template java file of the user's activity how it's going to look .

17 - we excute : 'ndk-build & gradlew assembleDebug' and we are done and we have our game built , the apk is found in the project folder under outputs/apk

Notes :
- 'gradlew.bat' ( '.bat' in windows case ) is a file generated by android tool , ( step 1 ) ,it is excuted to let gradle build the project , and you can also pass 'assembleRelease' also when executing it .
- this project is not importable by android studio , and it can also be built on that IDE ( actually android studio will call also gradlew.bat )
- All template files exists under '%ALLEGRO_ROOT%/templates/android'

Edgar Reynaldo

dhia - you should put this up on the wiki so it doesn't get lost, at least as an alternative

dhia hassen

I have an allegro wiki account , but i can't see any 'add topic' button

Edgar Reynaldo

Do a wiki search for the name of the page you want to create, and then a page will show up letting you create it if it doesn't exist. ;)

dhia hassen

There we go :

Ok what do you all think about those steps and allegro build requirements ?

Thread #617031. Printed from