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

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


Есть CMake - остальное все от лукавого.

И, да: нахрена так писать?

set(QT_LIBS ${QT_LIBRARIES})

А все остальное засовывается в отдельный файл и вызывается одной командой.

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

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

Теперь понял. ППКС.

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

qmake — это независимый .deb/.rpm пакет, который не тянет за собой Qt4. Я его свободно использую для программ без Qt4.
Синтаксис простой и понятный, намного лучше cmake, т.к. кривой поиск программ в системе никому не нужен взамен на over9000 строк кода нужного для того, чтоб создать свой проект или подключить исходники другого.

/me CMake hater, посмотрите к чему приводит его использование в проекте MITK. Превращает библиотеку в мега-супер-дупер проект, под который разработчик должен делать программы следуя шаблонам, вместо того, чтобы просто делать линк с оными библиотеками[кривые руки — да, но CMake здорово поспособствовал].

blinkenlichten
()

Была идея построить нечто похожее на компилируемом лиспе. Профиты - скороть ибо натив, DSL для описания проекта, возможность скриптования в императивном стиле. DSL можно мутить в разных стилях: от высокоуровненого описания проекта до make-подобного синтаксиса.

Но за эту штуку не возьмусь пока не наткнусь на грабли со множеством систем. Пока копаю maven. Он типа мощный, не радует пока огромная простыня вывода.

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

Мавен заточен под жабу и декларативен до невозможности (про написание своих mojo я не говорю. Жаль только, что нельзя свои моджи писать на жытоне, например).

Собирать мавеном плюсовые проекты - это предел извращений.

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

qmake — это независимый .deb/.rpm пакет, который не тянет за собой Qt4.

<что-то головного мозга>. Без Qt4 его собрать нельзя, неважно, что он там в итоге «тянет»

Синтаксис простой и понятный, намного лучше cmake

см. мой пост qmake hater'а выше

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

Ну и для нескольких версий Qt одним бинарником qmake собирать невозможно принципиально, так как в нем вшиты пути.

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

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

В результате получим одну систему сборки с поддержкой 100500 несовместимых между собой DSL

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

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

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

В любом случае

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

И вытанцовывать надо от императивщины. Тогда будет очень хорошо. Иначе - будет очередной лисапед для 10% случаев. Синтаксис - не самая большая проблема билдеров.

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

И не собирался собирать плюсовый код мавеном. Копаю его по работе для явы. Я о том, как вообще могут быть устроены системы сборки, в том числе для явы.

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

Для ябы он очень хорош же. Хотя имеено что для сборки, для остального надо немножко извращаться. С тем же антом скрещивать.

wolfy
()
Ответ на: В любом случае от wolfy

Будешь делать свой лисапед - посмотри на ант.

Синтаксис - не самая большая проблема билдеров.

И тем не менее, XML, мягко говоря, плохо сочетается с императивщиной.

сравнительная легкость создания своих тасок на разных языках

этот момент не очень понятен. Допустим, у меня есть premake на Lua, и я хочу запилить новую таску. Если я делаю это на том же Lua, я могу невозбранно использовать среду проекта. Если же я захочу, например, сделать таску на питоне, мне придется передавать набор переменных, что фактически будет равносильно таску на lua с кодом os.execute(«path/to/script.py » .. myargs)

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

Не понял цепочки рассуждений к такому выводу. Особенно учитывая, что этой системы нет и это только идея.

Скриптование для поиска либы на DSL с командами типа find-file, другое DSL для описания проекта. Можно и смешать учитвая, что все это будет лиспокод.

crutch
()

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

crutch
()

Вот вы мне скажите, придурки, как с помощью всех этих cmake, qmake и прочего(да даже этого вот) - собирать проекты на Common Lisp, например?

Ладно, хрен с ним с CL. На жабе то как? На C#, к примеру?

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

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

И, по схожим причинам ты никогда не сможешь сделать нормальную _кроссплатформенную_ систему сборки, даже для одного языка, типа сишечки. Самая более-менее кроссплатформенная система для Си, например, это autotools - а они Пиздец Какое Говно(вот такое вот, да, крупными буквами). Но ты думаешь они просто так такое говно? А нет. Говно они потому, что нацелены на тотальную кроссплатформенность, а ее, как известно, не существует.

Ну а так, для говна типа сишечки или плюсцов уже есть тот же make. Да или хотя бы msbuild какой-нибудь.

lovesan

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

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

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

А так - в принципе и пофиг, пиши на луе и пусть скриптуется на луе.

И тем не менее, XML, мягко говоря, плохо сочетается с императивщиной.

XML просто писать неудобно. Девелоперы упростили себе разбор исходника в AST.

А так - у меня там много императивного кода.

[code] <if> <not> <and> <isTrue /> </and> </not> <then> [/code]

И это, в принципе, самый существенный недостаток анта - плохо читаемый/сложно сопровождаемый код.

Дальше идут нетипизированность сущностей (всё - строки, java properties), отсутствие нативных списков, не очень гибкое управление выводом, сложности с передачей параметров комстроки (пришлось соорудить своё соглашение о параметрах, вроде такого: таска с именем something - для проставления флагов, с именем @mode - режимов, с именем Task - цели).

Фундаментальная сложность - «процедурный» стиль. ООП бы там очень лишним не было.

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

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

ANT. Модульный, яойный и няшноватый.

wolfy
()

Было бы круто, если бы эта штука умела генерировать:

  • rpm
  • deb
  • ebuild
  • innosetup
AoD314
() автор топика

Остановимся на поддержки следующих языков

  • C/C++/Qt
  • OpenCL/Cuda
  • C#
  • D
  • Tex(LaTeX, MikTex)/Rst
  • Java
AoD314
() автор топика

Из недавнего сообщения стало понятно

Сообщения не читал, но лучше CMake ты ничего не изобретёшь. Замечательный синтаксис, офигенно удобная расширяемость и куча всего изкоробки. Аналогов нет и не предвидится, ублюдство кривое (scons), а особенно кривое и маргинальное (waf, premake) можно сразу закопать.

anonymous
()
21 мая 2012 г.

Кросскомпиляция заработает? Если нет, то сразу в топку.

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

Если в системе сборки будут хоть какие либо языки и платформы жестко прописаны, то эту систему сборки надо удавить в зародыше.

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