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

Я бы постарался использовать #define как можно чаще. С правильным кодом вы можете свести к минимуму влияние на читабельность и повторения.

Но в то же время подход #define можно смело сочетать с разделением и ветвлением, применение которых зависит от характера кодовой базы.

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

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

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

Если вы используете вышеупомянутый подход, вам не нужно пытаться использовать такие трюки в вашем контроле версий для поддержки организации вашего кода.

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

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

Но основным механизмом переносимости является использование объектно-ориентированного программирования: он абстрагирует некоторые операции (рисование, отображение контекстного меню и т. д.) и использует файл платформы (или несколько) для каждой цели, обеспечивая конкретную реализацию.
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

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

Я столкнулся с той же проблемой. Я хочу делиться исходным кодом не только между целевыми объектами, но и между платформами (например, Mono и Visual Studio. Кажется, что нет никакого способа легко сделать это только с версией, которую ветвление/тегирование предоставляет Git. Потому что в идеале вы "Хотелось бы поддерживать общую ветку кода и ветки, специфичные для хоста/цели, и просто объединять общий код в этих ветках и из них. Но я не знаю, как это сделать. Может быть, комбинация ветвления и тегов? Кто-нибудь?"

Очевидно, я бы использовал компиляцию условий, если бы это было необходимо там, где я мог бы, чтобы был только один исходный файл под контролем версий, но для других файлов, которые должны появляться только в одной хост-/целевой ветке или там, где содержимое быть совершенно другим, нужен другой механизм. Если вы можете использовать методы ООП, чтобы обойти проблему, это тоже было бы желательно.

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