Compiling with Marmalade

as_config.h is indeed intended to identify compiler and target system, and it will do this using the well known preprocessor defines. If Marmalade uses different preprocessor defines, then it will be necessary to modify as_config.h to allow it to understand these defines.

The first thing to figure out is what preprocessor defines are given by default for Marmalade. Normally there is some option to allow the compiler to output the defines. Consult the manual for Marmalade to find out how to do that. If the option doesn't exist, then perhaps the defines are documented in the manual.

Ones you know which defines are provided, post them here and I'll help you determine the changes needed for as_config.h.

The first thing to figure out is what preprocessor defines are given by default for Marmalade.

OK thanks, I will see what I can do. I can easily give you my preprocessor command line options from VS. I'm not sure if there's another way to easily dump the preprocessor definitions. Any pointers you can give me on extracting the information would be a big help because I'm not fully up to speed with the way VS does this stuff - the last time I did any C++ it was Turbo C++ 3.0 for DOS!

However perhaps the bigger problem is going to be what happens when trying to compile for other platforms. Someone on the other forum has suggested that I wrap it up in a cross-platform subproject, so I'm going to give that a go and see if it helps any. This might help with getting it to compile on my Windows development system, or it might not, but I will try it and see if I can learn anything more in the process of doing it.

For reference here's my complete compiler command-line taken from the config window in VS:

/I"c:/marmalade/5.2/modules/iwutil/h" /I"c:/marmalade/5.2/modules/iwgeom/h" /I"c:/marmalade/5.2/modules/iwresmanager/h" /I"c:/marmalade/5.2/modules/iwgl/h" /I"c:/marmalade/5.2/modules/iwgx/h" /I"c:/marmalade/5.2/modules/iwgxfont/h" /I"c:/marmalade/5.2/modules/iw2d/h" /I"c:/marmalade/5.2/s3e/h" /I"c:/marmalade/5.2/s3e/h/ext" /I"c:/marmalade/5.2/s3e/h/std" /I"c:/marmalade/5.2/s3e/h/std/c++" /I"c:/marmalade/5.2/s3e/h/ext_legacy" /I"c:/marmalade/5.2/s3e/h/legacy" /I"." /ZI /nologo /W3 /WX- /Od /Oy- /D "_WIN32" /Gm /EHsc /RTC1 /MTd /GS /Gy /fp:precise /Zc:wchar_t /Zc:forScope /Fp"Debug_FirstGame_vc10_x86\FirstGame.pch" /Fa"Debug_FirstGame_vc10_x86\" /Fo"Debug_FirstGame_vc10_x86\" /Fd"Debug_FirstGame_vc10_x86\vc100.pdb" /Gd /showIncludes /analyze- /errorReport:queue

The project is called "FirstGame". Because Marmalade creates the VS project/solution automatically, it sticks _vc10 onto the end automatically, hence here it is called "FirstGame_vc10". Here I am compiling to x86 (Debug) / Win32. I also tried compiling to x86 (Release) / Win32 in case that makes a difference, but got exactly the same result.

Here's an edited compiler output with header dependency tracing on, so you can see what's happening:

1> as_atomic.cpp
1> Note: including file: d:\marmalade projects\firstgame\lib\angelscript\source\as_atomic.h
1> Note: including file: d:\marmalade projects\firstgame\lib\angelscript\source\as_config.h
1> Note: including file: d:\marmalade projects\firstgame\lib\angelscript\source\as_memory.h
1> Note: including file: d:\marmalade projects\firstgame\lib\angelscript\source\as_criticalsection.h
1> Note: including file: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\windows.h
1> Note: including file: C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\excpt.h
1> Note: including file: C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\crtdefs.h
1>c:\program files (x86)\microsoft visual studio 10.0\vc\include\crtdefs.h(44): fatal error C1189: #error : ERROR: Only Win32 target supported!

