Только опции компиляции надо чтобы были едины.

@I_vlxy_I ты точно получишь профит при инкрементном билде

или купить памяти/ссд

У народа на ноутах сборка медленно идет :-) у меня то норм.

@I_vlxy_I у тебя, кстати, сколько субпроектов при сборке? у меня порядка 800

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

Порядка 300

Порядка 300

ну вся пересборка должна быть не более 10 минут, хотя если у тебя мета на мете сидить и метой погоняет, то it depends

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

Ну, народ хочет чтобы при полной пересборке было быстро

ну вся пересборка должна быть не более 10 минут, хотя если у тебя мета на мете сидить и метой погоняет, то it depends

У меня - 5. На ноутах около 10-15.

У меня - 5. На ноутах около 10-15.

надо ускорять ноуты SSD

ну а ещё можно юзать всякие incredibuild

С учетом всех обстоятельств проще pch вкрутить.

Ну, народ хочет чтобы при полной пересборке было быстро

холиварно, но полная пересборка на постоянной основе - грусть и печаль

если только речь не о CI который всех достал своей тормознутостью

холиварно, но полная пересборка на постоянной основе - грусть и печаль

I know. Но многие привыкли вот так, либо иногда это бывает просто нужно.

если только речь не о CI который всех достал своей тормознутостью

Ну и это тоже :-)

ну иногда, то да, но постоянно

В общем я понял, что реалистично достичь по крайней мере 2x скорости сборки. 10% - это не достаточно.

спасибо

В общем я понял, что реалистично достичь по крайней мере 2x скорости сборки. 10% - это не достаточно.

а как ты сделал вывод о двукратном увеличии скорости при полной пересборке?

надо мерять, пробовать.

Выше писали вроде

полная пересборка с pch потребует времени и на создания pch, так что надо мерять

это как при профилировке, фиг наперед скажешь, что будет бутылочным горлышком

в одном проекте нет

Толь, на самом деле можно.

Можно ли иметь несколько наборов pch? Типа pch1.h, pch2.h? И использовать либо один либо другой либо и то и другое сразу?

Можно, но обычно это НЕ НУЖНО.

Толь, на самом деле можно.

cotire не поддерживает, это только на solution-ах можно

gcc вообще может вместо КАЖДОГО хедера искать его скомпиленную версию

указывать какой cpp файл отвечает за создание, и после для каждого cpp указывать какой pch использовать

cotire не поддерживает, это только на solution-ах можно

Это может быт. А так -- есть в PCH два шага, первый создаёт PCH на основе исходника -- их может быть сколько угодно. Второй -- использует PCH при сборке исходного модуля. PCH при этом задаётся в параметрах вызова компилятора, их тоже может быть сколько угодно (на один исходный модуль только один)

Это может быт. А так -- есть в PCH два шага, первый создаёт PCH на основе исходника -- их может быть сколько угодно. Второй -- использует PCH при сборке исходного модуля. PCH при этом задаётся в параметрах вызова компилятора, их тоже может быть сколько угодно (на один исходный модуль только один)

но я никогда на практике не встречал этого use case-a

cotire не поддерживает, это только на solution-ах можно

В VC как раз вроде бы нельзя, потому что там на проект только одно место, где можно указать "Создать PCH". И то я не уверен.

но я никогда на практике не встречал этого use case-a

Ну потому что это и бессмысленно во многом.

надо смотерть что там у него в конфигах, т.к. UI может и не позволять, а в xml от msbuild может работать

В VC как раз вроде бы нельзя, потому что там на проект только одно место, где можно указать "Создать PCH". И то я не уверен.

позволяет, вроде

надо смотерть что там у него в конфигах, т.к. UI может и не позволять, а в xml от msbuild может работать

Да вот... Многогранный С++

Да вот... Многогранный С++

скорее студия

gcc вообще может вместо КАЖДОГО хедера искать его скомпиленную версию

А какой смысл разбивать PCH на части ? Ведь скорость компиляции от размера PCH, я уверен, не зависит. Поэтому всё равно, как скомпилять например Boost и WinAPi, в один PCH или в 2 разных.

