Ответ 1
Для точно такой же цели я нашел .dir-locals.el
чрезвычайно полезным, вот как выглядит один из моих:
((nil . ((tab-width . 8)
(indent-tabs-mode . t)))
(c++-mode . ((c-basic-offset . 8)
(tab-width . 8)
(indent-tabs-mode . t)
(compile-command . "make -C ../build -j 2 run_tests")))
((c-mode . ((c-basic-offset . 8)
(tab-width . 8)
(indent-tabs-mode . t)
(compile-command . "make -C ../build -j 2 run_tests")))))
Очевидно, что у меня могут быть пути, указанные в разных .dir_locals.el
в соответствии с их местоположением, и, например, некоторые build run_tests
для unit test, некоторые из них строят реальную цель и т.д.
Затем я помещаю в каталог сборки фиктивный makefile
, который выглядит следующим образом:
all: run_tests
run_tests:
@cmake ..
@make -j 2
Таким образом, я могу сделать чек и запустить M-x compile
в любом файле, который мне нравится, и он пойдет правильно. Я использую git, и этот Makefile игнорируется при мониторинге с помощью git следующим образом:
git update-index --assume-unchanged Makefile
и если я хочу изменить и зафиксировать его, я делаю
git update-index --no-assume-unchanged Makefile
.
Таким образом, новый созданный cmake Makefile не будет отображаться в git status
как измененный, и я не буду его совершать случайно.
Преимущества такого подхода:
-
так как cmake использует абсолютные пути внутри, абсолютно нет проблем с перекосом ошибок компиляции в буфере компиляции, просто нажимая enter на них.
-
вы можете указать любые правила отступов, которые вы там хотите, и они могут быть разными в разных проектах или даже в каталогах, если вы так захотите:)
-
вы можете указать любое количество желаемых целей в разных проектах, даже в каталогах, по-прежнему использовать один и тот же старый
M-x compile
(привязанный кC-c b
) и заставить Emacs поступать правильно.
Единственный недостаток, заключающийся в наличии .dir-locals.el
в ваших подкаталогах, который я вряд ли нахожу плохой.
ИЗМЕНИТЬ: robUK, чтобы ответить на ваш комментарий:
Ниже приведена документация для локальных переменных для каждого каталога, как они ее называют в руководстве Emacs. Это не пакет, это часть Emacs, хотя я не уверен, был ли он доступен в версиях до 23, я использую 23.1.1.
EDIT2: liwp, чтобы ответить на ваш вопрос:
Как уже указывал Чарльз, и как говорится в документации:
Если вы поместите файл со специальным именем .dir-locals.el в каталоге, Emacs прочитает его при посещении любого файла в этом каталоге или любом из его подкаталоги, а также применить настройки он указывает на файловый буфер. Emacs ищет .dir-locals.el начиная с каталога посетил файл и дерево каталогов. (Чтобы избежать замедления, этот поиск пропускается для удаленного файлы.)
Вам не нужно .dir-locals.el
всюду в вашем дереве проектов. Заметьте, однако, это, вероятно, зависит от сложности вашей базовой структуры кода.
Обычно я бы выбрал довольно простой макет:
/project_root_dir
/build
/src
/test
и у меня были бы несколько разные цели, указанные в разных .dir-locals.el
, скажем, в /test
Я бы только построил testrunner
и выполнил бы это, я потратил бы большую часть времени разработки на создание этой цели. Тогда в /src
я бы сначала построил тот же testrunner
, выполнил ли он, и если все будет хорошо там, это создаст мне мою главную цель проекта. Если вам это не нужно, вы можете быть в порядке только с одним .dir-locals.el
под /project_root_dir
. Если ваша исходная структура и требования намного сложнее, это может означать, что вам понадобится немного больше волшебства, связанного с путями и целями.