История изменений

С точки зрения разработчика система сборки waf – классная. Она требует лишь Python 2 или Python 3 и не требует никаких дополнительных пакетов для сборки, как тот же CMake или Meson. А Python сегодня de-facto стандарт скриптописания и имеется на любой девелоперской тачке.

Как я понимаю, у waf имеется некий wrapper, который и позволяет собирать код сразу после клонирования его из репозитория без установки всяких дополнительных пакетов. Современные системы сборки в той же экосистеме Java: Gradle и Maven такое давно практикуют, там для сборки требуется лишь установленный JDK, а в случае с waf – Python + требуемые для проекта зависимости. Это такое же преимущество, как и у подхода autotools с configure-скриптом. Только вместо вырвиглазной нечитаемой лапшевидной портянки на shell/m4 и смеси ещё какого-то дерьма в куче файлов и таких же напрочь кривых, генерированных и тормозных Makefile – у waf стройная и понятная архитектура с нормальным языком описания сборки.

Многие говорят, мол полноценный язык для описания сборки это плохо и из пушки по воробьям. Но как только требуется собрать что-то сложнее Hello World и шагнуть в сторону от их уютного DSL, как тут же начинаются проблемы и нытьё на форумах «а как мне зделоть в смаке такое??», DSL, если он не является подмножеством полноценного языка, ограничивает и вставляет палки в колёса в различных нетривиальных случаях.

Да и вообще изучать ещё один DSL язычок для того, чтобы просто внедрить в проект сборочную систему – ИМХО, только мусор в голову класть. Особенно ковыряясь в различных упоротых доках того же CMake с кучей mindfuck’ов. Но стоит помнить, что DSL’ы как могут быть откровенно наркоманскими, спроектированными макаками без зачатков мозга, как в случае с CMake, более-менее приемлимыми, как в случае с Meson или откровенно декларативными с возможностью расширения, как в случае с QBS. Весь этот зоопарк в экосистеме C/C++ не от хорошей жизни, а от отсутствия понятия модулей, которые вот уже несколько лет всё пытаются внедрить, но воз и ныне там.

Из cons у waf разве что можно придраться к использованию Python, который много кто недолюбливает. Но факт остаётся фактом, сегодня он очень широко распространён, гораздо шире того же Shell’а, например. Возможно ещё какое-то значение имеет GIL в нём, при параллельной сборке наверное GIL как-то сказывается, но мне не хватает опыта работы с waf, чтобы это заявить утвердительно. По личному опыту я могу сказать, что обычный make + Makefiles в многопотоке тормозные, а Ninja отрабатывает на 10-15% быстрее. А waf, как и qbs вызывает компиляторы напрямую.

В идеальном мире возможно место waf занял какой-нибудь nim-build, на Nim или похожем языке программирования. С дешёвыми потоками, статической типизацией и возможностью компиляции в нативный код. Но в нашем мире сначала выиграло откровенно наркоманское решение – autotools, а на смену ему пришло практически такое же наркоманское в лице CMake. Что же, хорошо что в мире IT всё очень быстро меняется, возможно языки С и C++ спустя годы получат наконец достойную систему сборки, а файлы configure и CMakeLists.txt отправятся в /dev/null из наших репозиториев и репозиториев других разработчиков.

Так что waf всяческих успехов в популяризации. Возможно он или его идейный наследник когда-нибудь сотрёт с лица земли этот позор сборочных систем мира Unix и C/C++: как Autotools, так и CMake.

С точки зрения разработчика система сборки waf – классная. Она требует лишь Python 2 или Python 3 и не требует никаких дополнительных пакетов для сборки, как тот же CMake или Meson. А Python сегодня de-facto стандарт скриптописания и имеется на любой девелоперской тачке.

Как я понимаю, у waf имеется некий wrapper, который и позволяет собирать код сразу после клонирования его из репозитория без установки всяких дополнительных пакетов. Современные системы сборки в той же экосистеме Java: Gradle и Maven такое давно практикуют, там для сборки требуется лишь установленный JDK, а в случае с waf – Python + требуемые для проекта зависимости. Это такое же преимущество, как и у подхода autotools с configure-скриптом. Только вместо вырвиглазной нечитаемой лапшевидной портянки на shell/m4 и смеси ещё какого-то дерьма в куче файлов и таких же напрочь кривых, генерированных и тормозных Makefile – у waf стройная и понятная архитектура с нормальным языком описания сборки.

Многие говорят, мол полноценный язык для описания сборки это плохо и из пушки по воробьям. Но как только требуется собрать что-то сложнее Hello World и шагнуть в сторону от их уютного DSL, как тут же начинаются проблемы и нытьё на форумах «а как мне зделоть в смаке такое??», DSL, если он не является подмножеством полноценного языка, ограничивает и вставляет палки в колёса в различных нетривиальных случаях.

