Hacker News Reader

Comment by fanf2 | Hacker News Reader

I’ve been maintaining unifdef since about 2001. One of the rules I have set myself is to never use #if in unifdef. It’s an easy program to port, so this isn’t very hard :-) but Microsoft’s appalling C libraries make it more painful than it should be.

The main technique is to set the include path depending on the behaviour of the target platform, and have per-platform variant header files. For unifdef, this basically means standard vs windows.

The other thing I don’t have to deal with is build-time configuration options or feature switches. It’s easy to get into a combinatorial explosion with #if but kinda hard if you force yourself to reify each option as a pair of include files!

View on HN

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