Take - минимальная система сборки на C++ с конфигом на TOML вместо Makefile

[CoolCmd]

компилируется одним make

тц тц тц. по канону нужно make заменить на take.

[SilverTrouse]

что там с поддержкой модулей с++20?

[Roit_liasp]

По поводу С++20 modules:

Сама система take сейчас собираеться под C++17.

А в конфигурациях пользователей можно указать любой стандарт (включая С++20 и выше) - просто пишешь в [vars]

STD = "c++20"

и дальше используешь modules, если компилятор поддерживает.

[SilverTrouse]

Там же подвох в том что артефакты модулей для сборки иначе собираются ( в отличии от стандарных cpp ) , поэтому и спрашиваю как в этой системе сборки работает поддержка модулей

[AoD314]

Оно умеет определять что команды не зависимы и будет запускать команды компиляции или линковки в параллель?

[Roit_liasp]

Параллельной сборки в 0.0.5 пока нет - зависимости выполняются последовательно.

В 0.0.6 планирую добавить простое отслеживание уже выполненных задач + базовую возможность параллельного запуска независимых команд.

Пока приоритет был на простоту и надёжность.

[Roit_liasp]

Правка: 0.0.5 на 0.0.4

[domix32]

[vars]

почему vars, а не env? кушает ли оно перегрузки из внешнего env? есть ли возможность держать несколько наборов под разные компиляторы? Работает ли оно в CI/CD с матрицами значений? есть ли дефолтные значения чтобы не копипастить как в вашем примере с run_linux? Сравнивали с каким-нибудь bazel?

[Roit_liasp]

Спасибо за подробный комментарий!

[vars] - сделано в первую очередь для визуальной простоты и удобства новичков.

Хотелось, чтобы конфиг выглядел понятно даже человеку, который первый раз видит TOML.

почему vars, а не env?

Имя с префиксом env: идёт в std::getenv, всё остальное сначала в builtins (TAKE_FUNC, TAKE_DIR, ARGS), потом в [vars]:

• [vars] - константы зафиксированные в репозитории. Конфиг самодостаточен: склонировал - собрал, поведение не зависит от того, что у кого-то выставлено в шелле.

• ${env:VAR} - явное обращение к внешнему состоянию, и это видно прямо в месте использования.

Если бы ${CXX} молча резолвился из окружения, один и тот же take.toml собирал бы разное на разных машинах, и коллизии с системными переменными были бы неизбежны.

кушает ли оно перегрузки из внешнего env?

Нет, не кушает. getenv вызывается только для имён с префиксом env: привычный по Make паттерн CXX=clang++ take build ничего не изменит ${CXX} всегда возьмёт значение из [vars].

есть ли возможность держать несколько наборов под разные компиляторы?

Встроенных профилей нет: ни [vars.gcc]/[vars.clang], ни условных секций, ни include-директивы. Рабочие варианты на 0.0.4:

а) Отдельные файлы + -f:

take -f take.gcc.toml build
take -f take.clang.toml build

Минус - дублируется весь файл, общих частей вынести некуда.

б) Функция на компилятор в одном файле:

[vars]
STD   = "c++17"
FLAGS = "-O2 -Wall -Wextra"
[build-gcc]
run = ["g++ -std=${STD} ${FLAGS} -Iinclude src/main.cpp -o take-gcc"]
[build-clang]
run = ["clang++ -std=${STD} ${FLAGS} -Iinclude src/main.cpp -o take-clang"]

Работает ли оно в CI/CD с матрицами значений?

Работает, но "наоборот": матрица живёт в YAML CI-системы, а take только читает ${env:...}:

matrix:
  cxx: [g++, clang++]
steps:
  - run: take build
    env:
      CXX: ${{ matrix.cxx }}

[build]
run = ["${env:CXX} -std=${STD} ${FLAGS} -Iinclude src/main.cpp -o take"]

есть ли дефолтные значения чтобы не копипастить как в вашем примере с run_linux?

Да, частично:

run_linux / run_macos / run_windows -> run_unix (только не Windows) → run

То есть общий случай пишется один раз в run, а ОС-специфичные ключи - только там, где реально отличия:

[build]
run         = ["${CXX} -std=${STD} ${FLAGS} src/main.cpp -o ${OUT}"]   # дефолт для всех
run_windows = ["cl /std:${STD} src\\main.cpp /Fe:${OUT}.exe"]        # только отличие

Сравнивать с Bazel не могу - никогда его серьёзно не использовал.

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

[Desertoad]

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