Ах да, заголовочные файлы где ошибки тут, файлы: element.h; button.h; edit.h

Не хватает определений каких-то виртуальных функций, проверь, что точно все файлы перечислил

Да точно, что-то я сильно тупанул, там внутри папки ui есть же еще папка precompute, спасибо!

Осиль Autotools

https://autotools.io/index.html

Осиль CMake или QBS. Ни в коем случае не берись за autotools.

Хорош холиварить. Для его случая тулсы идеальны.

Для его случая тулсы идеальны.

Нет. Там boost.

смотри, может порядок файлов поменять

И чем это грозит?

CMake хотел изучить после make, сейчас пока на make хотел посидеть, а как время будет больше свободного разберусь с cmake...
у меня сейчас автоматически генерируются правила, но в папке src/ui и src/ui/precompute одинаковые названия файлов, и потому получается что ищет по первым совпадениям в какой-то папке и все, можно ли сгенерировать какой-то уникальный префикс?

source_dirs := src src/core src/map_editor src/renderer src/ui/precompute src/ui src/utility
VPATH := $(source_dirs)
 
%.o: %.cpp
	$(CC) $(stdcpp) -fPIC -D$(platform) -D$(arch) -c -MD $(addprefix -I,$(source_dirs)) $(compile_flags) $(include_pathes) $<

И чем это грозит?

Скачиванием кучи дополнительных, хреновоработающих M4-костылей с сайта GNU:

http://www.quantprogrammer.com/adding-boost-to-your-autotools-project/#.VVuLz...

http://www.gnu.org/software/autoconf-archive/ax_boost_base.html

В то время как в CMake всё есть из коробки.

у меня сейчас автоматически генерируются правила

Увы, я не в курсе этой кухни. Я всегда задавал всё явно:

dialog.o: fontweightissue-qt5/dialog.cpp fontweightissue-qt5/dialog.h
	$(CXX) -c $(CXXFLAGS) $(INCPATH) -o dialog.o fontweightissue-qt5/dialog.cpp

main.o: fontweightissue-qt5/main.cpp fontweightissue-qt5/dialog.h
	$(CXX) -c $(CXXFLAGS) $(INCPATH) -o main.o fontweightissue-qt5/main.cpp

moc_dialog.o: moc_dialog.cpp 
	$(CXX) -c $(CXXFLAGS) $(INCPATH) -o moc_dialog.o moc_dialog.cpp

Или генерировал корректные Makefile'ы с помощью QMake или CMake.

недавно пробовал prebuild 5 ... по мойму уже годно. И искалку буста накатал за часик, скопипистав в cmake пути поиска.

ясно, в общем лучше сразу cmake учить походу ))

prebuild 5

premake

I saw a book entitled «Die GNU Autotools» and I thought «My feelings exactly». Turns out the book was in German.

Реально, осиль цмейк, много времени не займёт, зато потом будет очень просто, быстро, легко и понятно всё собирать.

Как-то так может сработать (просто развернёт правило для каждого из путей):

define compile_template
$1/%.o: $1/%.cpp
	$$(CC) $$(stdcpp) -fPIC -D$$(platform) -D$$(arch) -c -MD $$(addprefix -I,$$(source_dirs)) $$(compile_flags) $$(include_pathes) $$<
endef
$(foreach dir, $(dirs), $(eval $(call compile_template,$(dir))))

Думать нужно перед тем как трупа советовать)

По случаю, оно не умеет случайно какое то дерево зависимостей, что бы в IDE отдать?

Ну типа для плагинья всякого?

CMake - де факто стандарт, особенно для кроссплатформщины. По этому знать его явно полезно.

Однако, лично я таки жду тулзу, с человечьим языком вместо их самопальщины. Но с той же идеалогией. Ну и расширяемым CPack :)

undefined reference to vtable

Зачем ты компилируешь код C++ с помощью gcc? Нужен g++.

Тулсы не бывают идеальны, это все сказки.

опять в тред набежали неосиляторы autotools и советчики наркоманской альтернативщины :)

«Наркоманский» - это о автотулзовском m4 и мегабайтах говнокода им пораждаемых. «Альтернативщина» тоже уже несколько лет относится только к autocrap, учитывая распространение cmake.

CMake - де факто стандарт, особенно для кроссплатформщины. По этому знать его явно полезно.

Autotools во всех полях. CMake обычно используют или в свежих поделках, или пионеры.

autotools используют для легаси. И с кроссплатформой у него туговато. Можно конечно, но дроч.

Что-нить типа scons или gyp?

scons собирает сам - врят ли он делает это лучше ninja...