Да и вообще изучать ещё один DSL язычок для того, чтобы просто внедрить в проект сборочную систему – ИМХО, только мусор в голову класть. Особенно ковыряясь в различных упоротых доках того же CMake с кучей mindfuck’ов. Но стоит помнить, что DSL’ы как могут быть откровенно наркоманскими, спроектированными макаками без зачатков мозга, как в случае с CMake, более-менее приемлимыми, как в случае с Meson или откровенно декларативными с возможностью расширения, как в случае с QBS. Весь этот зоопарк в экосистеме C/C++ не от хорошей жизни, а от отсутствия понятия модулей, которые вот уже несколько лет всё пытаются внедрить, но воз и ныне там.

Из cons у waf разве что можно придраться к использованию Python, который много кто недолюбливает. Но факт остаётся фактом, сегодня он очень широко распространён, гораздо шире того же Shell’а, например. Возможно ещё какое-то значение имеет GIL в нём, при параллельной сборке наверное GIL как-то сказывается, но мне не хватает опыта работы с waf, чтобы это заявить утвердительно. По личному опыту я могу сказать, что обычный make + Makefiles в многопотоке тормозные, а Ninja отрабатывает на 10-15% быстрее. А waf, как и qbs вызывает компиляторы напрямую.

В идеальном мире возможно место waf занял какой-нибудь nim-build, на Nim или похожем языке программирования. С дешёвыми потоками, статической типизацией и возможностью компиляции в нативный код. Но в нашем мире сначала выиграло откровенно наркоманское решение – autotools, а на смену ему пришло практически такое же наркоманское в лице CMake. Что же, хорошо что в мире IT всё очень быстро меняется, возможно языки С и C++ спустя годы получат наконец достойную систему сборки, а файлы configure и CMakeLists.txt отправятся в /dev/null из наших репозиториев и репозиториев других разработчиков.

С точки зрения разработчика система сборки waf – классная. Она требует лишь Python 2 или Python 3 и не требует никаких дополнительных пакетов для сборки, как тот же CMake или Meson. А Python сегодня de-facto стандарт скриптописания и имеется на любой девелоперской тачке.

Как я понимаю, у waf имеется некий wrapper, который и позволяет собирать код сразу после клонирования его из репозитория без установки всяких дополнительных пакетов. Современные системы сборки в той же экосистеме Java: Gradle и Maven такое давно практикуют, там для сборки требуется лишь установленный JDK, а в случае с waf – Python + требуемые для проекта зависимости. Это такое же преимущество, как и у подхода autotools с configure-скриптом. Только вместо вырвиглазной нечитаемой лапшевидной портянки на shell/m4 и смеси ещё какого-то дерьма в куче файлов и таких же напрочь кривых, генерированных и тормозных Makefile – у waf стройная и понятная архитектура с нормальным языком описания сборки.

Многие говорят, мол полноценный язык для описания сборки это плохо и из пушки по воробьям. Но как только требуется собрать что-то сложнее Hello World и шагнуть в сторону от их уютного DSL, как тут же начинаются проблемы и нытьё на форумах «а как мне зделоть в смаке такое??», DSL, если он не является подмножеством полноценного языка, ограничивает и вставляет палки в колёса в различных нетривиальных случаях.

Да и вообще изучать ещё один DSL язычок для того, чтобы просто внедрить в проект сборочную систему – ИМХО, только мусор в голову класть. Особенно ковыряясь в различных упоротых доках того же CMake с кучей mindfuck’ов. Но стоит помнить, что DSL’ы как могут быть откровенно наркоманскими, спроектированными макаками без зачатков мозга, как в случае с CMake, более-менее приемлимыми, как в случае с Meson или откровенно декларативными с возможностью расширения, как в случае с QBS. Весь этот зоопарк в экосистеме C/C++ не от хорошей жизни, а от отсутствия понятия модулей, которые вот уже несколько лет всё пытаются внедрить, но воз и ныне там.

Из cons у waf разве что можно придраться к использованию Python, который много кто недолюбливает. Но факт остаётся фактом, сегодня он очень широко распространён, гораздо шире того же Shell’а, например. Возможно ещё какое-то значение имеет GIL в нём, при параллельной сборке наверное это как-то сказывается, но мне не хватает опыта работы с waf, чтобы это заявить утвердительно. По-крайней мере Makefile в многопотоке тормозные и Ninja отрабатывает на 10-15% быстрее.

В идеальном мире возможно место waf занял какой-нибудь nim-build, на Nim или похожем языке программирования. Но в нашем мире сначала выиграло откровенно наркоманское решение – autotools, а на смену ему пришло практически такое же наркоманское в лице CMake. Что же, хорошо что в мире IT всё меняется, возможно языки С и C++ спустя годы получат наконец достойную систему сборки, а файлы configure и CMakeLists.txt отправятся в /dev/null из репозиториев разработчиков.