# Build with specified features

This topic is 1567 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi,

Let's assume that I have big project with lots of components (GUI with Multimap, Widgets, etc, Data  with loading, texture mangers, etc).
Now I want to create SECOND build - ie demo - with only part of functionality (GUI without minimap, data with fixed textures, etc). I could easily achieve that with preprocessor defines, but it will be ugly. Still achievable.

Ok, now something difficult. My boss tell me to create build to create GameEditor. Again - I could place multiple defines to separate functionality/features specific for each of those 3 build configuration. But it will populate code with more trash/gibberish.

How can I create make system to generate build based of some kind of features lists to contain in given build.

Other solution is to make special care to separate features so one FILE/CLASS would contain only one feature (possible but not so easy to achieve). Then in some file I could place list of files or feature tag, so make during file gathering would take only files matching features ID.

##### Share on other sites
Several build system generators (like for example CMake) should be up to the job but introducing them retroactively will probably be an uphill battle. Edited by BitMaster

##### Share on other sites

For instance, in my home project, I can do this:

void initialize() {
CreateService<IGraphics, GLGraphics>();
CreateService<IAudio, ALAudio>();
CreateService<IInput, SDLInput>();

#if !defined(NDEBUG)
CreateService<IDebug, AntTweakBarDebug>();
CreateService<IProfiler, TelemetryProfiler>();
#endif
}
And that's it. The linker will deal with stripping out the unused service implementations. No other code has to change. It's just these few lines in the app initialization code that have to be removed.

##### Share on other sites

@SeanMiddleditch - this will work quite well for selection of bigger components.

What about application with different versions? I mean trial (with blocked most of higher functionality), common, professional or ultimate versions? And we're not talking about simple code/serial unlock, but separate version for each. Yes, with proper architecture design I could hide those specific behaviors behind interface and use plugin approach. Situation became more complicated where in one file/class few functionalities crosses

You have - for example - only one file reading format, only one net protocol, only one configuration, etc. I would like to have situation where I can create build (with help of CI/Jenkins) which will always create all possible versions.

@BitMaster - building engine/tool isn't a problem. It doesn't matter if I use make/CMake or whatever else. Problem with selection files for different releases is the same. Do it manually, semi automatic or fully automatic.

Edited by T4ng10r

##### Share on other sites

Unfortunately, given how often the requirements for these "special" kinds of builds (public demo, trial version, alpha, beta, standard, expansion, editor, etc.) can be completely arbitrary and determined by the developer/publisher at later points in the project, if often does become a matter of sprinkling #ifdef's around the code (or runtime checks if appropriate) to disable/enable/tweak functionality. On the content side, it makes a lot of sense to have a filesystem that allows you to separate your data into multiple physical files, so you only need to distribute the right content for each build, and allow content from one package be able to "override" content from another package. This also allows you to easily patch content for bug fixes, expansions, DLC, whatever. On the code side, you can always try to plan ahead and split subsystems apart such that they can be turned on and off wholesale, but it's often not going to be enough if the game's functionality isn't fundamentally different for each build.

The editor build is usually more straightforward because it's often just the game with an additional editor interface on top, whether that be in-game or done as a separate application. However what you need to do in order to get this work, will depend on the specifics of your project.

##### Share on other sites

Yes. Even further - when during development I receive this kind of requirements I imagine whole lot of ifdef polluting my code.
Seperate approach would be to use strategy design pattern or separate functionality in files stored in folders with recognizable name  (demos, dlc, etc) which later on will be taken by build mechanism.

##### Share on other sites

It's typically not too bad. In my experience, most of the differences between builds boil down to data, or can otherwise be data-driven (which is where a robust asset and file management system comes in handy). Only in special cases where the developer absolutely needs/wants code excluded from the build are #ifdef's deployed.

##### Share on other sites

In my team we discussed few approaches.

Dynamically selected features - activated during run-time by configuration files or detected system values. Rejected - we can't allow our binary to grow for one of possible releases due to memory constraints (embedded system with low memory).

Statically selected features - by file locations (folder name) or if_defs. Second one - we want to avoid introducing ifdefs (in code we have almost none of them) because developers will easily overuse them. First approach is used right know and is candidate to be used further.

Is there ANY possible framework which uses marks or tags (i.e. @REL1/2/3/4 in files to select files (or part of file) for compile? I mean - some kind of extra pre-configuration step in buildchain which will provide list of files?

• ### What is your GameDev Story?

In 2019 we are celebrating 20 years of GameDev.net! Share your GameDev Story with us.

• 15
• 14
• 10
• 9
• 11
• ### Forum Statistics

• Total Topics
634096
• Total Posts
3015493
×