В VC как раз вроде бы нельзя, потому что там на проект только одно место, где можно указать "Создать PCH". И то я не уверен.

вроде бы даже у MS на каждую единицу компиляции независимо запускается компилятор. На уровне компилятора нет проектов. Вопрос лишь в том, с какими опциями компилятор запускается.

вроде бы даже у MS на каждую единицу компиляции независимо запускается компилятор. На уровне компилятора нет проектов. Вопрос лишь в том, с какими опциями компилятор запускается.

Там всёСЛОЖНА!

ну студийный проект же можно собрать без студии ?

да и вообще, ms компилятором можно и без солюшена/проекта собрать.

ну студийный проект же можно собрать без студии ?

можно, вопрос делает ли кто-то так

Можно, но оно старается скопом кормить компилятору несколько модулей исходных разом, больше-лучше. Чтобы 200 раз не запускать компилятор потом не освобождать всё. Естественно, оно так может сделать только если параметры запуска компиля одни и те же.

Хм. Это даже похоже на то, как компилятор zapcc работает.

ну, естественно, майки не могут придумать ничего своего ;)

zapcc появился позже ?

не важно

и он вроде вообще сервисом в системе висит. даже когда не компиляет ничего.

да

и он вроде вообще сервисом в системе висит. даже когда не компиляет ничего.

ну и Zapcc caches (among other things) template instantiations between compilations.

А как у zapcc с результурующим кодом и оптимизациями?

ну и Zapcc caches (among other things) template instantiations between compilations.

реально имеет какой-то еффект?

реально имеет какой-то еффект?

Having everything ready in-memory saves time, especially where the headers are much more complex than the source code. With a short C++ program using boost::numeric, boost::graph etc or Eigen, we see a 10-50x speedup.

А как у zapcc с результурующим кодом и оптимизациями?

как и у шланга

реально имеет какой-то еффект?

дыа, имеет

Having everything ready in-memory saves time, especially where the headers are much more complex than the source code. With a short C++ program using boost::numeric, boost::graph etc or Eigen, we see a 10-50x speedup.

я про реальность, а не из ридми

так то тоже можно компиляцию ускорить, если всё держать в оперативке

Вопрос к спецам: Имеем невозможность сделать перегрузку: template <class T> void f(std::function<void(T, int)>) и template <class T> void f(std::function<void(T, float)>) Концепты что-то исправят? Хочется иметь возможность: 1) делать явную перегрузку по сигнатуре 2) сделать это perfecly: template <class T, Callable<void(T, int)> F> void f(F&& f) (как-то так себе вижу) - без создания std::function

с шорт программкой модно много чего нагородить

так реальность у всех разная

я про реальность, а не из ридми

дак берешь и проверяешь, в чем дело то

будем надеяться, что часть нароботок в апстрим протолкнут

дак берешь и проверяешь, в чем дело то

берешь и доказываешь, что не только на шорт-программах с буст::граф имеет хоть какой-то резон

в рассылке шланга говорили, что раньше велись работы в схожем с zapcc направлении, но забили

берешь и доказываешь, что не только на шорт-программах с буст::граф имеет хоть какой-то резон

ещё раз - у всех разные кейсы, ну

ещё раз - у всех разные кейсы, ну

я не спорю, но они явно пишут, что на маленьких синтетических примерах. а что там в реальности и стоит ли оно перехода с гораздо блее популярного тулчейна - не понятно

а какой тест норм? компиляция ядра линуха?

похороникс вроде его юзает

а какой тест норм? компиляция ядра линуха?

с таким подхом- никкакой, естественно

я не спорю, но они явно пишут, что на маленьких синтетических примерах. а что там в реальности и стоит ли оно перехода с гораздо блее популярного тулчейна - не понятно

авторы пишут что сборка ллвм в 2 раза быстрее чем шлангом

Можно тест на сборку бубса!

авторы пишут что сборка ллвм в 2 раза быстрее чем шлангом

а вотт тут уже прикольно

буду знать

попробовал zapcc - gcc проект собирает за 5 минут, zapcc собирает проект за 2 минуты.