Установить зависимые от проекта системные переменные сборки
Я написал систему сборки, которая вызывает скрипт bash или batch build. Сейчас я копирую и вставляю скрипт сборки в любой новый проект и изменяю свойства, связанные с проектом.
Чтобы избежать необходимости каждый раз модифицировать скрипт (или использовать только тот, который будет задан глобально, например), я хотел бы иметь возможность установить некоторые переменные в настройках возвышенного проекта и получить их в системе сборки, а затем отправить их в сценарий в качестве аргументов.
Это выполнимо без определения системы сборки для каждого проекта?
В случае, если это уместно, вот несколько упрощенных сценариев сборки
#!/bin/bash
exe=some_defined_exe
mkdir -p build
cd build
cmake ..
make -j4
make install
cd ../bin
$exe
cd ..
И построить систему
{
"cmd": ["build.sh"],
"working_dir": "${project_path:${folder}}",
"shell": false,
}
И я хотел бы, чтобы они были чем-то вроде
#!/bin/bash
exe=$1
mkdir -p build
cd build
cmake ..
make -j4
make install
cd ../bin
$exe
cd ..
а также
{
"cmd": ["build.sh", "${some_project_defined_variable}"],
"working_dir": "${project_path:${folder}}",
"shell": false,
}
1 ответ
Поскольку вы уже используете пользовательскую систему сборки, вы можете извлечь что-то подобное, используя немного кода плагина и некоторые модификации вашей системы сборки.
Пользовательские системы сборки позволяют свойство с именем target
который указывает команду для выполнения сборки. Если вы не предоставите это (большинство систем сборки не предоставляют), по умолчанию используется exec
команда. Вы можете создать свою собственную команду, которая может выполнять расширения для вас.
В качестве простого примера посмотрите следующий исходный код на python, который вы можете сохранить как что-то вроде custom_build.py
в вашем User
пакет. Это реализует новую команду с именем my_custom_build
, Когда эта команда выполняется, она преобразует свои аргументы, расширяя переменные, а затем выполняя значение по умолчанию. exec
командовать ими.
import sublime, sublime_plugin
# List of variable names we want to support
custom_var_list = ["proj_var_1"]
class MyCustomBuildCommand(sublime_plugin.WindowCommand):
def createExecDict(self, sourceDict):
global custom_var_list
# Get the project specific settings
project_data = self.window.project_data ()
project_settings = (project_data or {}).get ("settings", {})
# Get the view specific settings
view_settings = self.window.active_view ().settings ()
# Variables to expand; start with defaults, then add ours.
variables = self.window.extract_variables ()
for custom_var in custom_var_list:
variables[custom_var] = view_settings.get (custom_var,
project_settings.get (custom_var, ""))
# Create arguments to return by expanding variables in the
# arguments given.
args = sublime.expand_variables (sourceDict, variables)
# Rename the command paramter to what exec expects.
args["cmd"] = args.pop ("command", [])
return args
def run(self, **kwargs):
self.window.run_command ("exec", self.createExecDict (kwargs))
В частности, он сначала ищет переменные в настройках, указанных в текущем представлении, а если они там не найдены, в специфических настройках проекта. Любые переменные по-прежнему не найдены по умолчанию для пустой строки.
Вам необходимо указать пользовательскую систему сборки, такую как:
{
"target": "my_custom_build",
"command": ["build.sh", "${proj_var_1}"],
"working_dir": "${project_path:${folder}}",
"shell": false
}
Обратите внимание, что теперь есть target
поле, которое указывает, что пользовательская команда должна быть выполнена вместо exec
, Обратите внимание, что вместо указания командной строки как cmd
мы указываем это как command
здесь вместо
Это связано с тем, что Sublime, кажется, предварительно расширяет значения известных ключей в системах сборки, прежде чем запустить пользовательскую команду. В результате он будет пытаться расширить переменные в cmd
ключ, вызывающий ${proj_var_1}
быть развернутым в пустую строку до того, как наша команда ее увидит, что лишает нас ее.
Чтобы обойти это, мы изменим имя ключа на что-то, что Sublime оставит в покое, а затем поменяем его обратно в коде.
Как написано в приведенном выше коде, мы попытаемся расширить любые переменные, которые он видит где-либо в системе сборки, но для защиты cmd
ключ в этом пути. Вам нужно сделать нечто подобное, если вы хотите использовать свои собственные переменные в working_dir
ключ, например.