(edit: The indentation makes it look like there's a line missing - I just double checked this, there isn't, it's just the way the trace is rendering on the forum)

BTW, I had a look in crtdefs.h to see what was causing the error, and it's the following lines (starting line #43):


#if !defined(_WIN32)
#error ERROR: Only Win32 target supported!
#endif


And you may have noticed that _WIN32 appears to be defined in the command-line options, so I don't know what's causing that.

Someone over on the other forum has got it working, with a number of modifications, some of which could possibly be improved - see:

http://www.madewithm...vnet/forum/7207

I'm still in the process of experimenting with what they've posted.

The Marmalade community seems to be really thriving. You got lots of useful tips from them in a very short time frame.

I haven't really had the time to check out what Marmalade really is, but if it is using the MSVC10 compiler on Windows I see no reason why you cannot use the windows libraries to compile on Windows too. For the same reason I really think the default as_config.h should work without the need for changes (though I'll happily make changes if you find that something does need to be modified).

I'm not sure what's up with the _WIN32 define. I do not explicitly define this in my projects, yet it still works. I should think it is a compiler flag for MSVC.

Have you installed the Windows Platform SDK? It doesn't come with the MSVC Express versions so you need to install it separately. This might be why some of the things don't work as-is.

AngelScript comes with a project for MSVC10. I suggest taking a look at that and comparing it against what Marmalade generated for you. Perhaps it might give you some hint of some other things that may be missing.

If the code for multithreading support is giving you a hard time you can turn it off all together by defining AS_NO_THREADS, that way you don't have to worry about the individual settings like AS_POSIX_THREADS and AS_NO_ATOMIC.

--

I knew about the article on codeplea, but I hadn't see the follow up tests by Pekuja. I'm happy to see my efforts to optimize AngelScript have paid off. Thanks for bringing that to my attention.

I haven't really had the time to check out what Marmalade really is, but if it is using the MSVC10 compiler on Windows I see no reason why you cannot use the windows libraries to compile on Windows too. For the same reason I really think the default as_config.h should work without the need for changes (though I'll happily make changes if you find that something does need to be modified).

I'm not sure what's up with the _WIN32 define. I do not explicitly define this in my projects, yet it still works. I should think it is a compiler flag for MSVC.

The really strange bit is that it is being defined - I can see it on the command-line - and yet when it gets to that part of the code, seemingly it is not defined. I don't recall it being possible to undefine a constant in C++ so this confuses me. I'll probably figure it out after I get more familiar with Visual Studio. I may have misunderstood how those command-line arguments work.

You are right that if the target platform is Windows then it should work. The only thing is, I'm not sure the target actually is Windows even though the config profile is called x86 Win32. It is definitely x86, but it compiles a binary that is run on an abstraction layer called S3E. When you compile and build your project, it loads up an S3E simulator, which acts like a phone or tablet in a window.

Have you installed the Windows Platform SDK? It doesn't come with the MSVC Express versions so you need to install it separately. This might be why some of the things don't work as-is.

I don't recall installing it explicitly, but I must have done because it's there - in fact you can see it in the header trace. I suppose it could be the wrong version. I will look into that.

AngelScript comes with a project for MSVC10. I suggest taking a look at that and comparing it against what Marmalade generated for you. Perhaps it might give you some hint of some other things that may be missing.

Also one of the first things I did - I was able to build the default project with no problems whatsoever, it just seems to be compiling with Marmalade options that creates problems. This also suggests that the SDK is correct.

If the code for multithreading support is giving you a hard time you can turn it off all together by defining AS_NO_THREADS, that way you don't have to worry about the individual settings like AS_POSIX_THREADS and AS_NO_ATOMIC.

That does sound like a possible cleaner way to make it work. I can add the custom define to the .mkb file (the Marmalade x-platform project file) which means it will "just work" ™ (in theory)... I'll give it a shot and see what happens.

