Назовите хотя бы одну причину существования долбанного meson...

а что, были проблемы?

У меня при кросс-компиляции GCC получаются рантайм-библиотеки со сломанными исключениями. Тоже самое с нативной сборкой работает нормально. Рантайм собирается как динамическая библиотека.

Простите, но у uint8_t какие могут быть «альтернативные» лимиты? Примеры в студию.

у uint8_t какие могут быть «альтернативные» лимиты?

А речь не про uint8_t, а про сравнения в препроцессоре типа такого:

/* Determine the size of an int, if not already specified.
 * We cannot use sizeof(int), because it is not yet defined
 * at this stage in the translation of the C program.
 * Also sizeof(int) does return the size in addressable units on all platforms,
 * which may not necessarily be the size in bytes.
 * Therefore, infer it from UINT_MAX if possible. */
#ifndef UNITY_INT_WIDTH
  #ifdef UINT_MAX
    #if (UINT_MAX == 0xFFFF)
      #define UNITY_INT_WIDTH (16)
    #elif (UINT_MAX == 0xFFFFFFFF)
      #define UNITY_INT_WIDTH (32)
    #elif (UINT_MAX == 0xFFFFFFFFFFFFFFFF)
      #define UNITY_INT_WIDTH (64)
    #endif
  #else /* Set to default */
    #define UNITY_INT_WIDTH (32)
  #endif /* UINT_MAX */
#endif

А речь не про uint8_t, а про сравнения в препроцессоре типа такого:

Не, ну тому кретину, у которого UINT8_MAX в LONG_MAX превратился, я уже поставил клоуна. А от вас-то почему то же самое приходится слышать? Мой вопрос был прост и понятен: зачем UINT8_MAX быть в кондишналах?

Разница в том, что нужно собирать отдельный компилятор. Мало какой дистр пакует кросс-компиляторы, потому что все это вертели делать. У GCC с этим слишком много геморроя.

А в чем сложность? Решил посмотреть как это делается, и вот простой скрипт который собирает под любую платформу gcc для кросскомпиляции в /opt, нужно только подложить файлы, причем можно любой версии он сам их распознает по имени: binutils-2.44.tar.zst linux-6.12.34.tar.zst gcc-15.1.0.tar.zst glibc-2.41.tar.zst

#!/usr/bin/env bash

set -e

cd $(dirname $0) ; CWD=$(pwd)

GCC_VERSION=${GCC_VERSION:-$(echo gcc-*.tar.zst | rev | cut -f 3- -d . | cut -f 1 -d - | rev)}
BINUTILS_VERSION=${BINUTILS_VERSION:-$(echo binutils-*.tar.zst | rev | cut -f 3- -d . | cut -f 1 -d - | rev)}
LINUX_VERSION=${LINUX_VERSION:-$(echo linux-*.tar.zst | rev | cut -f 3- -d . | cut -f 1 -d - | rev)}
GLIBC_VERSION=${GLIBC_VERSION:-$(echo glibc-*.tar.zst | rev | cut -f 3- -d . | cut -f 1 -d - | rev)}

GCC_LANGUAGES=${GCC_LANGUAGES:-'c,c++'}

GCCX_TARGET=aarch64-generic-linux-gnu
GCCX_HOST=x86_64-generic-linux-gnu
GCCX_HOST_LINUX=arm64
GCCX_PREFIX=opt/gccx-$GCCX_TARGET-$GCC_VERSION

VERSION=$GCC_VERSION
TMP=${TMP:-/tmp}
BUILDDIR=$TMP/gccx-$GCCX_TARGET-$GCC_VERSION
NUMJOBS=${NUMJOBS:-"-j$(expr $(nproc) + 1)"}

rm -rf /$GCCX_PREFIX
cd $TMP
rm -rf $BUILDDIR
mkdir $BUILDDIR

export PATH=/$GCCX_PREFIX/bin:$PATH

#
# binutils
#
cd $BUILDDIR
tar --zstd -xvf $CWD/binutils-$BINUTILS_VERSION.tar.zst
cd binutils-$BINUTILS_VERSION
mkdir build.$GCCX_TARGET
cd build.$GCCX_TARGET
../configure \
  --build=$GCCX_HOST \
  --host=$GCCX_HOST \
  --target=$GCCX_TARGET \
  --prefix=/$GCCX_PREFIX \
  --disable-multilib \
  --disable-nls
make $NUMJOBS
make $NUMJOBS install

