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).

from alan-by-examples.

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

from alan-by-examples.

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

from alan-by-examples.

from alan-by-examples.

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

from alan-by-examples.

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 ;-)

from alan-by-examples.