Чтобы избежать проблемы XYZ, вот некоторый контекст:
Мое приложение C ++ необходимо скомпилировать для разных встроенных платформ, используя разные кросс-компиляторы, sdk, APIи т. д. К сожалению, SDK устанавливают различные переменные среды (не все одинаковые), и кросс-компиляторам может потребоваться установить некоторые другие.(Конечно, это не может быть изменено или исправлено на моей стороне).
Для сборки приложения я использую automake + libtool для генерации make-файлов (Это был не мой выбор, и я все еще пытаюсь понять его синтаксиси макросы).Чтобы иметь возможность переключаться между целями, сгенерированное дерево make-файлов создается в определенном каталоге ./buildXXX, где XXX - имя цели.
Проблема:
Проблема заключается в том, что при установке одного SDK в сеансе bash он устанавливает переменные env, которые являются довольно распространенными (например, PATH, CC или PKG_CONFIG), и это нарушает сборку другой цели или даже установкуснова тот же SDK.
Конечно, я мог бы открывать новый терминал и снова вызывать sdk каждый раз, когда меняю цель, но есть дюжина разных целей, и мне часто приходится переключаться между несколькими из них.
Я хочу иметь возможность запускать сборку из каталога buildXXX (созданного после установки sdk), не заботясь об истории сборки, которую я делал в данном сеансе.
Мое текущее решение:
Я добавил несколько сценариев оболочки для сброса списка переменных env, прежде чем пытаться установить SDK (так что теперь они неt-себя сломать -_-).
Я добавил еще один сценарий оболочки для генерации нового правила 'setenv', которое устанавливает переменные, которые были изменены.
Далее:
Я не могу найти способ включить этот сгенерированный make-файл и добавить "setenv" в качестве зависимости к правилам, сгенерированным automake / libtool.
ELSE ???
Возможно, это было выполнимо без сценария оболочки и нового правила, но напрямую с automake / libtool, поэтому я также открыт для такого решения;)