gyp - выглядит относительно бодро, но дока у них что то не особо... Я не нашёл где поглядеть, что оно умеет в бэкэнде.

Upd. Как бы то что я хотел бы - это CMake на питоне.

waf?

эмм, я вообще-то компилирую код с помощью clang++
https://github.com/sysint64/e2dit/blob/ui/makefile

scons собирает сам - врят ли он делает это лучше ninja...

Scons при каждом запуске сначала парсит все проектные файлы, в результате на проекте средних размеров этот тупняк просто реально начинает доставать. Сделал на нем 1 проект и зарекся. По функционалу ничего (питон всё же), но тормознутость всё портит.

По задумке - оно, но по качеству исполнения, и доки, пока не дотягивает.

Понимаю что заявление тряпки, и надо допилить:) Но есть дела более насущные.

Мда, бедный народ из KDE не знает что они пионеры и используют CMake

autotools используют для легаси. И с кроссплатформой у него туговато. Можно конечно, но дроч.

Туговато? Да он вообще на всём unix-подобном работает, даже которое уже давно мёртвое.

Мда, бедный народ из KDE не знает что они пионеры и используют CMake

Достаточно на внешний вид KDE посмотреть, чтобы это подтвердить.

По мне так внешний вид KDE лучше внешнего вида Windows 10. И работает стабильнее. А autotools было говном мамонта, слепленным на соплях, уже 10 лет назад.

даже которое уже давно мёртвое.

На мёртвом, да работает. Потому я про legacy и говорю.

А вот под офтопик, оно например вообще никак без мозиловских подпорок.

Однако, лично я таки жду тулзу, с человечьим языком вместо их самопальщины. Но с той же идеалогией. Ну и расширяемым CPack :)

А QBS не пробовал? Или gradle?

Очень интересен QBS, можно ли с помощью него сгенерировать проект на Visual Studio?

qbs - он тоже сам собирает. Что не юниксвейно и врят ли столь же эффективно как специально заточенные тулзы.

gradle, вообще скорее для более высокоуровневых задач - типа раскидать артефакты, слепить пакет там. Опять же, по эффективности собственно билда и инкрементальной сборки к нему навярняка будут вопросы.

Но ни на чём серьёзном я ни то ни то не пробовал. Если есть какие то бенчмарки, то я бы поглядел в сравнении с нинзей и гну мейком. Тот же нинзя на инкрементальной сборке рвёт мейк как известный песик, известный предмет обихода.

О, нинзя прикольный, надо и его по разбирать )

он тоже сам собирает

А Ninja разве нет?

Что не юниксвейно и врят ли столь же эффективно как специально заточенные тулзы.

Это даже очень хорошо, что не юниксвейно и make не нужен. Тем более make вряд ли можно назвать «специально заточенной тулзой».

Очень интересен QBS, можно ли с помощью него сгенерировать проект на Visual Studio?

https://codereview.qt-project.org/#/c/91353/

Да, скоро будет можно (если не уже). И под XCode — тоже.

ninja собирает сам - но ты застрелишься к нему мейкфайлы писать (особенно кроссплатформенные). А cmake, генерит их.

Ты бы это, читал бы весь тред, ну или хотя бы цепочку :)

оО.

Так qbs - метасборщик? Т.е. под онтопик он make файлы генерит?

Тогда, если он не тянет за собой половину Qt, должна быть годная вещь по идее. Да даже если и тянет...

Нинзю проще пускать через CMake, если ты почитаешь доку, то он под то и задумывался (что бы его мейкфайлы было легко генерировать, а не руками писать).

Вот и qbs like a ninja. Я нить прочитал, но меня смутило, что ты хорошо отзываешься о Ninja, но при этом говоришь что другие инструменты, которые тоже собирают сами, поступают неюниксвейно.

Так qbs - метасборщик? Т.е. под онтопик он make файлы генерит?

Нет. Он будет (так как в master патчи https://codereview.qt-project.org/#/c/91353/ и https://codereview.qt-project.org/#/c/75130/ до сих пор не слиты) лишь генерировать проектные файлы для популярных IDE, по желанию пользователя.

При этом сам он не является мета-сборщиком, как CMake, так как собирает сам. Создание проектных файлов для других IDE — лишь приятная возможность, не более. При этом в сгенерированных проектных файлах будет использоваться стандартный для IDE сборщик.

Про ninja - я отзывался в контексте, что он хорош как бэкэнд.

Про qbs, с одной стороны я рад что когда последний раз на него глядел таки освоил доку, но и расстроен, что не ошибся :)

QMAKE рулит ^_^