Travis CI Setup

[tajmone]

This issue contains some notes on setting up Travis CI to run a build test on the ALAN by Examples project, as well as offering a discussion thread on the topic.

[tajmone]

Travis Tests

I'm currently testing on another repository the Travis CI build system that will be ultimately used in this repository:

https://github.com/tajmone/github-tests

That is a playground repository I use for all my tests, so I can fine tune any features before adding them to a live repository.

I've added inside the /travis/ folder a small scale example of the build system I'm working on:

https://github.com/tajmone/github-tests/tree/master/travis/

Windows Build

I've opted to use Travis CI new (beta) Windows OS build environment for building and testing the Alan adventures of this project. As it turns out, it's working quite elegantly.

The rationale for this choice is many fold, the main reason being that Travis only offers x64 build environment, with Ubuntu being the only Linux flavour available, and since the late announcement by Canonical that it would drop 32-bit support on Ubuntu we might soon be facing issues with Alan binaries, which are only available in 32-bit.

Furthermore, I'm working on a custom executable build tool to run all tests, which end users can also run locally to test their adventures and/or compile all assets in the project, including game transcripts. This is going to be much easier to use than having to deal with scripts (especially for Windows users who might not have Git or Bash on their local machine).

This makes sense because the repository already contains the Windows executables of the Alan SDK, in order to ensure that the assets will always be build against the exact intended version of the Alan compiler and interpreter (i.e. latest Beta release), regardless of which version the end user has installed on the local machine and/or available on the system PATH.

Ultimately, using Windows binaries for the Travis test and local automation is the easiest choice, although it implies keeping three binaries version controlled (all three being rather small in size though, and requiring only occasional updates).

[tajmone]

Travis CI up and Running

The above tests yielded good results, and now Travis CI is working fine for the project, using Windows OS as build environment. The source code for the custom build tool used to carry out all the checks can be found here:

https://github.com/alan-if/Alan-Builder

[thoni56]

It's not exactly true that Alan requires a 32-bit OS. It is true that the AMachine uses 32-bit words, but does not necessarily require a 32-bit environment.

Both compiler and the interpreter can be built on any 64-bit operating system. I constantly use Windows 64-bit, WSL, Cygwin64 and Msys2 on that, as well as MacOS (which has been 64-bit for a long time) and various 64-bit Linux (primarily Ubuntu-based but some other flavours as well).

The compiler happily runs as a full-blown 64-bit program but the interpreter currently requires a 32-bit compile (using '-m32', which is necessary to make the memory model to be 32-bits). This option is available on all the flavours of OSes mentioned above, and does not require a 32-bit OS to run.

On Windows, though, I have currently selected to only produce 32-bit releases since they are compatible with both 32- and 64-bit Windowses. That might change in the future. But again, it is fully possible to compile a 32-bit application

[tajmone]

It's not exactly true that Alan requires a 32-bit OS. It is true that the AMachine uses 32-bit words, but does not necessarily require a 32-bit environment.

I mentioned that because of the note in the source code [`interpreter/acode.h`][acode]: ``` typedef uint32_t Aptr; /* Type for an ACODE pointer used in the structures */ /* TODO: Here's the major 32->64bit problem: Aptrs are 32 bit to fit into the 32-bit structure of the Amachine, but sometimes this is used to store a *real* pointer value, which on 64-bit machines are 64bits. So for now we'll compile for 32bits to achieve complete cross-platform compatibility of game files. */ ``` I stumbled on that while working on a couple of tools for parsing `.a3c` files — so I'm pretty interested in knowing more about it. From what I understood, the problem is that the storyfle itself uses 32-bit pointers both in the AMachine as well as in real memory, which lead me to conclude that currently a x64 verions of ARun/WinARun would require to translate these to 64 bit pointers when handling real memory (ie. outside the Alan VM). Is that correct?

Both compiler and the interpreter can be built on any 64-bit operating system. I constantly use Windows 64-bit, WSL, Cygwin64 and Msys2 on that, as well as MacOS (which has been 64-bit for a long time) and various 64-bit Linux (primarily Ubuntu-based but some other flavours as well). The compiler happily runs as a full-blown 64-bit program but the interpreter currently requires a 32-bit compile (using '-m32', which is necessary to make the memory model to be 32-bits). This option is available on all the flavours of OSes mentioned above, and does not require a 32-bit OS to run.

What will happen when finally Ubuntu drops the 32-bit drivers support on x64 Ubuntu? I hadn't had a chance to read in depth the issue (neither I know Ubuntu well enough), but I've read that many 32-bit apps will stop working on x64 machines, including Wine. Would this affect also using the Alan compiler and interpreter, being 32-bit apps? If that is the case, it would be a big blow (as indeed the new has been for many companies selling 32-bit software for Ubuntu, including Steam).

On Windows, though, I have currently selected to only produce 32-bit releases since they are compatible with both 32- and 64-bit Windowses. That might change in the future. But again, it is fully possible to compile a 32-bit application

I agree that releasing 32-bit only apps is more than sufficient, and reduces maintenance work. Also, the benefits of x64 binaries will be barely noticeable, except that they will be bigger in size. For the time being, until this issue of Ubuntu dropping x32 support on x64, I opted for a safe approach on Travis and chose Windows OS environment (which will ALWAYS run 32 bit apps). Travis offers only x64 enviroments, and only Ubuntu flavours, so when Ubuntu drops 32 bit support we might face some issues. [acode]: https://bitbucket.org/alanif/alan/src/master/interpreter/acode.h "View source file"

[tajmone]

(for some reason, GitHub markdown renderer seems broken and the above reply is not being formatted).

[thoni56]

It's not exactly true that Alan requires a 32-bit OS. It is true that the AMachine uses 32-bit words,
but does not necessarily require a 32-bit environment.
I mentioned that because of the note in the source code

typedef uint32_t Aptr;       /* Type for an ACODE pointer used in the
                               structures */
/* TODO: Here's the major 32->64bit problem: Aptrs are 32 bit to fit
  into the 32-bit structure of the Amachine, but sometimes this is
  used to store a *real* pointer value, which on 64-bit machines are
  64bits. So for now we'll compile for 32bits to achieve complete
  cross-platform compatibility of game files.
*/

Yes that is true, and the core of the "issue" Alan has with wider memory addresses. But this means that it compiles into a memory space spanning 2^32-1 32-bit words.

As far as I can understand from the later posts on the subject (like this one) Ubuntu's initial decision has been revoked, although not forever. But still I read it like the primary intention was to not support (=ship) 32-bit versions of the OS. Although this might imply that all 32-bit versions of libraries would also be killed, but that is not explicitly expressed as far as I can see. Also, if forced to, I'm sure someone would step up and create 32-bit runtime libraries, it is FOSS, after all.

And a third point here is that Alan already has some fixes for this. In memory.c there is code that create a map of Aptr (virtual adresses) to actual native adresses. I'm not sure (since my work on Alan is intermittent so I forget), but it might actually mean that the comment you pointed to is correct in principle, but is no longer a TODO.

Grep'ing through the Makefiles for the interpreter you will only find -m32 when compiling WinArun for Windows. And that is only to build that as a 32-bit Windows application to avoid having to distribute two Windows versions. (We could do that, but in the scope of this "32-bit going obsolete on Ubuntu" it is not relevant.)

In fact, it seems like arun is actually compiled as a 64-bit program:

$ file arun
arun: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l,
for GNU/Linux 2.6.32, BuildID[sha1]=0255d5a2d178210caa7860c8fa14b669f9bb0b06, not stripped

according to my latest WSL build. And it works fine. So, after this long comment, I feel confident that we are already covered ;-)