Два файла .cpp с одним именем в разных папках

[juvf]

Здравствуйте!

Имеется проект с использованием Qt(qmake), в котором появились в разных папках два файла с одинаковыми именами (папка1/xxx.cpp и папка2/xxx.cpp).
В этих файлах реализуются два класса с одинаковыми именами XXX, но в разных пространствах имен.

После выполнения qmake создается обычный makefile, в котором

Код:

XXX.o: папка1/XXX.h
    $(CXX) -c $(CXXFLAGS) $(INCPATH) -o XXX.o папка1/XXX.h
    ...
    XXX.o: папка2/XXX.h
    $(CXX) -c $(CXXFLAGS) $(INCPATH) -o XXX.o папка2/XXX.h

т.е. получается, что имя цели одинаковое для разных файлов, а также объектный файл для этих целей создается в одной и той же директории с одинаковым именем


При компиляции, сначала появляется варнинг о том, что одно правило связанное с одним из фалов уже было и будет переназначено.
В результате имеем ошибку компиляции multiple definition XXX::XXX().

Как научить qmake из Qt создавать корректный makefile в этом случае?

[Dendy]

Поздравляю, вы не первый кто напоролся на эти грабли. Коротко: Just use CMake!

CMake как система сборки для Qt приложений

[juvf]

О как!!
Спасибо!

[break]

Имело дело с проектом в котором куча подпроектов внутри кот. по крайней мере файл main.cpp точно повторялся, но видимо это не тот случай?

Какие еще есть доводы в пользу cmake и отказа от qmake?

[Dendy]

Имело дело с проектом в котором куча подпроектов внутри кот. по крайней мере файл main.cpp точно повторялся, но видимо это не тот случай?

Всё верно, для отдельных подпроектов создаются временные файлы внутри директории этого подпроекта и они не конфликтуют между собой. Автор напоролся на случай, когда в одном проекте:

Код:

SOURCES += \
  Wicked/Dialog.cpp \
  Resolver/Dialog.cpp \
  Hammer/Dialog.cpp

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

Какие еще есть доводы в пользу cmake и отказа от qmake?

Из этой фразы я делаю вывод, что про CMake вы только слышали, иначе такого вопроса бы не возникло. Обязательно напишу статью на Wiki в ближайшее время.

[lit-uriy]

2 Dendy, Очень хотелось бы объективного описания/сравнения с qmake в вики, в разделе Зачем мне может понадобиться использовать CMake?. Т.к. фраза

Вы программируете больше чем для одной платформы и хотите сделать ваш проект переносимым.

применима и к qmake.

Я тоже лишь слышал о CMake и прочитав статью пришел к выводу, что под каждую конкретную библиотеку, нужна какая-то примочка к CMake, типа Выше вызов find_package(Qt4) обьявил набор вспомогательных функций для Qt4.

П.С. извиняюсь за оффтоп

[Steven_Orko]

Какие еще есть доводы в пользу cmake и отказа от qmake?

Я не нашел для себя долвольно сильных, потому перешел на scons...

[break]

SOURCES += \
  Wicked/Dialog.cpp \
  Resolver/Dialog.cpp \
  Hammer/Dialog.cpp

Наверное этот пример имеет смысл только при переводе готового проекта на QMAKE - да большое количество таких окошек переименовать будет тяжко, а если программист сам эти окошки постепенно добавляет в программу то ему не оч. страшно называть их WickedDialog.cpp, ResolverDialog.cpp - и т.д. пусть даже оставля в разных папках.

Просто насторожило что такая ситуация может заставить переходить на другую систему сборки. Я личного опыта работы с cmake действительно не имел. И из-за такой ситуации просто поправил бы имена.