#
# gcc-base
#
cd $BUILDDIR
tar --zstd -xvf $CWD/gcc-$GCC_VERSION.tar.zst
cd gcc-$GCC_VERSION
if [[ -e libsanitizer/asan/asan_linux.cpp ]]; then
  sed -i '1s/^/#include <linux\/limits.h>/' libsanitizer/asan/asan_linux.cpp
fi
mkdir build.$GCCX_TARGET
cd build.$GCCX_TARGET
../configure \
  --build=$GCCX_HOST \
  --host=$GCCX_HOST \
  --target=$GCCX_TARGET \
  --prefix=/$GCCX_PREFIX \
  --includedir=/$GCCX_PREFIX/$GCCX_TARGET/include/ \
  --disable-multilib \
  --disable-nls \
  --disable-threads \
  --enable-languages='c,c++'
make $NUMJOBS all-gcc
make $NUMJOBS install-gcc

#
# linux headers
#
cd $BUILDDIR
tar --zstd -xvf $CWD/linux-$LINUX_VERSION.tar.zst
cd linux-$LINUX_VERSION
make $NUMJOBS ARCH=$GCCX_HOST_LINUX INSTALL_HDR_PATH=/$GCCX_PREFIX/$GCCX_TARGET headers_install

#
# glibc headers
#
cd $BUILDDIR
tar --zstd -xvf $CWD/glibc-$GLIBC_VERSION.tar.zst
cd glibc-$GLIBC_VERSION
mkdir build.$GCCX_TARGET
cd build.$GCCX_TARGET
AS=$GCCX_TARGET-as \
AS=$GCCX_TARGET-ar \
CC=$GCCX_TARGET-gcc \
CXX=$GCCX_TARGET-g++ \
../configure \
  --build=$GCCX_HOST \
  --host=$GCCX_TARGET \
  --prefix=/$GCCX_PREFIX/$GCCX_TARGET \
  --disable-multilib \
  --disable-nls \
  --with-headers=/$GCCX_PREFIX/$GCCX_TARGET/include \
  libc_cv_forced_unwind=yes \
  libc_cv_c_cleanup=yes
make $NUMJOBS install-bootstrap-headers=yes install-headers
make $NUMJOBS csu/subdir_lib
install csu/crt1.o csu/crti.o csu/crtn.o /$GCCX_PREFIX/$GCCX_TARGET/lib/
$GCCX_TARGET-gcc -nostdlib -nostartfiles -shared -x c /dev/null -o /$GCCX_PREFIX/$GCCX_TARGET/lib/libc.so
touch /$GCCX_PREFIX/$GCCX_TARGET/include/gnu/stubs.h

#
# libgcc
#
cd $BUILDDIR/gcc-$GCC_VERSION/build.$GCCX_TARGET
make $NUMJOBS all-target-libgcc
make $NUMJOBS install-target-libgcc

#
# glibc
#
cd $BUILDDIR/glibc-$GLIBC_VERSION/build.$GCCX_TARGET
make $NUMJOBS
make $NUMJOBS install

#
# gcc
#
rm -rf $BUILDDIR/gcc-$GCC_VERSION/build.$GCCX_TARGET
mkdir $BUILDDIR/gcc-$GCC_VERSION/build.$GCCX_TARGET
cd $BUILDDIR/gcc-$GCC_VERSION/build.$GCCX_TARGET
../configure \
  --build=$GCCX_HOST \
  --host=$GCCX_HOST \
  --target=$GCCX_TARGET \
  --prefix=/$GCCX_PREFIX \
  --includedir=/$GCCX_PREFIX/$GCCX_TARGET/include/ \
  --disable-multilib \
  --disable-nls \
  --enable-languages=$GCC_LANGUAGES
make $NUMJOBS
make $NUMJOBS install

#
# cleanup
#
rm -rf $BUILDDIR

ну, исключения на разных платформах могут быть реализованы по-разному. может, там просто не хватает каких-то библиотек или ещё чего-то.

А в чем сложность?

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

Practically, building cross toolchains is complicated, with lots
of  separate parts (GCC, binutils, GDB, libc, etc.) that have to
be built in  the right order and with the right options, so you
end up with some kind  of script to automate the particular builds
you want to do, and that adds  all the required options
automatically.  There are several such build systems out there
(e.g. crosstool-ng) that deal with this orchestration of
the build of different pieces of the toolchain with appropriate
options.

Building an individual piece on its own (i.e., writing your own
build system that deals with the different toolchain components
and how to build them) requires much more understanding of the
fine details of how the different configure options are specified
and how to get them to achieve what you want.  I'm familiar with
many of the details through having  written multiple such build
systems myself.

