Add color to Boost Build with BJolt
Wednesday November 27, 2013 15:58:25

I recently added CMake support to Macaroni after growing incredibly frustrated with how long it took to compile some apps with Boost Build on my ancient Acer Aspire One. Because CMake can generate Visual Studio project files, this meant I was able to easily work on Macaroni projects again in Visual Studio.

Unfortunately, Visual Studio 2013 seems to have be more hostile towards Macaroni than its 2008 iteration; syntax is still correctly highlighted, but the IDE adds scribbles to almost everything. Worst of all, it refuses to jump to errors in Macaroni source code when you click on them in the IDE even though it's own compiler is outputting the appropriate lines. I actually used to use VS2008 with Macaroni all the time several years ago and had a good experience, so VS2013's intolerance for mcpp files (possibly arising from the fact it's improved as a C++ IDE) is a bit sad. The end result is I stick to Sublime and the command line when writing and testing code and use VS2013 when I need the debugger.

However, not being able to click on those errors really was a bummer, and perhaps its what led me do something to improve the experience of using Boost Build on the command line. The worst part of using it today is that while Macaroni itself has colorized output, when it runs Boost Build the affair is strictly monochromatic, meaning I've gotten very good at scanning through dozens or even hundreds of lines of text to find the one or two error messages that caused the failure. It looks something like this:

So, in about two mornings worth of time last weekend I created Bjolt, which runs bjam and colorizes its output as well as formatting long lines to make them easier to read in Windows. Now it looks more like this:

So far it finds errors and warning from the Visual C++ compiler and linker, as well as error messages from Boost Test. In the future I'll probably add support for GCC and Clang (ironically Clang has beautiful colorization, but Boost Build unfortunately ruins it).

Download Bjolt here.



Solace comforts sufferers of the Windows Console
Sunday August 25, 2013 03:20:19

Here's a tool I whipped up this afternoon in order to spruce up using the Windows command line console as well as create an easy-to-grok example project for Macaroni for C++.

The Windows console has a palette of 16 colors. While it's easy to switch the foreground and background colors between the various 16 choices on the command line using the color shell command, altering the palette itself is a huge hassle and involves clicking around in Windows 95 era GUIs. Using a modified palette routinely introduces other hassles as the colors may not work for all programs. Finally, there's no way to switch between palettes in an active session, and when you're juggling multiple command line sessions the ability to switch to a unique color scheme is crucial to maintaining sanity.

There are several pretty decent Windows command prompt replacements out there, but none ever clicked for me personally. So I always find myself using the standard command prompt and hating the lack of colors (and tabs, but I didn't write a program to fix that so we won't discuss that today).

Coding Solace

I went looking around for a program to change the built in palette of colors from the command line and found a tool called consattr which seemed to do exactly what I needed, but alas it didn't work in Windows Vista onward (I think- the page is a bit out of date). However, the author derelict did include a note on a Windows API call named “SetConsolePalette”, which lead me to a source file from catch22.net that included a note referencing a new Vista API called SetConsoleScreenBufferEx, and at that point I figured writing a program myself might not be that difficult.

The big trick, as usual, was mitigating the pathological edge case bugs that seem to exist in all Windows APIs (the call to change the color palette moves the window for some reason, so code had to be written to move it back), but with a little bit of Googling and elbow grease I got it done in a few hours.

Even though Solace is Windows only, I hope it might serve as a decent example of how to use Macaroni as it is both simple enough to understand but also manages to accomplish something worth doing. A unique thing about the project's code is that I tried to keep all of the source to one single file, though I did move some external project declarations out as it seemed like better practice. The cool thing is this all worked without any changes to Macaroni, which is not something I could have said two years or even a year ago. Every C++ translation unit necessary to create Solace, including the two main functions for each exe file, comes from a single Macaroni source file. Though it's kind of a cheat to say this since it generates a Boost Build script,the entire project's build configuration is only 15 lines long.

Using Solace

Solace works by writing all the colors used by the current palette to stdout. They can then be scooped up into a file which can be loaded later.

The file format is just the palette index, an equals sign, and the three RGB values seperated by spaces and ending with a newline.

Once you create a few color schemes you like, it's easy to write a batch file like the following to load them:

 solace-load coffee.solace
color 07

Put that in a file called “coffee.bat” somewhere in your path and you've got a quick way to put a color scheme into effect whenever you need it. Make a few of these and the color experience approaches something usually seen only on Linux or OSX.



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.





<---2014-02-23 18:00:58 history 2013-05-23 04:30:07--->



-All material © 2007 Tim Simpson unless otherwise noted-