LINUX.ORG.RU

[Идея] Универсальная система сборки ( убийца cmake/scons/waf/premake )

 


1

1

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

Предлагаю «разработать» новую систему сборки с красивым и простым синтаксисом и большим кол-вом плюшек.

Чтобы было от чего отталкивался, предлагаю первый - очень грубый вариант:

файл solution - основной, с базовыми определениями.

solution = "hello"
    # comment
    flags.release = flags.02, flags.wall, flags.c++11, flags.sse41
    flags.reldeb  = flags.02, flags.g

смысл сборки такой, указываем bs(build system) файл solution, дальше система сканирует систему каталогов и ищет проекты.

существует возможность отключать проекты: однако если мы отключим проект «mylib», то получим ошибку, т.к. проект name требует mylib

project = c++              # supported: mingw, gcc, clang, icc, microsoft  
    name = "name"
    type = app
    version = 1.0.41
    files.srcs = ["src/*.cpp"]
    files.hdrs = ["src/*.hpp", "src/version.h"]
    request = packages.Qt(>=4.7), packages.tbb(=3.0<=4.1), packages.boost(<=1.48.0), packages.mylib
project = c # на этапе конфигурации можно выбрать компилятор 
    name = "mylib"
    version = 0.1.1
    type = static lib
    flags.release = flags.02, flags.wall
    files.srcs = ["src/*.c"]
    files.hdrs = ["src/*.h"]
    request = packages.tbb(=3.0<=4.1), packages.boost(<=1.48.0)
project = tex              # supported: miktex, texlive, ...
    name = "tex_name"
    type = pdf             # pdf, ps, dvi
    files.srcs = ["doc/*.tex"]
project = c++, cuda 
    name = "cuda_app"
    type = app
    use = false # по умолчанию отключен
    files.srcs = ["src/*.cpp", "src/code.cu"]
    files.hdrs = ["src/*.hpp"]
    request = packages.cuda(=4.0)

теперь нет необходимости писать много года типа

find_package(Qt4 4.7.0 COMPONENTS QtCore QtGui QtNetwork REQUIRED)
include(${QT_USE_FILE})
include_directories( ${QT_INCLUDE_DIR} )
set(CMAKE_INCLUDE_DIRS_CONFIGCMAKE "${CMAKE_INCLUDE_DIRS_CONFIGCMAKE} ${QT_INCLUDE_DIR}")
set(QT_LIBS ${QT_LIBRARIES})
...

теперь можно так:

...
    request = packages.Qt(>=4.7)

Возможность генерировать Visual Studio 2010, Eclipse, QtCreator(плагин), GNUMakefile, xCode, PythonScript(самосборка - типа scons/waf)

возможность использования ccache, distcc

предлагайте улучшения ...


ещё добавь «показать вывод препроцессора для заданного каталога(-ов)»

pacify ★★★★★
()

а как с java? :)

Pi ★★★★★
()

Почитайте про maven. Если сварганите что-то похожее (не обязательно с конфигами на XML), если оно будет иметь похожие стадии сборки (с расширением функционала через плагины), и к тому же с возможностью тянуть пакеты по зависимостям при помощи нативного для дистра менеджера, то памятник Вам поставят при жизни.

Slavaz ★★★★★
()
Ответ на: комментарий от Slavaz

да, было бы круто. Мавну просто, у него основной - java, что освобождает от ряда проблем. Остальное умеет плагинами, но обычно все равно для jvm. А тут натив, с ним не так просто.

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

maven мне не нравится из-за xml синтаксиса:

<project>
  <modelVersion>4.0.0</modelVersion>
  ...

слишком много мусора, так проще:

project
  modelVersion = 4.0.0
  ...

AoD314
() автор топика
Ответ на: комментарий от AoD314

Причем тут синтаксис. Делай другой. Ты просто фичи посмотри и как все организовано. Возможно увидишь решение проблем наперед, а так бы пришлось отхавать кактус

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

А тут натив, с ним не так просто.

ИМХО должно быть просто в использование, а не в реализации.

AoD314
() автор топика
Ответ на: комментарий от Slavaz

То есть, единственное достоинство новой системы сборки - это компактные конфиги?

Не только. Например, отключение проектов(дерева проектов) из компиляции, смена компилятора, выбор другой библиотеки через gui(было скомпилировано с qt 4.7.1 переключаем на 4.7.3), простой синтаксис(даже пусть кода будет много, лишь бы читался очень просто)

AoD314
() автор топика
Ответ на: комментарий от AoD314

Постарайся на бумагу выписать фичи по уровню полезности. Ты загорелся сменой компилятора, хотя у 95% один компилятор С++. Думай, будет оно надо или нет.

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

Ты загорелся сменой компилятора, хотя у 95% один компилятор С++. Думай, будет оно надо или нет.

Да, необходимо. Просто потому, что если ты пишешь кроссплатформенное приложение, а такое бывает(иначе ты просто бы использовал какую либо IDE), то для более высокого качества кода, хотелось бы проверить работоспособность программы/библиотеки с несколькими компиляторами (узнать про ошибки компиляции или ворнинги)