The non-sysroot form of configuring cross toolchains is to a large
extent  considered a *legacy* way to configure such a toolchain
and so has  received less attention to making it feature-complete
in its interactions  with other features (e.g. building with
installed libc at a different  path) because most people prefer
to use sysroots.

Если вкратце, то юзера вежливо послали crosstool-ng использовать, так как не юзерское это дело - кросс-компиляторы собирать.

А в чем сложность? Решил посмотреть как это делается, и вот простой скрипт который собирает под любую платформу gcc для кросскомпиляции в /opt, нужно только подложить файлы, причем можно любой версии он сам их распознает по имени: binutils-2.44.tar.zst linux-6.12.34.tar.zst gcc-15.1.0.tar.zst glibc-2.41.tar.zst

И вот так лёгким движением руки нормальный дистр превращается в Слакварь.

Не, ну тому кретину, у которого UINT8_MAX в LONG_MAX превратился, я уже поставил клоуна.

#if LONG_MAX == INT64_MAX

Да ты совсем плох, я посмотрю.

Мой вопрос был прост и понятен: зачем UINT8_MAX быть в кондишналах?

Чтобы заменить захардкоженные 0xFFFFFFF в том примере выше на UINTxx_MAX. Ну и ещё чтобы такие константы были одинаково определены для всех численных типов.

Всегда ваш Копетан Очевидность!

но не думал

Ты способен к мыслительной деятельности? Врёшь ведь!

В оригинале не было ни одной запятой про то, что это невалидное выражение даёт ошибку компиляции.

Чо? А что ещё должно давать невалидное выражение? Член на палочке да жопу с ручкой?

(~(uint8_t)0) у препроцессора превращается в (~(0) 0). Что ты ожидаешь от этого кроме ошибки? В корректные 255 это явно никак никогда не превратится, даже с твоими исправлениями.

Чо? А что ещё должно давать невалидное выражение?

Пост о том, что сломалась сборка, вместо поста о том, что нельзя использовать дифайн в сравнениях.

Я тут посмотрел, интереса ради, эту историю в репе.

Добавили:

Robert Mason <rbmj@verizon.net>  2012-10-29 01:42:48
    vxworks fixups
    
    From-SVN: r192898

и заменили:

Doug Rupp <rupp@adacore.com>  2017-06-12 15:10:12
    config.gcc (*-*-vxworks*): Set use_gcc_stdint to "provide".
    
    2017-06-12  Doug Rupp  <rupp@adacore.com>
    
    	gcc/
    	* config.gcc (*-*-vxworks*): Set use_gcc_stdint to "provide".
    	Append vxworks-stdint.h to the tm_file list.
    	* config/vxworks-stdint.h: New file.
    
    	fixincludes/
    	* inclhack.def (AAB_vxworks_stdint): Remove hack.
    	* fixincl.x: Regenerate.
    
    From-SVN: r249121

То есть почти пять лет оно жило, и никто не возражал. Правда на vxworks всего 59 багов в gcc’шной багзилле, что говорит о многом.

Пост о том, что сломалась сборка, вместо поста о том, что нельзя использовать дифайн в сравнениях.

Потому что если не использовать этот макрос, ошибки не будет.

То есть почти пять лет оно жило, и никто не возражал. Правда на vxworks всего 59 багов в gcc’шной багзилле, что говорит о многом.

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

Сборка на самом VxWorks проводилась:

https://gcc.gnu.org/legacy-ml/gcc-patches/2012-09/msg01619.html

Before submitting the patch, I tried to run «make check» and it failed miserably.

Вообще, там есть интересная ремарка:

Fix 5: Add stdint.h wrapper for VxWorks.

Vxworks stdint.h doesn’t have all the typedefs needed for standards compliance, so add a hack that adds all of the needed typedefs to be fully compliant to the standard. Fixes broken libstdc++.

There was additional discussion of adding the necessary macros to get gcc to have built-in recognition of the types, but I could not get that to work. That is also non-essential to this patch, which is primarily to fix a bug caused by relying on types in stdint.h that vxworks does not define.

Ну, то есть, какой-то чел наговнокодил хак и не придумал ничего лучше кроме как засунуть его по самые гланды в GCC. Где его радостно приняли. Просто топчик!

Какие то страшные вещи в этом треде пишут, то патчить какой то fixincludes-gcc обязательно надо в любом дистрибутиве, то вся группа разработчиков gcc не может собрать свой компилятор. Но я без какого либо опыта, написал скрипт+собрал за час себе aarch64-gcc.