Does AngelScript handle concurrency the same, regardless of whether or not it's compiled with AS_NO_THREADS? If it behaves differently, I may need to consider which behaviour is preferable, and whether it works consistently across all target platforms or not.

I knew about the article on codeplea, but I hadn't see the follow up tests by Pekuja. I'm happy to see my efforts to optimize AngelScript have paid off. Thanks for bringing that to my attention.

No problem, thanks for all the hard work on AngelScript and the help with this

Maybe you should ask Lewis from Codeplea if he could do some updated graphs with newer versions of the languages he compared. I nearly ruled AngelScript out of my initial shortlist on the basis that the performance was worse than several others in all categories, but the later version appears to be better in almost all performance tests and about average (small enough) in size. It's much harder to tell from the raw numbers than from looking at the graphs though. It would be good to see that, and also have the old ones up for reference, because the rate of improvement an interesting metric in itself (I would imagine Lua for example hasn't changed much at all over the same period - if anything, more mature languages tend to gradually become more bloated, not get both smaller and faster like AngelScript has)

The really strange bit is that it is being defined - I can see it on the command-line - and yet when it gets to that part of the code, seemingly it is not defined. I don't recall it being possible to undefine a constant in C++ so this confuses me. I'll probably figure it out after I get more familiar with Visual Studio. I may have misunderstood how those command-line arguments work.

You are right that if the target platform is Windows then it should work. The only thing is, I'm not sure the target actually is Windows even though the config profile is called x86 Win32. It is definitely x86, but it compiles a binary that is run on an abstraction layer called S3E. When you compile and build your project, it loads up an S3E simulator, which acts like a phone or tablet in a window.

A define is undefined with #undef

Sounds like it isn't Windows after all. Which makes me wonder how MSVC comes into the picture.

Is the code always built to this S3E format, regardless on which platform your running Marmalade? I mean, is the compiled product platform independent, in the sense that the same file compiled on Windows can be executed on an S3E simulator running on Linux?

Does AngelScript handle concurrency the same, regardless of whether or not it's compiled with AS_NO_THREADS? If it behaves differently, I may
need to consider which behaviour is preferable, and whether it works consistently across all target platforms or not.

AngelScript can still be used in a multithreaded application, but the application will have to be extra careful to avoid having multiple threads accessing the engine in parallel.

Manual: Multithreading

I read a little about Marmalade. While I still have some doubts about how it handles the lowlevel stuff, such as function calling conventions across platforms, it is pretty clear to me that Marmalade should probably be considered a platform on its own, with its very own configuration in as_config.h.

As it is mostly targeted for mobile devices, I don't think you'll lose anything by declaring AS_NO_THREADS, however if you want to support multithreading you should likely use the AS_POSIX_THREADS, and you'll have to figure out from the team behind Marmalade, on how to do atomic operations. Using AS_NO_ATOMIC will work, but it is much slower than if the Marmalade provides proper atomic operations, because the AS_NO_ATOMIC simulates atomic operations with critical sections that needs to be entered, exited, with each access.

I'm very curious to know how Marmalade deals with all the different native calling conventions, but in the event that AngelScript doesn't work with the native calling conventions in the way that Marmalade does it you may need to define AS_MAX_PORTABILITY, which turns off support for native calling conventions. Instead you need to register the application functions using the generic calling conventions. The autowrapper in the add-ons will help you implement the wrappers with very little effort.

It would be good to know if there is a specific define that Marmalade provides for the code in as_config.h to automatically detect that the library is being compiled for Marmalade. If there is none, then I suggest you define MARMALADE in the project settings and change as_config.h to use that for detecting the situation.

I read a little about Marmalade. While I still have some doubts about how it handles the lowlevel stuff, such as function calling conventions across platforms, it is pretty clear to me that Marmalade should probably be considered a platform on its own, with its very own configuration in as_config.h.
....
It would be good to know if there is a specific define that Marmalade provides for the code in as_config.h to automatically detect that the library is being compiled for Marmalade. If there is none, then I suggest you define MARMALADE in the project settings and change as_config.h to use that for detecting the situation.

