Target platform and build systems

Stainless 151 Jun 23, 2013 at 09:09

Since AGP is binary portable, I don’t have to deal with multiple target platforms anymore.

However I do have to port other peoples code a lot, so I come across several different approaches.

The three main ones I come across are…

  • Linux style configure (run a tool)
  • Header based (define a platform code and use #if defined(__TARGET_PLATFORM__)
  • Manual (do it all by hand)

All have their problems

The tool based solution requires all the source code to be in the correct path, often this isn’t the case when it gets to me

The header based system is a pain in the proverbial as you often end up having to guess which files to include at first and if you miss an instance you may get strange errors that are hard to track down.

The manual system is the worst. The only way to port it is to stick everything in and deal with each compiler error one at a time.

Has anyone come across a better system?

6 Replies

Please log in or register to post a reply.

Reedbeta 167 Jun 24, 2013 at 01:10

I lean toward the #ifdef version as the least bad alternative…requiring an external tool just seems gross to me, I guess it’s common practice in Linux but I would rather my code be more self-contained. Of course it does still require putting in the right platform token in the project settings, makefile, etc.

Visual Studio, GCC, and (I think) Clang all now support “#pragma message” which allows you to print a custom message from the preprocessor, so you can use this to write headers that will warn you if some required token is not defined. At least some of the compilers even have an “#error” directive that generates a compiler error, and can be used to stop compilation in such a case.

Beyond that, I think good documentation in a README or in comments of the headers, about what build environment your code expects, is about the best you can do.

Stainless 151 Jun 24, 2013 at 08:03

Ahh yes, the one thing I NEVERget……….. documentation

fireside 141 Jun 24, 2013 at 10:13

Ha ha. It is hard to come by most of the time. First thing I check for when I’m picking out an engine. It’s amazing how many people think it’s unnecessary.

Albertone 101 Jun 24, 2013 at 13:14

An interesting topic, closely related, in my opinion, to the broad, and much neglected, field of “physical design”: the only book on this argument I can think of is the old “Large Scale C++ Software Design” by John Lakos. Another book with valuable information is “Writing Portable Code” by Brian Hook. By the way: does anyone use the if() instead of #ifdef, as explained on page 94 of this Valve paper:

TheNut 179 Jun 24, 2013 at 14:12

A good build engineer will keep his build system simple. That means the code base should also be self-sufficient and not rely on a lot of external factors (Google, take note!). If they do, then like Reed said they should document it. Nevertheless, in your case Steel it does seem like a manual effort. If you need to port code, there’s not a whole lot you could do other than make the necessary modifications to get it working.

Stainless 151 Jun 24, 2013 at 14:36

I better not say which companies code this is, for obvious reasons, :rolleyes:

They do have 800 staff at the office I went to last week, so I hoped the code was in a better state.

However it’s not, if you try to build an OpenGLES 2 version, it includes OpenGLES 1.1 files

They use a bunch of text files which are parsed by a custom tool to generate the visual studio project and solution files.
Then the actual source code is full of a mix of #ifdef FLAG and #if defined(FLAG) to get the actual code files required into the build

it’s a mess as usual.
and I have to get something working in two weeks.

Anybody looking for an expensive games coder? :D