Оно же в /opt/gccx-$xxx-$yyy ставит, удалить можно одним rm -rf, оригинальный комментарий «дистр превращается в слакварь» был про make install который по всей системе разбрасывает файлы.

Вся эта идея fixincludes – большая параша.

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

И если бы gcc просто в ./configure детектил проблемы и затем использовал хаки, чтобы самому скомпилироваться и работать – это было бы окей.

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

Это полный абсурд.

Извините, но если целевая платформа не обеспечивает standard compliance для компилируемого кода, это:

1. по большому счёту, не проблема компилятора
2. это не должно просто заменяться на хак.

Это должно быть явно документированное поведение: что именно не соответствует, и как именно компилятор решает эту проблему. Прямо в документации на компилятор как продукт.

У них же в лучших традициях m4-портянок, всё это навалено одной большой кучей на заднем дворе.

Ты хочешь сказать, маленькая слака лучше слаки большой? Процитирую одного персонажа:

Слака — это слака. Меньшая, бо́льшая, средная — всё едино, пропорции условны, а границы размыты. Я не святой гентушник, не только одним дебианом пользовался в жизни. Но если приходится выбирать между одной слакой и другой, я предпочитаю не выбирать вообще.

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

Но я без какого либо опыта, написал скрипт+собрал за час себе aarch64-gcc.

Да я разве против - помоги челу вот в этом триде: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879

Тут бОльшая часть разрабов гцц отписались, но он так ничего и не собрал.

Мой вопрос был прост и понятен: зачем UINT8_MAX быть в кондишналах?

Чтобы заменить захардкоженные 0xFFFFFFF в том примере выше на UINTxx_MAX.

Где ты видел в том примере UINT8_MAX, укуреный ты наш? Там есть что угодно, но не UINT8_MAX, и не его значение.

Хотел почитать, но это буквально тред «у меня все сломалось памагите!!!», он бы хоть ввод свой приложил.

Ты хочешь сказать, маленькая слака лучше слаки большой?

У меня есть вторая версия скрипта которая собирает .tgz, все отличие это указание DESTDIR и makepkg в конце. Так что добавлено всего 2 строки по сравнению с этим вариантом. Уж .deb поди запаковать тоже одной командой можно.

Тебе ещё надо вагон библиотек в свой префикс сунуть.

Какими библиотеками? Посмотри на какой нибудь TDM-GCC, там компилятор и основные утилиты, библиотеки типа SDL ты можешь уже собрать к своем приложению сам. Clang же тоже не тащит за собой arm32,arm64,riscv,mips версии всех библиотек мира.

Какими библиотеками? Посмотри на какой нибудь TDM-GCC, там компилятор и основные утилиты, библиотеки типа SDL ты можешь уже собрать к своем приложению сам. Clang же тоже не тащит за собой arm32,arm64,riscv,mips версии всех библиотек мира.

Окей, да. Мы тут две отдельные проблемы обсуждаем:

1. GCC сосёт;
2. Кросскомпиляция требует адекватного управления пакетами в префиксе.

Второе, кстати, решается в пару строк в Nix:

let
  pkgs = (import <nixpkgs> {}).pkgsCross.aarch64-multiplatform;
in
pkgs.pkgsStatic.callPackage ({ mkShell, zlib, pkg-config, file }: mkShell {
  # these tools run on the build platform, but are configured to target the host platform
  nativeBuildInputs = [ pkg-config file ];
  # libraries needed for the host platform
  buildInputs = [ zlib ];
}) {}

А дальше можно запустить nix-shell и собирать в нём всё под целевую платформу. Ляпота! Никаких портянок на баше.

Не особо понятно, можешь дать другой пример? Представим, я долго ждал когда в gcc добавят cobol, потому что gnucobol меня не устраивал. И вот я дождался, мне нужен кросскомпилятор (x86 -> arm64) gcc-gcobol, как я могу его теперь запустить на nix? Другие языки не интересуют, это для смузихлебов.

Представим, я долго ждал когда в gcc добавит cobol, потому что gnucobol меня не устраивал.

Чем не устраивал-то? Недостаточно древний?

Другие языки не интересуют, это для смузихлебов.

Сорян, Nix – это для смузихлёбов. Пока стакан смузей не выпьешь, да лавандовым рафом не запьёшь, нихрена работать не будет.

Ну вот видишь, стоит захотеть чего то лишь слегка необычного, и сразу Nix «не шмогла». А теперь показываю силу Slackware:

