[TEMPORARY] Steps to build Wesnoth

[asimonov-im]

WARNING: The steps below are in constant flux, include numerous hacks and are likely incomplete in certain places!

All required repositories, with the exception of SDL and TouchControlOverlay, are located in my github. Because this is a work in progress, there are quite a few hacks, but we are working to remove them.

First get SDL and TouchControlOverlay from blackberry github. Import them into your workspace, and change TouchControlOverlay to use the GNU runtime instead of the default one. This can be done under the project Properties -> C/C++ Build -> Settings -> Target -> Runtime.

The list of repositories you will need, in rough build order:

• boost_headers (import into NDK)
• boost_program_options (import into NDK)
• boost_regex (import into NDK)
• boost_system (import into NDK)
• boost_iostreams (import into NDK)
• ogg (import into NDK)
• vorbis (import into NDK)
• SDL_image (import into NDK)
• SDL_mixer (import into NDK)
• SDL_net (import into NDK)
• SDL_ttf (import into NDK)
• pixman (don’t import)
• cairo (don’t import)
• libffi (don’t import)
• glib (don’t import)
• pango (don’t import)
• wesnoth (check out the pandafluff branch, import into NDK from projectfiles/qnx)

Clone all projects above into the same directory, and then make a separate workspace directory to import projects into the NDK.

In each of the projects that weren’t imported into the NDK, there should be a build_for_playbook.sh script that basically sets up the environment variables and runs configure and make. They all expect to install themselves in a directory called install at the same level as all the projects. However, there are a few additional problems.

You can build all the NDK projects, except boost_headers – it’s a header only project which is not meant to be built. Make sure TouchControlOverlay builds with the same build configurations as all other projects (either Device-Debug or Device-Release) and uses the GNU runtime. Don’t build wesnoth yet.

Hacks

You will need to get libintl.h from here and copy it to your NDK include directory - bbndk-2.0.0/target/qnx6/usr/include. The library is present on the device, but its header is missing from the current version of the NDK (should be in future versions though).

There are three pkgconfig files that you need to add manually to install/lib/pkgconfig before you can build cairo and wesnoth. You can create your own or get them here. Everything’s already in the NDK folders, there’s just no pkgconfig file to point to them. Cairo needs the libpng.pc and wesnoth needs freetype2.pc and fontconfig.pc.

Glib is also messy, since it has a few issues with cross compilation. In particular, you will need a HOST version of glib-compile-resources and glib-genmarshal. These don’t necessarily come with the devel packages so you may need to compile glib the normal way and install it to somewhere in your path so glib will work. If you feel like it, you may be able to get away with disabling the compilation of glib tests instead.

You may also encounter problems with older versions of libtool and autoconf – these repositories are the latest releases of everything, with as few changes for PlayBook as possible, so I’ve had difficulties with older versions in some cases.

Wesnoth is a special case. It builds with cmake, but I’ve wrapped the cmake build with a NDK project. I may not have wrapped it in a completely portable way, so basically look in the common.mk file to see how I call the cmake build (through build_for_playbook.sh, but with lots of options).

In terms of running, pango may give you problems, since it needs to be able to run pango-querymodules and generate the pango.modules file.

[NichtJens]

Hi!
I built Wesnoth according to your manual, and it actually works! :)

I made some notes and wrote some shell scripts to simplify the compilation. Maybe they are of some help for others, or the future development of this port, so I put them here:
https://github.com/NichtJens/wnbbpb-helper

So, the questions I have:
(1.) I'm not really sure whether my Pango solution is good or not. I followed the manual of the old port for it.
Is there a simpler way to do this?

(2.) I could not get it working with the separate workspace and clone-into directories you mention in the manual.
Does the way I did it provide any problem besides the SDL vs. SDL12 directory?

(3.) I had problems for pixman and pango with libtool versions.
Are these correctly solved the way I solved them, or is this problematic?

(4.) I do not really understand how to create the assets part in the bar-descriptor.xml correctly.
Is there a manual? For now I just did it with a shell script, and for the data-files by manually copying, as in the old manual ...

Finally, please have a look at the note on the Wesnoth build_for_playbook.sh - is this just a typo? If so, maybe you should correct it in your repo!?

[NichtJens]

Ah, I forgot:
I can only build the Device-Debug configuration. Device-Release stops with:

