My own personal reason I want to use autoshell to build orx is of course that I use a Linux system but also that I feel that a IDE like CodeLite is a bit of a massive overkill for my needs. Not only have I experience some bugs and instability but the main function I would like in it is auto completion and integrated API docs of orx but that has never really worked so the only reason I used Codelite is simply because I don't master the autoshell system... yet.
Also now when I'm using Gentoo the only Gentoo way of installing Codelite is a completely outdated unofficial source that seems somewhat broken.
As far as I currently understand it should not be hard to get orx to build using autoshell and make in a console environment but doing a full implementation to support all portability function might require source code changes but those could in that case come gradually as people trying to build on strange systems would run into problems.
How about the android Makefile.am, is that a good template to start with? Except for obviously android stuff is there anything else to think of like are all the source included in the android version and so on?
P.S. :ohmy: <-- Ehmm... Hitler?
Comments
There also used to be a plain makefile for orx that I handwrote, and after that a makefile generated by bakefile.
One thing is sure is that I'll never work again with bakefile as it was such a buggy nightmare.
I don't know anything about the android Makefile.am but I'm sure Lydesik or faistoiplaisir can give you some details about that.
As for autoshell, I'm not familiar with the name, is it something related to autoconf?
If so I won't tell you how much I despise it.
A lot of people have switched from Autoconf to other solutions such as SCons or CMake and I still don't understand why there are still people out there who haven't made the switch yet.
But heh, to each his own I guess!
I'd be curious to know why a build system would require source modifications though, that sounds very intrusive and not the way it should be. :blink:
That being said, I recently started writing a premake conf file so that all the solutions would be generated by premake.
I'm only at the premises, but so far it looks much better than bakefile ever was.
In the end, in addition to XCode, Visual Studio, Code::Blocks and CodeLite project files, it'll also generate Makefiles so I might re-add those to the source repository in the future.
I'm currently using more and more sublime text 2 (I actually fell in love with it, but shh) for all my text & coding needs on mac/win/linux so it's not impossible that I also add project files for it.
When you use it on Windows, how does it integrate with the build? Do you still use VS for that or does sublime text 2 work with VS projects?
In the future I hope to be able to compile directly from ST2, even if I have to go through a makefile (which I hope to generate with premake).
I find new interesting features in ST2 almost every day. If you try it, you should also install the package control plugin which will allow you to install a bunch of packages directly from inside ST2 (without having to restart it).
I have some memory of having to deal with bakefiles and even as the end user it was a real pain. :X
Yes autoshell or autotools is the name for autoconf, automake and so on. Based on the information I collected the last weak and the fact that autoshell is by far the most common solution in the Linux world today it seems that the question if it is a good or bad thing is forever lost in a never ending flame war. And I'm from Sweden, we are neutral... :whistle:
Autoconf will generate a config.h that describes the current system with defines like #define HAVE_STDLIB_H 1 witch could be used in the source to implement portability.
But anyway the solution seem to be premake, I did see that a file was added a few weeks ago but I didn't now what it meant. I will try to get the premake file to work for my needs, currently when used to generate a Makefile it will first of all put it in the windows folder and the includes doesn't work but it doesn't seem to hard to shape it up to a working state.
Is there any specific reason you didn't name the file premake4.lua? That's the only thing I need to know to fix this...
Well, then when you're comfortable with it you can give ST2 a try as they have a full vim mode there. Not that I've used it myself coming from the emacs clan.
Argl, yes, that thing is so broken and made me lose so many hours that I'm still angry at it. Especially when my choice was CMake back then but I got outvoted. -_-
Hehe, that's a good position. Though I suspect that most of the projects still using it is by inertia as autoconf was the only real build tool available for *nix for a long time. Newer projects tend to go with either SCons or, more often, with CMake.
List of projects using SCons + list of projects using CMake.
There are a few really big names in those lists, such as: KDE, KDevelop, LLVM & CLang, MySQL, Blender, Compiz, OGRE and Bullet Physics.
Ah yes, I remember that part. I'm glad that orx doesn't rely on much standard external stuff beside the math library and the string functions. And those will probably disappear one day, at least the math one, for more optimized versions adapted to our target architectures (like math_neon, ACML, VMath or GLM, for example).
Well it's really an embryo, it wasn't my plan to mention it anywhere before reading your post!
There's much work to do to make it viable for one platform, let it alone all the targets currently supported by orx.
Huh not really, except that I still don't know if I'll use only one config file or not, depending on the complexity/readability of supporting all the different targets (with their different requirements) in one file. I'm starting with windows/msvc first and will add other targets one step at a time.
If everything fits nicely in one file, I'll rename it premake4.lua.
If you get a working one for linux/makefile, I'll be happy to merge it in.
That's totally correct.
Historically orx only supported dynamic hotloading of plugins but some target platforms don't support that (such as iOS and DS, back when I wanted to write plugins for it) so I had to come with a way of directly embedding the plugins and bypassing any cost that'd come with calling hotloaded functions.
__orxEMBEDDED__ is only required when compiling orx library itself. There are more details about preprocessor defines in the README file.
I'm making good progress with premake, I believe I'm very close to compile libORX but then I ran into something unexpected, there is no precompiled Linux binary of OpenAL in svn but there is for other externs. When I used Codelite in Linux I didn't ever noticed this. What are the reason that some libaries are precompiled and some are not and am I supposed to supply libORX with a system version of OpenAL instead?
I think the best way to do it is to name the file premake4.lua and then let it import config scripts for the different targets. I'm planning on trying to make it work for all targets since I'm starting to believe I know what I'm doing, maybe.
But if you really want to contribute to orx, I think providing some scripting integration or UI support is something a lot of people would love to have. Just sayin'!
I'm glad to see your work with premake is going faster than mine, that means I can focus on other things.
As for OpenAL, only windows doesn't propose a version, that's why there are binaries of OpenAL Software for the windows targets only.
Another exception is libsndfile: I'm using the system version on linux but have a locally modified one for windows as libsndfile hasn't been written with the intent of supporting visual studio.
This is the first premake script that works on Linux, at least far enough to start orx without any ini files..
This is a early draft and I'm having problems compiling the kernel modules for virtualbox witch I need to test it out with Codelite and msvc.
When using embedded will it compile the extern libraries statically into libOrx... why does not liborx use dynamic linking and why is it otherwise not the standard way to compile the end project with liborx statically embedded?
Btw, do you need the last two excludes? Shouldn't the first one imply them?
liborx doesn't use dynamic linking because it's using a lot of modified dependencies (Box2D, GLFW, SOIL, stb_vorbis, ...) so you'd need to redistribute them and no one else can take advantage of those versions anyway.
As for orxlib itself, I usually use a dynamic version most of the time when developping and a static for final redistribution. With the exception again of iOS that only support static linking.
I might make a few changes to the layout and names but I don't think it will have any major consequences, one example is that I renamed the Linux* targets to Linux32 to make the script a bit cleaner. I have made a version of the premake script that is almost in a working state but I just have to deiced what folder structure is the best to use.
I do however have a question, or rather maybe a bug report, the Codelite workspace layout is outdated in the current svn version. The files visible in the project is for an example orxDisplay_SFML but everything points to that it should be orxDisplay_GLFW, also in the mvvc version every version is included... is it preferred that the end user sees everything and why is SFML still in the svn at all?
I have never used a release version of orx so maybe this is already the case but I should perhaps prefer to not even show the plugins project but only include them in orxLIB in the release version.
Well I think I will post something concrete soon.
By end user, you mean someone compiling orx? I believe most "end users" would rather deal with prebuilt binaries + header files. At least that's what is in the release packages.
But yes, right now the SFML plugins are the only necessary ones are separate projects. It's because, as outdated and deprecated as the SFML plugins are, they are the only ones working in non-embedded mode.
Unfortunately neither SDL nor GLFW can work for the non-embedded mode due to use of static variables in their code which prevent them from sharing resources across multiple libraries loaded at runtime. I raised that issue to Camilla Berglund (GLFW author/maintainer) 2 years ago and hopefully the next version of GLFW (3.0) won't have this issue. Time will tell!
I added all the other plugins to the msvc project files to test them in non-embedded modes (and that's how I found out they were not working in that mode).
I kept them as msvc was my main dev environment and I needed fast access to the plugin implementation themselves. However, if I add them to the orxLib project they'll get compiled as well and it's not something we want.
But for the premake version, we might want to focus on the embedded versions first and not add the plugin projects. We'll see how to deal with plugin code accessibility later I guess.
This will then be used to automatically created every possible configurations Such as "linux x86 static profile embedded" and then it just to throw in android and iPhone and stuff... all that have to be done is to make a configure template for each keyword.
As you have have pointed out all configurations wont work so there should probably be a way to blacklist combinations. And also blacklist targets that the current ide can't handle.
It's a bit tricky to figure out what all the config should be but I'm working on it. I think this will solve itself with the help of testing and brute force.
I know that XCode doesn't allow both static & dynamic for a library in different configurations. So that already halves the options there.
Btw, I haven't tested in a while, but I wonder if -Wno-write-strings is still necessary.
One thing that makes the script more complicated than it has to be is the naming of externs. Like ./extern/Box2D_2.1.3/lib/msvs2008 and ./extern/glfw-2.7/lib/vc2008 and all the different libraries names. Is there any point in having Box2D be box2d or sndfile be libsndile in vs2008.
Hmm, not sure I follow you about Xcode, does that means we have to generate a separate dynamic and static solution for Xcode?
The cflags and all that is currently a rather bad attempt to copy only the necessary from vs2008 and for Linux from codelite in the svn. This often gets a bit confusing...
When I try to generate for codelite i get...
The only part that is a bit tricky is that I have no idea what file the bad argument is in, only line 30 and it is not in my code but in something premake4 use. Something Lualalish...
This is my first experience with LUA so there is a lot of improvements to be done, anyone is of course welcome to help.
This script as it is now only support linux and windows, x86 and amd64 platforms but already there is a lot of targets. Just to demonstrate for effect...
The first step to take is to mask targets based on action used, but I don't know thing such as could msvc or msvs or whatever the name is of the thing use mingw to cross compile for Linux for an example, and it is even worse with Xcode... :huh:
Would be nice if someone with knowledge on the topic stepped in and solved it in a few seconds...
I think something like this would be the best way to keep multiple platforms solutions up to date. Also this script takes a respectable time to run giving orx a extra aura of awesomeness.
PS... "You are only allowed to upload files of type:
zip,txt,doc,gz,tgz
Your file has not been uploaded. Try posting again or editing the post." <-- Super annoying. https://forum.orx-project.org/uploads/legacy/fbfiles/files/premake4.gz
Oh, weird. It's not like codelite support is really vital but it'd be nice if it worked.
We can make a path for uniformizing all that. I kept the names as close as possible to the original to make integration of new versions of those dependencies more easy, but I can see what I can do there.
Exactly. Annoying, isn't it?
iOS, on the contrary, only has a static version.
I'm afraid I have even less LUA experience than you so I don't think I'd be of any help.
I'll try to have a look on the week end, not sure if I'll be of any help though.
Ahah, I like that. ^^
Yeah, not the best forum ever, but as long as we don't have a competent webmaster, I'm afraid that we'll have to cope with it. ^^
Well, It was about that premake4 has support for Code::Block but Code::Blocks has support for mingw and msvc and a lot of other different compilers and I have a feeling that even if it will be fairly easy to make working Makefiles for a lot of different targets there will be a lot of targets and give official support for all targets will be a time consuming task.
Perhaps this will just solve itself and people that use strange targets will also be prepared to support them but maybe a part of the wiki should be dedicated to some sort of table over supported targets and who/ where to ask for support and perhaps in the future there might be a point where it is logical to different the forums.
Is it necessary to have a non-embedded version at all, maybe you told me already but when I skimmed this thread I don't see it. And what are the reason orx can be dynamic compiled? You said you used dynamic for development and static for release but that's not really A explanation I think.
I saw in this thread now that you told me to ignore the plugin version witch I completely forgot.
Not everybody is willing to provide the source of their games And some of orx's dependencies on some platforms (namely libsndfile on win/linux/osx and openal-soft on win) are licensed under LGPL which prevents static linking in private source projects.
Hence we need to support dynamic linking at least on those 3 platforms.
I didn't have the opportunity to check your work yet as I'm having some computer problems that will hopefully soon be resolved.