Using Boost Build with Emscripten
Sunday August 11, 2013 23:45:43

A few months back, I tried to use Emscripten, an amazing tool which compiles C++ code to Javascript using LLVM and found it was incredibly easy to install and set up (this may be because I did so on Linux. At this point, I've got a nice workflow using a Ubuntu VM on my Windows box, don't expect a giant blog post on how to make this stuff work on that platform).

Boost Build is my current C++ build tool of choice, so of course I got Emscripten set up as a custom toolset and figured I'd document that simple process here.

If you haven't already, install and configure Emscripten so that you can compile simple C++ apps using it's provided tools directly on the command line. I highly recommend following this tutorial and getting to the point where you can compile hello_world.cpp into a.out.js.

Next, you need to edit your site-config.jam file, typically found in ~/site-config.jam, to contain the following:

 using clang
: emscripten
: /home/tim/Tools/emscripten/em++
: <root>/home/tim/Tools/emscripten
<archiver>/home/tim/Tools/emscripten/emar
<ranlib>/home/tim/Tools/emscripten/emranlib
<linker>/home/tim/Tools/emscripten/emlink
<cxxflags>" -std=c++11 "
<linkflags>"-lstdc++"
;

import type : change-generated-target-suffix ;
type.change-generated-target-suffix EXE : <toolset-clang:version>emscripten : js ;

Hopefully this is obvious, but I installed emscripten to /home/tim/Tools/emscripten- you'll need to change the above filepaths to point to wherever you git cloned emscripten.

The “using clang” section is similar to how I got the KallistiOS Dreamcast compiler to work. The tricky part was
making sure that Boost Build “exe” targets got “.js” appended to them; emscripten will compile to Javascript files only by if the output file extension is “.js”, so without that line things didn't work correctly. (related reading). Another thing to note is that the compiling things with link=static causes numerous archive (“.a”) files to be created, which the official Emscripten docs state to avoid. So for now I'm leaving that option alone when compiling Javascript “executables”.

Another thing that may or may not interest you is unit test support. Now, the Boost Test library won't work with Emscripten, as is the case with many other C++ libraries- it is targeting Javascript after all. However, all the Boost Build “unit-test” rule cares about is that some file is created which is invoked either directly as an executable or using some other tool and results in a zero exit code. This means you can use the “<testing.launcher>” property to specify that Node.JS be used to execute the tests, making it possible to unit test the compiled Javascript.

One more caveat is that in order to keep Node.JS from *always* being used to run the tests even when you're building for a different platform you'll have to define the unit-test rule multiple times, each time with a property noting the given toolset. I created a nifty Macaroni script to automatically add all such targets, but I'm not ready to show it or the game engine off, so for now here's what the generated Jamroot.jam file looks like:

 # Tests
# ---------

# PrimitivesTest
unit-test MACARONI_TEST_TARGET_PrimitivesTest
: # Sources:
/MACARONI_PROJECT_Lp3___Lp3Project___DEV//Lp3Test
Lp3_Core
9342569157862752302
:
;
unit-test MACARONI_TEST_TARGET_PrimitivesTest
: # Sources:
/MACARONI_PROJECT_Lp3___Lp3Project___DEV//Lp3Test
Lp3_Core
9342569157862752302
: <toolset-gcc:version>dreamcast
<testing.launcher>"dctest "
;
unit-test MACARONI_TEST_TARGET_PrimitivesTest
: # Sources:
/MACARONI_PROJECT_Lp3___Lp3Project___DEV//Lp3Test
Lp3_Core
9342569157862752302
: <toolset-clang:version>emscripten
<testing.launcher>"node "
;



The Physical Structure of C++ Programs
Saturday June 15, 2013 18:07:35

Every programmer knows about the logical structure of the code they write, but most aren't even aware about the concept of “physical structure” in program code.

“Physical structure” problems only arise when programming languages have to use processor to include other files. The only example of this that really matters is C and C++, where the #include directive is necessary to make use of code in another compilation unit or library. Other modern languages, such as C# or Java, don't have these issues.

This article on mitigating problems with the physical structure of C++ programs is one of the best reads on the topic I've ever encountered, and is recommended if you program in C or C++.

I started work on Macaroni for C++ years ago because I was sick of copying and pasting to create header files, wasting LOC on include guards, or other grostesque preprocessor crap, and that was before I had to spend time adding boilerplate for features similar to reflection. At the time I was starting to prefer writing C++ to C#, buthaving to define so much stuff for the processor took all the fun out of it.