workspace/wesnoth/src/lua/lcode.c:243: error: 'v' may be used uninitialized in this function

... which does not make the slightest sense to me, as:

1. It works in the debug build.
2. It seems it's impossible for this 'v' to be uninitialized, as it's one of the functions arguments.

So - some more questions:
(5.) Is there any reason (say e.g. performance or file size) to prefer the release build over the debug build?
(6.) Why does the same error not occur in the debug build?
(7.) How does one get rid of it?

[jnicholl]

1. I'm really not sure. I wrote the manual for the old port as well, so ... I don't know if there is a better way. Something to investigate.
2. I think the only problem is the SDL vs SDL12, but this could lead to future problems if there are other projects whose base directory does not match the project name.
3. That looks correct.
4. There is an interface in the IDE to add assets to the BAR file, either way works.

Yes, it's a typo. Good catch!

-----Original Message-----
From: NichtJens [mailto:[email protected]]
Sent: Thursday, April 05, 2012 12:13 PM
To: Jeremy Nicholl
Subject: Re: [wesnoth] [TEMPORARY] Steps to build Wesnoth (#1)

Hi!
I built Wesnoth according to your manual, and it actually works! :)

I made some notes and wrote some shell scripts to simplify the compilation. Maybe they are of some help for others, or the future development of this port, so I put them here:
https://github.com/NichtJens/wnbbpb-helper

So, the questions I have:

1. I'm not really sure whether my Pango solution is good or not. I followed the manual of the old port for it.
   Is there a simpler way to do this?
2. I could get it working with the separate workspace and clone-into directories you mention in the manual.
   Does the way I did it provide any problem besides the SDL vs. SDL12 directory?
3. I had problems for pixman and pango with libtool versions.
   Are these correctly solved the way I solved them, or is this problematic?
4. I do not really understand how to create the assets part in the bar-descriptor.xml correctly.
   Is there a manual? For now I just did it with a shell script, and for the data-files by hand, as in the old manual ...

Finally, please have a look at the note on the Wesnoth build_for_playbook.sh - is this just a typo? If so, maybe you should correct it in your repo!?

---

Reply to this email directly or view it on GitHub:
https://github.com/asimonov-rim/wesnoth/issues/1#issuecomment-4979853

---

This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

[jnicholl]

Excellent questions. All of this was a work-in-progress so I haven't really tried out release mode. The function is probably being inlined and in one of the places that it's called, it may be uninitialized (according to the compiler). Are there any more messages around the particular error to indicate how it is called?
Performance and file size are both reasons to prefer the release build, I would think. We should try to fix this. :)
Let me know if you can solve it, I will also take a look when I can.

