cmake разделение проекта

т.е. после стадии конфигурации и между началом этапа компила

Это как?

ЯННП. Какая генерация? какие 100 секунд? Всегда так делаю, все работает быстро, брат жив.

0s cmake.. 3s Configuring done 114s Generating done 114s make -j8 ...

Что ты в cmake намудрил, что он тормозит?

В проекте 3 тыщи файлов исходников, компилится часа пол с нуля, поэтому конфиг + ген = 100сек я бы понял, если бы не одно но, что если не разделять по таргетам, а тупо вставить сорцы в итоговую либу, этот этап проскакивает моментально. Всё банально, вот к примеру

корневой CMakeLists.txt:

...
ADD_LIBRARY(${PROJECT_NAME} SHARED <TARGET_OBJECTS:FIRST_PART_OF_LIBRARY>)
ADD_SUBDIRECTORY(first_part_of_library)
...

В подпроекте first_part_of_library CMakeLists.txt:

...
ADD_LIBRARY(${PROJECT_NAME} OBJECT ${FIRST_PART_OF_LIBRARY_SRCS})
...

И это всё выливается в 100сек конфига + гена.

В то же время вариант корневого CMakeLists.txt:

...
ADD_LIBRARY(${PROJECT_NAME} SHARED ${FIRST_PART_OF_LIBRARY_SRCS})
...

выполняется секунды за 3.

Один таргет для примера, в проекте их десятки. Но проверка самого большого дала +-30 сек. Т.е. явно не от количества таргетов зависит, а от их объёма, но какого ***???))

И это всё выливается в 100сек конфига + гена.

Выложи работающий пример, на котором проявляется проблема, пожалуйста. В моей практике никогда ничего подобного не встречалось.

Эм... один в один как я описал выше, сами сорцы яж сюда не смогу выложить. А структура cmake чётко именно такая же, стоит убрать создание таргета и переместить из него сорцы сразу в итоговую либу и всё сразу шустро. Я надеялся кто-нибудь сталкивался, если не - над будет тогда разрабам cmake-a черкнуть.

ЗЫ: из знаменитого манула cmake performance tips я перепробовал всё, с помощью ninja удалось сократить время немного, но проблема всё равно осталась.

ADD_LIBRARY(${PROJECT_NAME} OBJECT ${FIRST_PART_OF_LIBRARY_SRCS})

Разве в ${PROJECT_NAME} будет «FIRST_PART_OF_LIBRARY»? По-моему, надо так:

ADD_LIBRARY("FIRST_PART_OF_LIBRARY" OBJECT ${FIRST_PART_OF_LIBRARY_SRCS})

Не, это же подпроект, у него свой PROJECT(FIRST_PART_OF_LIBRARY) в заголовке.

А точно нужно это как подпроект оформлять? Может быть, просто как библиотеку внутри текущего проекта? А то проект с выходными данными - кучей объектников - странно как-то смотрится.

Не странее, чем статическая либа, нужная только для итоговой динамической) к тому же - эффект такой же...

Ну а если статическую либу в подпроекте определить, то тоже тормозит?

Да, любой таргет, проседание в этапе генерации и конфига происходит как только мы выделяет любые сорцы в отдельный таргет, если этого не делать - просеста нет. Такое впечатление, что при определении части сорцов как таргета cmake не просто создаёт пару дополнительных дир и связей, а грохает там огого чего-то лишнего. Либо в кэшах держит только сгенерированный корень, а таргеты каждый раз перегенерирует...

Попробуйте всё-таки не делать подпроекты, если это не принципиально. Т.е. всё как сейчас, но PROJECT() - только в корне, а в поддиректориях - либы (объектники или статические - всё равно).

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