Анатолий ШироковWhite Owlпропущено...
Здесь ключевое слово "абстрактному описанию". У CMake описание совсем не абстрактное, а очень даже конкретное.
Я не случайно привел описание одного из наших проектов, чтобы показать, что синтаксис описания вполне себе пригоден для звания "абстрактного описания". Нет, не пригоден. Хорошо, перефразирую: Уровень абстракции у CMake абсолютно такой же как и у make.
Абстрактное описание сборки (как я его понимаю) это то что у меня есть на уровне корня проекта: Собрать специальные инструменты используемые для сбора программы, собрать промежуточные библиотеки, собрать программу, собрать плагины. Причем именно в этом порядке (хотя плагины можно собирать и параллельно с программой).
Вот пример:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
subdirs = tools app app-libs plugins
.PHONY: $(subdirs)
all: $(subdirs)
app plugins: app-libs
app-libs: tools
# стандартная цель
clean-subdirs = $(addsuffix .clean,$(subdirs))
clean: $(clean-subdirs)
# И наконец правила для обработки целей
$(subdirs):
$(MAKE) -C $@
$(clean-subdirs):
$(MAKE) -C $(basename $@) clean
То что в своем CMakeList.txt ты не показываешь как конкретно надо компилировать .cpp ничего не значит. Я в своем makefile тоже могу этого не показывать.
Вот тебе makefile от одного из плагинов:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
PROJECT=ba_zip
SOURCES=ba-zip.c unzip.c ioapi.c
BUILD_DIR=.build
OBJECTS = $(addprefix $(BUILD_DIR)/, $(SOURCES:.c=.o))
CFLAGS = $(shell pkg-config --cflags gtk+-2.0 gmodule-2.0) -I../../app $(CFLAG_PIC)
LDFLAGS = -shared $(shell pkg-config --libs gtk+-2.0 gmodule-2.0) -lz
CC = gcc
$(bin_dir)/$(PROJECT).$(lib_suffix): $(OBJECTS)
$(OBJECTS): | $(BUILD_DIR)
$(BUILD_DIR):
mkdir -p $(BUILD_DIR)
clean:
rm -f $(PROJECT)
rm -rf $(BUILD_DIR)
# А в config.mak у меня задаются bin_dir и ОС-зависимый суффикс для динамических библиотек.
include ../config.mak
Как видишь, количество кода описывающего сценарий точно такое-же как и у CMake. Уровень абстракции описания тоже совпадает.
Анатолий ШироковWhite Owlпропущено...
А зачем мне с него соскакивать, простите?Вопрос твой ожидаемый. Но мало ли, захочешь подебажить свой проект под студией. Я себе это могу повзолить просто сгенерировав solution под конкретную версию студии? А ты как этого достигаешь? Конечно, если речь идет о небольшом проекте, то можно и накидать на коленке студийный проект, но когда у тебя 600 модулей со сложными взаимосвязями, то здесь без чего-либо отвязанного от конкретной среды сборки просто необходимо.Смеешься?!
600 модулей написанных для одного компилятора запихнуть в другой компилятор и просто так подебажить? Ну-ну... То-то тут постоянно возникают вопросы: "почему в vc это работает а в g++ не работает?", и наоборот. А ты сводишь всю сложность межкомпиляторного перехода к переводу сценария сборки? Шутник.
И нет, я не захочу дебажить проект под студией. Во первых, для дебага есть логи, во вторых dbg. Зачем мне студия?