AoD314
() автор топика
Ответ на: комментарий от AoD314

Да, но место такой фиче на 138 месте в рейтинге нужных фич. Ты о тестах подумал? Различные интеграции с CI и т.д.

vertexua ★★★★★
()
Ответ на: комментарий от schizoid

Про qmake зря забыл.

Это больше «Qt only» нежели универсальная штука.

Даже не представляю как с помощью qt собрать можно собрать cuda программу, графическое приложение на C# и документацию к ней в latex. Для этого оно явно не предназначалось ...

AoD314
() автор топика
Ответ на: комментарий от vertexua

Ты о тестах подумал?

project = c++
    name = "tests"
    type = apps # каждый int main(){} - это приложение
    use = false
    files.srcs = ["src/*.cpp"]
    request = packages.googletests

Различные интеграции с CI

С BuildBot точно проблем не будет.

«P.S. На работе используем c++/cmake/buildbot/{windows, linux, macos}»

AoD314
() автор топика
Ответ на: комментарий от AoD314

судя по всему никому это не нужно ...

AoD314
() автор топика
Ответ на: комментарий от AoD314

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

Так что 3.5 тонный грузовик можно не рассматривать...

nanoolinux ★★★★
()

Библиотеки компилированные набигают

Универсальная система сборки - это нечто директивное и с большой библиотекой задач. Навроде apache ant.

Только:

1) Без простынь xml

2) С легким созданием своих задач

3) Изначально ориентированное на императивность

wolfy
()
Ответ на: комментарий от AoD314

согласен, но это не аргумент в пользу того, что qmake можно выкинуть.

nanoolinux ★★★★
()
Ответ на: комментарий от AoD314

Иногда не хватает легкого подключения проектов на других системах сборки.

kulti ★★
()
Ответ на: комментарий от Slavaz

не обязательно с конфигами на XML

обязательно не с конфигами на XML

annulen ★★★★★
()

предлагайте улучшения

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

annulen ★★★★★
()

Не нужно

Универсальная система сборки

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

vasilenko ★★
()
Ответ на: комментарий от schizoid

Когда-то я тоже думал, что qmake вполне нормален. Однако в курпных проектах у него проявляется туева хуча недостатков. Некоторые из них:

  • Без документа «undocumented qmake» (как бы намекает на возможные последствия) практически невозможно сделать в проекте хотя бы что-то нетривиальное (а чем сложнее проект, тем больше нетривиальных вещей приходится делать)
  • Крайне хреновая расширяемость. Попробуй написать функцию или цикл - запаришься разбираться, где надо ставить $$, где не надо. И грузить prf-ки из локального проекта нельзя.
  • Вообще в языке куча подводных камней, чего стоит требование к расположению «{» в одной строке с условием или «else».
  • Убогая организация вложенных проектов. На каждый задрипанный тест понадобится отдельный каталог. В subdirs-проектах нельзя объявлять общие параметры конифгурации, приходиться писать отдельные пришники
  • Пришник включается в прошник как есть => весь спектр недостатков, присущих сишному #include, плюс необходимость писать имена файлов с $$PWD
  • Нет настоящей системы конфигурации. да, можно передавать qmake знаечния переменных, но для того, чтобы узнать, что можно настраивать, придется читать код проекта
  • Можно продолжать дальше, но для меня и этого достаточно
annulen ★★★★★
()
Ответ на: комментарий от annulen

Вы наблюдаете скорее первую мысль, не же ли draft стандарта ...

а так, похоже?

project = c++              # supported: mingw, gcc, clang, icc, microsoft
{
    name = "name"
    type = app
    version = "1.0.41"
    files.srcs = ["src/*.cpp"]
    files.hdrs = ["src/*.hpp", "src/version.h"]
    request = packages.Qt(">=4.7"), packages.tbb()
}

AoD314
() автор топика

«разработать»

тогда неизбежно получится «система» :)

annulen ★★★★★
()
Ответ на: комментарий от AoD314

draft стандарта

ух ты как пафосно

а так, похоже?

похоже.

На Premake было бы что-то вроде

project "name"
  kind "ConsoleApp"
  version "1.0.41"
  files { "src/*.cpp", src/*.hpp", "src/version.h" }
  uses { "Qt >=4.7", "tbb" } 
annulen ★★★★★
()
Ответ на: комментарий от annulen

Если есть варианты, по улучшению синтаксиса, то будет интересно их увидеть/услышать.

AoD314
() автор топика
Ответ на: комментарий от schizoid

Не пробовал ещё на QBASIC писать ОС?

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

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

annulen ★★★★★
()
Ответ на: комментарий от annulen

* грабли при попытке как-то использовать генерируемые не qmake'ом сорсы или ресурсы

annulen ★★★★★
()

Молодец. Здорово придумал. А чем это отличается от реально существующего premake, если конечно не брать во внимание то что он не тянет за собой пистон и qt?

KblCb ★★★★★
()
Ответ на: комментарий от annulen

Изначально ориентированное на императивность

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

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

wolfy
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.