Отслеживание вариантов исходного кода

Вы должны стараться, насколько это возможно, хранить индивидуальный код каждого варианта в отдельном наборе файлов. Затем ваша система сборки (Makefile или что-то еще) выбирает, какие источники использовать, в зависимости от того, какой вариант вы строите.

Преимущество этого заключается в том, что при работе над конкретным вариантом вы видите весь его код вместе, без других вариантов » код там, чтобы запутать вещи. Удобочитаемость также намного лучше, чем засорение исходного кода #ifdef, #elif, #endif и т. Д.

Ветви работают лучше всего, когда вы знаете, что в будущем вы захотите объединить весь код из ветвь в главную ветку (или другие ветки). Это не работает только для слияния некоторых изменений от ветки к ветке (хотя это, безусловно, можно сделать).

Я не уверен, что это «лучшая практика», но в проекте Scintilla в течение многих лет используется что-то, что все еще вполне управляемо. У него есть только одна ветка, общая для всех платформ (в основном Windows / GTK + / Mac, но с вариантами для VMS, Fox и т. Д.).

Так или иначе, он использует первый вариант, который довольно распространен: он использует определения для небольшого управления специфические для платформы части внутри исходных текстов, где нецелесообразно или невозможно разместить общий код.
Обратите внимание, что этот параметр недоступен для некоторых языков (например, Java).

Но основным механизмом переносимости является использование объектно-ориентированного подхода: он абстрагирует некоторые операции (рисование, отображение контекстного меню и т. Д.) И использует файл платформы (или несколько) на цель, обеспечивая конкретную реализацию.
Makefile компилирует только правильный файл (ы) и использует ссылку для получения правильного кода.

Я думаю, что правильный ответ частично зависит от того, насколько радикально отличаются варианты.

Если есть небольшие части, которые отличаются, использование условной компиляции для одного исходного файла является разумным. Если варианты реализации согласованы только в интерфейсе вызова, то может быть лучше использовать отдельные файлы. Вы можете включить радикально измененные реализации в один файл с условной компиляцией; насколько это запутано, зависит от объема кода варианта. Если это, скажем, четыре варианта по 100 строк в каждом, возможно, один файл в порядке. Если это четыре варианта по 100, 300, 500 и 900 строк, то один файл, вероятно, плохая идея.

Вам не обязательно нужны варианты в разных ветвях; действительно, вы должны использовать ветки только тогда, когда это необходимо (но не используйте их, когда они необходимы!). У вас может быть четыре файла, скажем, все в общей ветке, всегда видимые. Вы можете организовать компиляцию, чтобы подобрать правильный вариант. Одна из возможностей (есть много других) - это скомпилировать единственный исходный файл, который знает, какой вариант исходного кода включить в текущую среду компиляции:

#include "config.h"
#if defined(USE_VARIANT_A)
#include "variant_a.c"
#elif defined(USE_VARIANT_B)
#include "variant_b.c"
#else
#include "basecase.c"
#endif

Вас ждет мир боли!

Что бы вы ни делали, вам нужна автоматическая сборка среда. По крайней мере, вам нужен какой-то автоматический способ создания всех различных версий вашей прошивки. У меня были проблемы с исправлением ошибки в одной версии и нарушением сборки другой версии.

В идеале вы могли бы загрузить различные цели и запустить некоторые дымовые тесты.

Если вы пойдете по маршруту #define , Я бы поместил следующее место, где проверяется вариант:

#else 
    #error You MUST specify a variant!
#endif

Это обеспечит создание всех файлов для одного и того же варианта в процессе сборки.