These days, Macaroni is finished enough that I feel confident using it on big projects.C++ still takes longer to write than Java or C#, but more because the language demands that I, as a coder, know what I'm doing and state things precisely. The benefit is the resulting code is usually more expressive and readable than Java or C# and has a staggering amount of portability.

One issue I'm now seeing with Macaroni is because it enables writing C++ code faster and more succinctly, it makes it easier to write it like C# and ignore the resulting physical structure of the generated source. This could lead to projects that resemble balls of mud and have longer compile times.

Thankfully, Macaroni also makes it easier to write well physically structured C++ code since it has tricks like the “~hidden” keyword to hide class functions in the “Cpp-only” version of the class definition, as well as the ~block keyword which makes it easy to add helper functions to a class in an anonymous namespace. Today, Macaroni makes a good effort to use forward declarations instead of #include directives if it detects the later is unnecessary, but in the future I'd like to also generate its library-wide config header files with precompiled header support for appropriate platforms.

The problem of code's physical structure is something that makes C++ more difficult to use compared to it's newer native language rivals. I'd I'd love it if Macaroni could alleviate this and make C++ a more attractive choice for non-believers.



Sublime Text user settings
Thursday May 23, 2013 04:30:07

Sublime Text is my favorite text editor of all time. Here's what my user settings file looks like:

 {
"caret_style": "phase",
"color_scheme": "Packages/Color Scheme - Default/Monokai.tmTheme",
"ensure_newline_at_eof_on_save": true,
"fade_fold_buttons": false,
"flatland_sidebar_tree_small": true,
"flatland_square_tabs": true,
"font_face": "Inconsolata",
"font_size": 12,
"gutter": true,
"highlight_line": true,
"line_padding_bottom": 0,
"line_padding_top": 0,
"rulers":
[
80,
120,
160
],
"save_on_focus_lost": true,
"sentinel": true,
"tab_size": 4,
"theme": "Flatland Dark.sublime-theme",
"translate_tabs_to_spaces": true,
"trim_trailing_white_space_on_save": true
}

These settings standardize white space, cutting back on merge conflicts. It establishes rulers to help keep code down to 80 columns (yeah it's the year 2013 and we have widescreen monitors blah blah blah but an 80 column limit just looks better. It also makes it easier to view two panels of text at once). I'm more iffy on “save_on_focus_lost”- for most projects I enjoy it, but sometimes it can cause needless recompilation in C++ (this is solved in Macaroni, as it checks to see if the destination file is different before replacing it).

Updated on 2013-11-27: I didn't Sublime could look any prettier, but changed my mind after being introduce to the Flatlands theme by my coworkers. The big change with this theme is that the folder navigation pane gets blue icons. The best part about it is that you can make both the new icons and text smaller, making it easier to navigate large projects.

I also began using the Inconsolata font which looks only a little bit better than the default font on Mac's but is gorgeous on Windows.



Retron 5 will play GBA games, output in HDMI
Sunday March 24, 2013 14:49:20

The past half decade has offered a plethora of “retro” systems designed to be clones of the SNES, NES, and Genesis. Many of these have been two or three in ones, such as the Retro Duo or Retron 3. However, most have been plagued with less than perfect game compatibility and build quality issues. Additionally, none really offered anything new, other than crappy clone controllers which felt worse than the originals.

The recently announced Retron 5 looks to fix that with a number of features unique to the retro system space, such as a wireless Bluetooth (instead of flaky infrared) controllers in addition to original controls and the ability to remap buttons for any controller to any game (this is a feat Nintendo only recently remembered how to do). It also will output to HDMI and includes graphics and sound filters in an attempt to make old games not look like garbage on new TVs.

Most importantly though is it's ability to play Gameboy Advance games! I own close to 50 GBA games so it's nice to finally see someone make a decent alternative to the Gameboy Player, which while a competent product looks terrible on HDTVs and doesn't allow for configurable controls. This last point was alleviated somewhat by Hori's Gameboy Player controller, until mine broke (one of three times I've ever had a controller break). I thankfully had bought a backup years ago for $20, but to this day am afraid to open it since they now cost $200 on e-bay.

Now the only question is whether or not this thing will play Mother 3…






<---2013-12-08 22:30:09 history 2013-03-10 20:28:03--->



-All material © 2007 Tim Simpson unless otherwise noted-