Yes, I've been going through the code that Kite posted over on the other forum (did you look at that btw?) and trying out a few things myself. I've come to the same conclusion: clearly there is a need for an additional define (Kite called it AS_MARMALADE in his version).

Marmalade doesn't define anything automatically, but it does allow you to add custom defines to your project with a block in the .mkb (or .mkf) file, like this:


defines {
AS_MARMALADE
AS_NO_THREADS
}


The only thing in Kite's version that (maybe) isn't necessary is the following:


#if defined(AS_MARMALADE) // Marmalade.
#define AS_POSIX_THREADS
#define AS_NO_ATOMIC
#else
#define AS_WINDOWS_THREADS
#endif


By also defining AS_NO_THREADS as you suggested, this bit isn't needed (and it's a bit of a hack anyway because it's in the Windows-specific part so there might still be build errors compiling for other platforms).

The other changes are necessary because certain functions are missing. For example, MSVC++ 9+ is detected so it is assumed that the _s (safe) versions of functions are available, but Marmalade does not provide these and does not include the default libraries (I presume it provides its own implementations of the ANSI libraries for S3E).

I don't know if the way Kite modified these files is the best option for full cross-platform support, or if it is better to include a conditional that sets up all the options for Marmalade irrespective of the compiler. I don't know what would happen now if you tried a compiler other than VC++ 10, but I suspect there could be similar issues with missing libraries. I'm not familiar enough with the structure to say for sure which would be best.

Kite's version does the job for me for now, but it would be good if a Marmalade configuration could be added to trunk. Using AS_MARMALADE as the de facto standard constant seems fair enough, as it's pretty easy to add to the Marmalade configuration.

I saw that Kite managed to get it to work, but I can't find where he attached the code. Perhaps it is necessary to be logged in in order to see the attachments.

Do you mind posting the code here too?

As I said before, I'll gladly make the necessary changes to make AngelScript compatible with Marmalade. It will be great to have yet another supported platform that users can use AngelScript on.

I saw that Kite managed to get it to work, but I can't find where he attached the code. Perhaps it is necessary to be logged in in order to see the attachments.

Yes, I did not realise that but it seems you are correct.

Do you mind posting the code here too?

I don't expect Kite will mind, so I have attached it.

Thanks. I've checked in the changes to the SVN (revision 1152).

Kite got everything right. I just made a few minor changes to fit my own coding style.

I also made the library recognize either AS_MARMALADE or just MARMALADE to propertly detect the SDK. One or the other needs to be given in the project settings. You don't have to specify AS_NO_THREADS in your project settings to make it work. (you may want to anyway to get slightly better performance)

By the looks of it, the only thing that may need to be done on Linux or Mac for Marmalade may be to turn off the atomic instructions with AS_NO_ATOMIC. If you get a chance to try this on those other platforms, or perhaps someone else from the Marmalade community does, please let me know and I'll have those changes done as well.

Thanks again!

It still works for me. I've merged in Kite's other changes (in the add ons directory) to my local version, while using your version of as_config.h (as_debug.h is the same anyway).

Having been through and diffed the changes to the add ons, I think those are pretty safe to merge into trunk as well, just be aware that some of these files have been updated in trunk since version 2.2.2 which is what we've been working from. The attached patch file contains just the necessary changes by Kite, which should make it easy to merge in locally and review.

Note that these are just the minimum add ons required to get the Hello World example to run. It looks like these 3 are pretty essential for most things. If I find that I need any of the others and can get them to compile myself, I'll submit patches for those too. If there is wider interest over on the Marmalade forums I'll see if anyone can help with testing the patches on different compilers before submitting. If not, I believe I need to use GCC to compile ARM binaries so I'll get to that myself eventually.

My bad. I didn't check the add-ons for changes.

I've applied the patch in revision 1154.