В разных IDE разные файлы проектов...

[niXman]

вот кусок makefile из настоящего проекта. и так же все пучком.

Код

INI
tmp/release/main.o: main.cpp config.hpp \
		dirdiff.hpp \
		fileinfo.hpp \
		scandir.hpp \
		rpcmethods.hpp \
		xmlrpc/XmlRpc.h \
		xmlrpc/XmlRpcClient.h \
		xmlrpc/XmlRpcDispatch.h \
		xmlrpc/XmlRpcSource.h \
		xmlrpc/XmlRpcException.h \
		xmlrpc/XmlRpcServer.h \
		xmlrpc/XmlRpcServerMethod.h \
		xmlrpc/XmlRpcValue.h \
		xmlrpc/XmlRpcUtil.h \
		tools.hpp \
		torrentcontext.hpp \
		log.hpp \
		sleep.hpp \
		console.hpp
	$(CXX) -c $(CXXFLAGS) $(INCPATH) -o tmp/release/main.o main.cpp
 
tmp/release/fileinfo.o: fileinfo.cpp fileinfo.hpp
	$(CXX) -c $(CXXFLAGS) $(INCPATH) -o tmp/release/fileinfo.o fileinfo.cpp
 
tmp/release/dirdiff.o: dirdiff.cpp dirdiff.hpp \
		fileinfo.hpp
	$(CXX) -c $(CXXFLAGS) $(INCPATH) -o tmp/release/dirdiff.o dirdiff.cpp
 

[SABROG]

Попробовал под MSYS, makefile получился на 200 байт длиннее, но внешних признаков отличия я не заметил, также как и присутствия broken.h

Если этот файл насильно запихнуть в SOURCES, то получается такой makefile:

Код:

release/main.o: main.cpp 
	$(CXX) -c $(CXXFLAGS) $(INCPATH) -o release\main.o main.cpp

release/broken.o: broken.h 
	$(CC) -c $(CFLAGS) $(INCPATH) -o release\broken.o broken.h

И комплиятор не собирает проект:

Код:

release/broken.o: file not recognized: File format not recognized

[niXman]

так это что получается? что прогеры под вендавз самые несчастные прогеры в мире?
а как тогда зависимости отслеживаются?
маловероятно чтоб такое не было замечено троллями. хотя...

[niXman]

release/broken.o: broken.h
   $(CC) -c $(CFLAGS) $(INCPATH) -o release\broken.o broken.h

[SABROG]

так это что получается? что прогеры под вендавз самые несчастные прогеры в мире?
а как тогда зависимости отслеживаются?
маловероятно чтоб такое не было замечено троллями. хотя...

Тут получается, что при каждом изменении/добавлении/удалении директивы #include надо пересобирать .pro файл, т.е. qmake делать, тогда изменения в зависимых .h файлах отслеживаются, т.к. запись меняется в makefile.

[Dendy]

HEADERS вообще ни на что не влияет, qmake берёт из них список файлов для генерации мета-информации, к разрешению зависимостей эта переменная не имеет отношения.

niXman, я не понимаю как вы проверяете. Дописываете #include "...", потом прогоняете qmake и смотрите на результат? Если так, то я два раза написал, что проблема не в этом, а в том, что зависимость не появляется в Makefile после того как вы прогнали qmake, а уж затем добавили #include "..." и запустили make.

При чём здесь операционная система я не понимаю, проблема то не в том как работает qmake, а в том, что в результирующем Makefile отсутствует команда для регенерации зависимостей между исходниками. Сейчас запущу на Линуксе, проверю.

[SABROG]

HEADERS вообще ни на что не влияет, qmake берёт из них список файлов для генерации мета-информации, к разрешению зависимостей эта переменная не имеет отношения.

Т.е. это чисто MOC'овская переменная для хедеров с классами на базе QObject'a?

[niXman]

я просто изменяю один из файлов проекта, и и выполняю make. и все что по зависимостям, пересобирается. что не так?

[niXman]

аааа! вот ты о чем!(вот я дубень) )
щас.

[SABROG]

Получается отличае CMake от QMake в этом плане такое, что первый проходится по всем исходниками в момент сборки и определяет зависимости, в то время как QMake делает это всего-лишь один раз при генерации makefile'ов.

В некотором смысле это не проблема, т.к. конечный потребитель, который будет собирать программу из исходников, будет вынужден запустить qmake на .pro файл, т.к. ему нужны мейкфайлы уже для его ОС. Просто qmake тут заставляет ломать голову уже разработчику.

[niXman]

да, все верно. после добавления хидера к одному из исходников, он появляется в его зависимостях только после генерации makefile

[Dendy]

Только что проверил на Линуксе. Чуда не произошло.

SABROG, вы правы. В итоге гарантировано без ошибок QMake'ом можно собрать проект только с нуля. Хотя здесь для конечного пользователя припасены другие грабли вроде невозможности узнать какие переменные можно подтюнить на этапе конфигурации, банально указать префикс инсталяции, а также отсутствие какого-либо механизма проверки системы на наличие пререквизитов. В итоге после генерации Makefile'а и запуска make последний ругнётся на отсутствие заголовочника "абвгд.h" и поди узнай что за dev-пакет ты забыл установить.

Собственно вопрос стоял какой из генераторов Makefile'ов можно использовать для кодинга. QMake здесь однозначно сливает.

[Авварон]

странная логика... по-моему я на прошлой странице привел выдержку grep'а мейкфайла говорящую о том, что qmake лазит по исходникам и выцепляет только нужные хедеры. По-моему это логично, и трудно называть это багом. Тем более что по вашим словам смейк выполняет ту же работу, но каждый раз и все нарекания на кумейк в скорости

[SABROG]

банально указать префикс инсталяции

Если .pro файл поддерживает такую возможность, то повлиять на переменные можно через окружение или передав нужный параметр в qmake.

, а также отсутствие какого-либо механизма проверки системы на наличие пререквизитов.

А каким образом они проверяются? Если путем поиска нужных файлов по нужным директориям, то это осуществимо.

привел выдержку grep'а мейкфайла

В моих makefile'ах никаких grep'ов нет.

[Авварон]

grep - никсовая команда, ищущая строку в файле... в 1м мейкфайле нет строк, содержащих broken.h (та где нет инклюда в мейне), во 2м есть. как следствие, qmake смотрит исходники