-----Original Message-----
From: NichtJens [mailto:[email protected]]
Sent: Thursday, April 05, 2012 12:34 PM
To: Jeremy Nicholl
Subject: Re: [wesnoth] [TEMPORARY] Steps to build Wesnoth (#1)

Ah, I forgot:
I can only build the Device-Debug configuration. Device-Release stops with:

workspace/wesnoth/src/lua/lcode.c:243: error: 'v' may be used uninitialized in this function

... which does not make the slightest sense to me, as:

1. It works in the debug build.
2. It seems it's impossible for this 'v' to be uninitialized, as it's one of the functions arguments.

So - some more questions:
(5.) Is there any reason (say e.g. performance or file size) to prefer the release build over the debug build?
(6.) Why does the same error not occur in the debug build?
(7.) How does one get rid of it?

---

Reply to this email directly or view it on GitHub:
https://github.com/asimonov-rim/wesnoth/issues/1#issuecomment-4980328

---

This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

[NichtJens]

(1.) Atleast I think having a /etc dir for the pango.modules file next to the /lib dir is a little cleaner (as it mirrors the linux path layout) than the pango dir in the root of the sandbox. Actually I was not allowed to create that anyway ...

(2.) I think now I understand what the intended way to do this is:
I should have imported the project, but without having the files copied to the workspace (by ticking that checkbox). Atleast that's what I did, and now think it was wrong.

(4.) I saw the assets interface, but did not really get how to use it. I will have a further look into it. I think I would prefer some command line tool to add assets to the xml file... Maybe one could whip something together using Python's minidom ...

Anyway, it would probably be better to just have the modules' dir as an asset, and not each file itself, right?

Regarding the release build:
I don't have much idea of what this code does, and the error message does not say anything but that one line ...

But:
I got it to compile (and to run, as far as I can see) by adding one line:

v.value.b = 0;

I guess the variable 'v' is initialized by a function called 'setnilvalue'. The compiler does not see this as an assignment and thus complains. 'v' is a 'TValue', which is a struct containing a 'Value', which is a union containing several other variables, one of them being 'b'. If one does an assignment to any of those variables the compiler stops to complain, I choose the 'b' as it is just an int, while the others are yet more complex things. I guess this does not hurt, as 'setnilvalue' is called afterwards anyway, but on the other hand this has the potential to mess things up. I'm really not sure, as this is a rather complex layered type, and I don't understand much ...

[jnicholl]

1. The sandbox is always a little awkward since you can't deploy files directly to it from the bar file. Possibly app/native/etc as a path, and place it in an etc subfolder when packaging?
2. Sorry. I missed that you had checked the copy option. That's the problem, you're right. I'm not sure how to prevent people from doing this.
3. There should be a way to upload whole folders using the assets interface. Edit the bar-descriptor xml file, go to the assets tab. There should be a list of build configurations at the top and a list of files for the selected build configuration below, and you can add to the list of files (you can add folders too).
   Writing a tool is okay, since the xml is pretty simple, it may need maintenance however since the format may slightly change over time.

----- Original Message -----
From: NichtJens [mailto:[email protected]]
Sent: Friday, April 06, 2012 01:05 PM
To: Jeremy Nicholl
Subject: Re: [wesnoth] [TEMPORARY] Steps to build Wesnoth (#1)

1. Atleast I think having a /etc dir for the pango.modules file next to the /lib dir is a little cleaner (as it mirrors the linux path layout) than the pango dir in the root of the sandbox. Actually I was not allowed to create that anyway ...
2. I think now I understand what the intended way to do this is:
   I should have imported the project, but without having the files copied to the workspace (by ticking that checkbox). Atleast that's what I did, and now think it was wrong.
3. I saw the assets interface, but did not really get how to use it. I will have a further look into it. I think I would prefer some command line tool to add assets to the xml file... Maybe one could whip something together using Python's minidom ...

Anyway, it would probably be better to just have the modules' dir as an asset, and not each file itself, right?

Regarding the release build:
I don't have much idea of what this code does, and the error message does not say anything but that one line ...

But:
I got it to compile (and to run, as far as I can see) by adding one line:

v.value.b = 0;

I guess the variable 'v' is initialized by a function called 'setnilvalue'. The compiler does not see this as an assignment and thus complains. 'v' is a 'TValue', which is a struct containing a 'Value', which is a union containing several other variables, one of them being 'b'. If one does an assignment to any of those variables the compiler stops to complain, I choose the 'b' as it is just an int, while the others are yet more complex things. I guess this does not hurt, as 'setnilvalue' is called afterwards anyway, but on the other hand this has the potential to mess things up. I'm really not sure, as this is a rather complex layered type, and I don't understand much ...

---

Reply to this email directly or view it on GitHub:
https://github.com/asimonov-rim/wesnoth/issues/1#issuecomment-4998703

---

This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

[NichtJens]

(1.) Yes, exactly - that's what I did. See:
https://github.com/NichtJens/wnbbpb-helper/blob/master/pango.patch
https://github.com/NichtJens/wnbbpb-helper/blob/master/pangomodules-assests.sh
That's what I meant with mirroring the linux layout...

(2.) Maybe one could clarify this step, like so:
Clone all projects above into one directory, and then import the projects into a separate workspace directory (without ticking the "Copy projects into workspace" checkbox).

(4.) Okay, I'll have another look at this. One last question about it: Is it possible to replace the absolute path with something generic? If we use separated directories as in 2. I guess we can't use ${workspace_loc:... There is no variable holding the building directory, is there?

[xsacha]

NightJens, if you want to add a directory (like lib/modules), you can just add the directory name as an asset. No need to add the 16 or so libraries individually.
So instead of running that script, the asset could already be included in the bar-descriptor.xml.

[NichtJens]

Yes, thanks for noting that ...

Actually that was what I meant when I wrote earlier:

Anyway, it would probably be better to just have the modules' dir as an asset, and not each file itself, right?

... I just didn't bother trying.