Hacker News Reader

Comment by snarfy | Hacker News Reader

Isn't this just moving the goal posts? Now all of your #ifs and the complexity they bring are in your build system.

It already was in the build system. The macros that control conditional compilation when one is doing it with the preprocessor do not appear out of thin air. A build system has to set them appropriately in the first place.

All of the mechanism for auto-detecting (or manually specifying) the capabilities of the target have to be there. It is simply a case of whether they set preprocessor macros via command-line options or tell the build system to use alternative source files.

The latter has the advantage of only creating build dependencies against the modules that actually use the library functionality in question, rather than against the compiler command line and potentially forcing a re-build of everything (when an honest dependencies mechanism is being used).

For gRPC we needed the code to work on all major OS's and had to support a number of different build systems. In no case were the capabilities of the target system manually specified, as that wouldn't have been sustainable. And specifying for each build system what files to include or not for each platform would have been onerous and hard to work with (as the person adding some platform-specific code probably isn't fluent in build systems for other platforms).

So the solution we adopted is a header file that detects the target platform capabilities. And each source file being either platform-agnostic, or specific to one platform. In the latter case, the whole file contents would be #ifdef'd out if compiling for a different platform.

Perhaps there are fewer conditionals in the build than there would be in the code.

But your build system will probably need that platform specific piece anyway, so the question is more "should we have one or multiple switches on platform type".

Reply on news.ycombinator.com