# export GCC_LANGUAGES='c,c++,cobol' 
# sh gccx.SlackBuild
# aarch64-generic-linux-gnu-gcobol --version
aarch64-generic-linux-gnu-gcobol (GCC) 15.1.0 

А уж как легко поставить любую нужную версию ПО, просто кидаешь app-src.tar.gz к SlackBuild и запускаешь его, мой скрипт так же написан, сам определяет нужный архив.

я никогда не слышала про crosstool-ng, но посмотрю, что это, на досуге. всегда собирала тулчейны для кросс-компиляции вручную. но таки да, это довольно геморное занятие. не потому, что сами принципы кросскомпиляции какие-то сложные. а потому, что, во-первых, есть множество патчей под разные архитектуры и сложно найти их все (и иногда дописать новые) и применить там, где нужно. от архитектуры также могут зависеть настройки конфигураций тулзов и библиотек, потому что не все фичи работают на всех платформах. во-вторых, есть неявные (и, главное, нигде не описанные) зависимости разных тулзов друг от друга. gcc, binutils, coreutils и многое другое (там ещё сотни библиотек, на самом деле) связаны множеством зависимостей, которые сильно зависят от версий. если бы сразу знать все такие наборы совместимых меж собой бибилиотек, жить было бы намного проще. но их просто не существует.

Да, что то похожее и в том триде пишут, куда я ссылку дал. Там много всяких рецептов приводится, помимо crosstool-ng. Покопай, вдруг там есть что ценное… Ну и вообще, расскажешь потом, почему всем миром не смогли помочь чуваку. Я не осилил, но вообще там интересно пишут разрабы.

я не читала там весь тред. но знаешь, некоторым людям и весь мир не поможет. просто не надо им софтом заниматься.

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

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

иногда даже под хорошо знакомую архитектуру просто тулчейн собрать бывает трудно. потому что в новых версиях натащили всяких новых фич, не все они совместимы меж собой, иногда могут появляться новые неведомые глюки. и когда, например, новые версии libc, gcc и binutils, можно довольно долго ковыряться, пока всё вообще соберётся, пройдёт все тесты и тем более когда оно успешно заработает.

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

Да силанг вам в руки. Его то и собирать не надо, он сразу мультиарч.

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

и да, я всё равно всю систему собираю из сорцов. так что сборку тулчейнов и патчи это никак не отменяет. тем более, что у меня в системе в качестве libc стоит musl. а это тоже добавляет специфику.

а насчёт стандартов добавлю:

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

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

1. вопрос поставлен неверно. правильно: «хоть одна причина… долбанных cmake, meson…»

2. юз сконс, Люк!

Кто тут хвалил мейкфайлы:
Ошибка в Makefile linux-headers при установке r8126 (комментарий)

Как в скунсе указать пользовательские сифлаги?

Корневой SConstruct:

lib = [«#build/exe»,] bin = «#build/exe»

env = Environment(… BINDIR=bin, LIBDIR=lib, LIBPATH=lib,…. CXXFLAGS=[ «-std=c++1z», ….. ) и т.д.

и/или переопределить в соотв. SConscript’ах

А без редактирования скриптов как это сделать?

в каком смысле, без редактирования? ну правь переменные окружения, они по умолчанию подхватятся, если в скрипте не переопределены.

Обычно бывают переопределены

на моей памяти только Kbuild умеет в твои хотелки

meson вполне удобен

сайт с документацией у них уж очень убогий. Даже гнушные info-страницы по всратости обошел.

waf умеет

Так используй waf, если он тебя устраивает, в чем проблема?

ну и как ты себе это представляешь? Kbuild тупо в файлики складывает команды, которые он будет исполнять для сборки той или иной цели, и добавляет его в список зависимостей.

Ни один генератор мейкфайлов (что cmake, что meson) такой ерундой не занимается.

Waf же вроде из другой оперы, это ж замена самому make/ninja.

хотя waf и наследник scons, работа над waf (суд по гиту), идёт сильно помедленнее, чем у прародителя.

так что…

в чем проблема?

Жаль, что на Пистоне.

чтобы затруднить разработку тулинга для интеграции с редакторами и IDE (Шмальман очень боялся, что gcc встроят в visual studio, не шучу)

я, кстати, [совсем недавно] видел gdb встроенное в visual studio

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

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

Жаль, у сконса нет функциональности dub’а при указании внешних зависимостей, если работаешь на D. Остальное, в общем и целом, устраивает, задачки у меня вполне себе игрушечные, на скорость сборочной системы откровенно плевать. Всё равно по сравнению со временем компиляции плюсов, такое замедление, просто откровенное «тьфу», забыть и растереть.