Комментарии 6
Несколько лет назад перетаскивал большой древний с++ проект с tmake (предтеча qmake) на CMake. Если с маленькими проектами проблем не было, то большой проект вызвал вопросы, на которые не находились толковые ответы, например как лучше организовывать работу с библиотеками в большом проекте, с бинарными и заголовочными, с теми что являются частью проекта и внешними, но тоже являющимися частью разработки.
Традиционно проблемы вызвали генерируемые файлы, которые никак не удавалось помирить с параллельной компиляцией без прописывания вручную зависимостей (так и не разобрался с этим).
Смотрел, кстати, немного исходники CMake и меня неприятно удивило то, что поддержка Qt в нём прибита гвоздями, а не реализована стандартными средствами.
Традиционно проблемы вызвали генерируемые файлы, которые никак не удавалось помирить с параллельной компиляцией без прописывания вручную зависимостей (так и не разобрался с этим).
Смотрел, кстати, немного исходники CMake и меня неприятно удивило то, что поддержка Qt в нём прибита гвоздями, а не реализована стандартными средствами.
Традиционно проблемы вызвали генерируемые файлы, которые никак не удавалось помирить с параллельной компиляцией без прописывания вручную зависимостей (так и не разобрался с этим)Для этого используются реальные или виртуальные target. Но прописывать это всё нужно руками, да.
Для этого используются реальные или виртуальные target. Но прописывать это всё нужно руками, да.
Ну да, так я это и сделал. Но как я себе это представляю в 2020 году? — Я каким-то образом задаю правило генерирования одних файлов из других, например *.hpp и *.cpp из файлов *.xxx и всё, на этом моя работа должна быть закончена.
Если генерируемый *.hpp включается в *.cpp файл проекта, то cmake должен сам догадаться (иначе зачем он строит дерево зависимостей), что прежде чем начать компилировать этот *.cpp файл, ему следует сначала сгенерировать соответствующий *.hpp, который он подключает. Почему я должен задавать ещё что-то вручную? По-моему это явная и очень серьёзная недоработка, из-за которой, собственно им и пришлось прибивать qt гвоздями (я знаю, что там есть и другие проблемы).
Если вы правильно укажете файлы, которые генерирует ваша внешняя тулза (выхлоп), а потом добавите эти файлы в проект через target_sources, то всё должно работать.
У меня ситуация такая — есть заголовочный файл *.hpp, генерируемый из xxx файла. Этот заголовочный файл включают разные библиотеки и приложения проекта. Иногда непосредственно, иногда опосредовано, через заголовки других библиотек.
Естественно я не хочу и не могу добавлять вручную этот файл в каждый из этих подпроектов, а хочу чтобы cmake сам, во время построения зависимостей увидел, что используется генерируемый заголовочный файл, и сделал соответствующие манипуляции. По-моему вполне законное желание и у CMake для этого всё есть.
Сейчас мне пришлось сделать специальную цель построения, которую я просто добавляю ко всем подпроектам библиотек и приложений, независимо от того, включают они этот заголовок или нет.
Естественно я не хочу и не могу добавлять вручную этот файл в каждый из этих подпроектов, а хочу чтобы cmake сам, во время построения зависимостей увидел, что используется генерируемый заголовочный файл, и сделал соответствующие манипуляции. По-моему вполне законное желание и у CMake для этого всё есть.
Сейчас мне пришлось сделать специальную цель построения, которую я просто добавляю ко всем подпроектам библиотек и приложений, независимо от того, включают они этот заголовок или нет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
История успешного перевода ScreenPlay с QMake на CMake