#python #c #bash #environment-variables #shared-libraries
Вопрос:
У меня есть приложение, состоящее из разных слоев и написанное на трех разных языках: c , bash и python РЕДАКТИРОВАНИЕ: на платформе Linux/Raspbian
С тех пор мы управляем разными сборками, в зависимости от платформы, с разными ветвями разработки sw, но я пытаюсь объединить все в одной ветви, чтобы повысить удобство обслуживания.
Знаете ли вы, существует ли (и какой из них лучше) способ обмена настройками env между c , bash и python?
Смысл в том, чтобы различать, создаю ли я платформу A или платформу B, и единственная идея, которая у меня есть, — это создать отдельный файл для каждого языка для настройки. Есть ли способ иметь единую точку зрения на информацию?
Комментарии:
1. Обычно это входило бы в CMake или что-то подобное. Вам действительно нужно знать, для какой платформы вы создаете на C ? Если вы укажете разные пути включения и т. Д. В зависимости от цели, в любом коде не должно быть видно, что существуют разные платформы.
2. спасибо за asnwer, у меня другой код в файле cpp
3. и дело в том, чтобы иметь уникальную точку, где cpp, bash и python получают доступ к информации о платформе
4. Я предполагаю, что очень мало кода C должно отличаться между Linux и Raspbian? Вы изолировали эти части? Надеюсь, ваша кодовая база не завалена
#ifdefбуквами s5. на самом деле код raspbian, но у меня другое поведение, чтобы включить его в соответствии с HW, прикрепленным к Rpi.. и, к сожалению, у меня разреженный код на трех языках, которые я упомянул.
Ответ №1:
В зависимости от платформы объявление переменной среды будет отличаться. Для Linux вы, возможно, захотите использовать:
#include lt;stdlib.hgt; int setenv(const char *envname, const char *envval, int overwrite); Но вам придется различать платформы. Другой способ-иметь файл конфигурации с блокировкой для совместного использования этих переменных, но это также зависит от платформы (механизм блокировки файлов).
Решение, не зависящее от платформы, должно иметь некоторую форму связи между различными программами (IPC).
Комментарии:
1. платформа-linux, извините, что я изменяю, чтобы прояснить этот момент
Ответ №2:
Это не полное решение для этой смешанной среды, а скорее идея о том, как организовать ее часть на C . Возможно, эту структуру можно было бы использовать повторно, чтобы сделать что-то подобное для bash и python тоже.
Я вижу структуру каталогов, которая может выглядеть примерно так, как показано ниже. src и include будет содержать все независимые от платформы части. Для деталей, специфичных для платформы, вы создаете подкаталог в targets :
src/ include/ targets/ -- linux/ | | | -- src/ | include/ | -- raspbian | -- src/ include/ В include него вы можете поместить заголовок прокси — сервера и описание интерфейса для конкретных частей платформы.
include/IFoo.hpp
#pragma once class IFooable { public: virtual ~IFooable() = default; virtual void do_stuff() = 0; }; include/foo.hpp
#pragma once #include lt;foo_impl.hppgt; И в целевых каталогах:
raspbian/include/foo.impl.hpp
#pragma once #include lt;IFoo.hppgt; class foo : public IFooable { void do_stuff() override; }; linux/include/foo.impl.hpp
#pragma once #include lt;IFoo.hppgt; class foo : public IFooable { void do_stuff() override; }; Обе IFooable реализации совершенно не знают друг о друге, но они реализуют один и тот же интерфейс, который вы будете использовать в остальной части агностического кода платформы.
Затем вам нужно только заставить систему сборки решить, какую реализацию выбрать. Простое Makefile может выглядеть так:
raspbian: $(CXX) -Iinclude -Itargets/raspbian/include ... linux: $(CXX) -Iinclude -Itargets/linux/include ... Ключевая часть состоит в том, чтобы определить, когда вам нужно делать что-то по-разному на разных платформах. Когда вы чувствуете желание #ifdef … #else … #endif что-то, это должно автоматически заставить вас остановиться и задаться вопросом, является ли это чем-то тривиальным (например, однострочным) или реализации действительно разные звери. Если вы придете к выводу, что это нетривиальная разница, подумайте о том, какой общий интерфейс вы хотели бы иметь, и определите класс интерфейса для этого. Затем продолжайте и реализуйте два разных решения. В части кода, не зависящей от платформы, он будет чистым. Не будет видно и следа разницы между реализациями linux и raspbian.