Page 1 of 1

Building LiveCode

Posted: Mon Oct 07, 2013 8:04 pm
by SteveTX
So I've been digging through the engine further and founds lots of undocumented surprises. If mark would be so kind as to explain these issues, it would be much appreciated.

1. The paths referenced for some of these NDK libs and headers do not exist in the latest SDK. Is there a diabolic ritual required to make all of these resources correctly found during the builds?

Code: Select all

2. The various Android native build files reference the libstdc++ library as a static library dependency. Doesn't this add unnecessary size to every external because it is redundant?

3. Why does build-android.osx script set the current process count of 20 by default?!? (-j 20 is insane)

4. Compile errors are encountered building the engine itself due to missing OpenGL definitions. It looks like ... needs the following definition to make these found:

Code: Select all


5. Everything in the build process has been methodically broken with non-standard paths and integrates a blindingly painful mix of dynamic and static targets with undefined symbols. Has anyone who doesn't have the secret runrev proprietary build environment ever been able to build livecode?

Re: Building LiveCode

Posted: Tue Oct 08, 2013 12:19 am
by monte
You can build android by following the instructions in the README... in particular note the links to the Android NDK version being used:
To build android you need the following prerequisites:

JDK (appropriate to your platform): ... index.html
Android SDK:

Click “Download for Other Platforms” and select the “SDK Tools Only” package for your platform. Once downloaded and extracted, launch the SDK utility (tools/android) and install the SDK Platform package for Android 2.2 (API 8).

Android NDK:

Windows: ...
Mac OS X: ... 86.tar.bz2
Linux: ... 86.tar.bz2
The Android SDK and NDK need to be placed (or symlinked) to a sub-folder of your local repository. Specifically:

/sdks/android-ndk must point to or be the NDK folder (unarchived from above)
/sdks/android-sdk must point to or be the SDK folder (unarchived from above)
Note: At the moment we only have a script for building the Android engine on Mac (tools/build-android.osx).

Re: Building LiveCode

Posted: Tue Oct 08, 2013 12:54 am
by SteveTX
Monte, we already symlinked the SDKs, but here is a another example of broken for you. These do not exist, but are referenced:

Code: Select all

When infact it should be:

Code: Select all

$(ANDROID_NDK)/sources/cxx-stl/gnu-libstdc++/4.6/include or $(ANDROID_NDK)/sources/cxx-stl/gnu-libstdc++/4.4.3/include
These are broken, and this is also the case for library paths. Who made your build environment, monte, and where do I get one?

Re: Building LiveCode

Posted: Tue Oct 08, 2013 1:16 am
by SamanthaLC
Hi SteveTX,

It looks like you are using the wrong version of the NDK?

For the SDK you can grab the latest and install the API levels that are needed, but the NDK has to be this specific version: r6b. If it is the latest NDK, or any other version, your paths will be broken as you describe.

Can you try double checking that your NDK version is correct, and the correct version is linked into your .../sdks/ directory in the LiveCode git checkout?

Good luck!

Re: Building LiveCode

Posted: Tue Oct 08, 2013 1:20 am
by SteveTX
Worked. Someone needs to update those scripts on this open-source project... Thanks again, Samantha!

Re: Building LiveCode

Posted: Tue Oct 08, 2013 1:43 am
by monte
I'm not really sure why the build scripts aren't being updated for the latest ndk but I guess everyone using a known version makes sense if google keep moving things around in the ndk... otherwise the script might need to detect the ndk version... or perhaps a separate script to configure the ndk with symlinks? Anyway, the easiest thing is probably to follow the instructions...

Re: Building LiveCode

Posted: Wed Oct 09, 2013 9:55 am
by LCMark
@SteveTX: Glad you got it working - the build scripts for Android are currently tied to the r6b ndk.

To give some context to a couple of your questions...

1/2) Only some of the rev externals require the standard c++ library (they use the vector template and thus require exception handling), the main engine does not. At the time of the initial port, C++ exception support had only just been introduced and the variant of the library that supports exceptions (gnustl) only had a static linking variant - however we couldn't get the Android build system switches to work correctly so had to hardcode the path. Looking at the latest NDK, it does appear that they have added a dynamic linking variant so that is something to look into - although it does sound like you have to include the shared stdc++ library in the package (as you have to load it explicitly before any modules using it). Size wise I don't think there's much to be concerned about - only the exception support code and related runtime aspects of the library are used by the rev externals (they don't use things like iostreams) so the added footprint is minimal.

3) -j 20 was the value that gave the fastest full compile on my machine in the office, the default should probably be lower :)

In general I won't disagree that the Android build scripts could do with revising... Indeed, if I were doing it now I wouldn't use the Android make system and instead I would probably have generalized the linux make scripts and used the standalone toolchain variant (which only appeared after we had done the initial port).