Cross-Platform C single header file and multiple implementations

bobveringa 0
Viewed 81

I am working on an open source C driver for a cheap sensor that is used mostly for Arduino projects. The project is set up in such a way that it is possible to support multiple platforms outside the Arduino ecosystem, like the Raspberry Pi.

The project is set up with a platform.h file, with the intention of having different implementations of this header file. Like the example below:

platform.h
platform_arduino.c
platform_rpi.c
platform_windows.c

There is this (Cross-Platform C++ code and single header - multiple implementations) Stack Overflow post that goes fairly in depth in how to handle this for C++ but I feel like none of those examples really apply to this C implementation.

I have come up with some solutions like just adding the requirements for each platform at the top of the file.

#if SOME_REQUIREMENT
#include  "platform.h"

int8_t  t_open(void)
{
    // Implementation here
}

#endif //SOME_REQUIREMENT

But this seems like a clunky solution.

  • It impacts readability of the code.1
  • It will probably make debugging conflicting requirements a nightmare.

1 Many editors (Like VS Code) try to gray out code which does not match requirements. While I want this most of the time, it is really annoying when working on cross-platform drivers. I could just disable it for the entirety of the project, but in other parts of the project it is useful. I understand that it could probably be solved using VS Code thing. However, I am asking for alternative methods of selecting the right file/code for the platform because I am interested in seeing what other strategies there are.

Part of the "problem" is that support for Arduino is the primary focus, which means it can't easily be solved with makefile magic. My question is, what are alternative ways of implementing a solution to this problem, that are still readable?

If it cannot be done without makefile magic, then that is an answer too.

For reference, here is a simplified example of the header file and implementation

platform.h

#ifndef __PLATFORM__
#define  __PLATFORM__

int8_t  t_open(void);

#endif //__PLATFORM__

platform_arduino.c

#include  "platform.h"


int8_t  t_open(void)
{
    // Implementation here
}
arduino c
1 Answers

this (Cross-Platform C++ code and single header - multiple implementations) Stack Overflow post that goes fairly in depth in how to handle this for C++ but I feel like none of those examples really apply to this C implementation.

I don't see why you say that. The first suggestions in the two highest-scoring answers are variations on the idea of using conditional macros, which not only is valid in C, but is a traditional approach. You yourself present an alternative along these lines.

Part of the "problem" is that support for Arduino is the primary focus, which means it can't easily be solved with makefile magic.

I take you to mean that the approach to platform adaptation has to be encoded somehow into the C source, as opposed to being handled via the build system. Frankly, this is an unusual constraint, except inasmuch as it can be addressed by use of the various system-identification macros provided by C compilers of interest.

Even if you don't want to rely specifically on makefiles, you should consider attributing some responsibility to the build system, which you can do even without knowing specifically what build system that is. For example, you can designate macro names, such as for_windows, etc that request builds for non-default platforms. You then leave it to the person building an instance of the driver to figure out how to configure their tools to provide the appropriate macro definition for their needs (which generally is not hard), based on your build documentation.

My question is, what are alternative ways of implementing a solution to this problem, that are still readable?

If the solution needs to be embodied entirely in the C source, then you have three main alternatives:

  • write code that just works correctly on all platforms, or
  • perform runtime detection and adaptation, or
  • use conditional compilation based on macros automatically defined by supported compilers.

If you're prepared to rely on macro definitions supplied by the user at build time, then the last becomes simply

  • use conditional compilation

Do not dismiss the first out of hand, but it can be a difficult path, and it might not be fully possible for your particular problem (and probably isn't if you're writing a driver or other code for a freestanding implementation).

Runtime adaptation could be viewed as a specific case of code that just works, but what I have in mind for this is a higher level of organization that performs runtime analysis of the host environment and chooses function variants and internal parameters suited to that, as opposed to those choices being made at compile time. This is a real thing that is occasionally done, but it may or may not be viable for your particular case.

On the other hand, conditional compilation is the traditional basis for platform adaptation in C, and the general form does not have the caveat of the other two that it might or might not work in your particular situation. The level of readability and maintainability you achieve this way is a function of the details of how you implement it.

I have come up with some solutions like just adding the requirements for each platform at the top of the file. [...] But this seems like a clunky solution.

If you must include a source file in your build but you don't want anything in it to actually contribute to the target then that's exactly what you must do. You complain that "It will probably make debugging conflicting requirements a nightmare", but to the extent that that's a genuine issue, I think it's not so much a question of syntax as of the whole different code for different platforms plan.

You also complain that the conditional compilation option might be a practical difficulty for you with your choice of development tools. It certainly seems to me that there ought to be good workarounds for that available from your tools and development workflow. But if you must have a workaround grounded only in the C language, then there is one (albeit a bad one): introduce a level of preprocessing indirection. That is, put the conditional compilation directives in a different source file, like so:

platform.c

#if defined(for_windows)
#include "platform_windows.c"
#else
#if defined(for_rpi)
#include "platform_rpi.c"
#else
#include "platform_arduino.c"
#endif
#endif

You then designate platform.c as a file to be built, but not (directly) any of the specific-platform files.

This solves your tool-presentation issue because when you are working on one of the platform-specific .c files, the editor is unlikely to be able to tell whether it would actually be included in a build or not.

Do note well that it is widely considered bad practice to #include files containing function implementations, or those not ending with an extension conventionally designating a header. I don't say otherwise about the above, but I would say that if the whole platform.c contains nothing else, then that's about the least bad variation that I can think of within the category.

John Bollinger0
Related