Новый формат описания проектов - BuilDj

>GNOME продолжает генерировать ненужного говно.

ну так сгенерируй нужное (:

>CMake выглядит для человеческого глаза неплохо, но очень плохо поддаётся парсингу

Мсье знает толк... или это действительно нужно? Конфигурировать cmake-файлы с помощью внешнего конфигуратора - это уж как-то через край

>GNOME продолжает генерировать ненужного говно.

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

> Его бы переписать на питоне

Ага, чтобы тормозил, как scons. Нафиг, нафиг.

project( HelloWorld )
cmake_minimum_required( VERSION 2.8 )

find_package( GTK2 2.6 REQUIRED gtk )

include_directories( ${GTK2_INCLUDE_DIRS} )
add_executable( helloworld hello.c )
target_link_libraries( helloworld ${GTK2_LIBRARIES} )

install( TARGETS helloworld
         RUNTIME DESTINATION bin )

Сложно, не правда ли?

+1. Порог вхождения высокий, но если войти, ничего другого уже не хочется.

>ни разу не видел, чтобы в xml вкладывали функции. И где в зумеле списки, словари и вообще типы данных помимо строк?

man xsd пожалуйста.

>Его бы переписать на питоне

Не, пусть лучше работает также быстро, как сейчас, многократно заруливая autotools! :)

JSON мне по нраву. Автогенерируемо и расово!

>> GNOME продолжает генерировать ненужного говно.

ну так сгенерируй нужное (:

Зачем? И без нас справились - make, cmake.

> Я тоже считаю, что YAML лучше.

...был бы, если бы не пробелы. Хотя никто не мешает написать свою прослойку, YAML в JSON и обратно гоняется элементарно.

> И что тут такого нечитабельного?

а ты witespace`ы убери :-D :-D :-D

или расставь их неправильно!

а как в josn ставить комменты?

(не стёб. правда интересно)

>а как в josn ставить комменты?

или провалидировать JSON-код согласно схеме?
(аналогично НЕ стеб. реально интересно)

спасибо за json, xml не нужен чуть менее, чем совсем.

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

Хотя никто не мешает написать свою прослойку, YAML в JSON и обратно гоняется элементарно.

вот так ? :

import yaml
import json

def yaml_from_json(json_str):
    return yaml.dump(json.loads(json_str))

def json_from_yaml(yaml_str):
    return json.dumps(yaml.load(yaml_str))

:-)

Вай нот?

>Ant сравним с Make - это тупая выполнялка правил сборки, для больших проектов нужны абстракции более высокого уровня иначе поддержание системы сборки превращается в ад

Вы просто не умеете пользоваться антом.

>или провалидировать JSON-код согласно схеме?

Изобрети схему и провалидируй.

>Сабж одобряю, имхо, будет очень полезно для широкого ряда проектов.

Сабж - это не система сборки. Это хреновина для описания проектов - дальше ее надо компилировать в бэкэндную систему сборки.

> захардкоженых путей

Язык не сломался такое произносить? Может стоило вспомнить, на каком мы тут языке все говорим?

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

для хеллоуворлда на Gtk - нет.

где тут сложность?

project(hello)
find_package(GTK2 2.10 REQUIRED gtk glade)
include_directories(${GTK2_INCLUDE_DIRS})
add_executable(mygui mygui.cc)
target_link_libraries(mygui ${GTK2_LIBRARIES})

>>чтобы можно было легко писать плагины и подключать их к сборке

к cmake'у можно неволзбранно писать свои модули. Язычок конечно не слишком доставляет (что-то бейсиковое прослеживается), но в целом терпимо

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

>>CMake выглядит для человеческого глаза неплохо, но очень плохо поддаётся парсингу

Мсье знает толк... или это действительно нужно? Конфигурировать cmake-файлы с помощью внешнего конфигуратора - это уж как-то через край

Толк-то я знаю, но речь шла о коде самого CMake :)

> +1. Порог вхождения высокий, но если войти, ничего другого уже не хочется.

+1, теперь даже в голову не прийдёт долбаться с autohell. Использую CMake даже для мелких тестиков :)

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

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

Кстати, за две страницы никто не заметил ошибки в тексте - название не BuildJ, а BuilDj. Как видно, лор состоит из Ъ чуть менее, чем полностью.

А если у меня все либы лежат в одной папке, например SDK_WIN64, то как заставить этот велосипед искать их там ? По примерам что-то неочевидно.

Звиздец. Что ж оно страшное такое? :}

>>Ant сравним с Make - это тупая выполнялка правил сборки, для больших проектов нужны абстракции более высокого уровня иначе поддержание системы сборки превращается в ад

Вы просто не умеете пользоваться антом.

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

А так да - на Ant можно сделать всё, как и любую программу можно написать на ассемблере. Здесь нет почвы для спора.

> Не нужно никакого пейтона, для любителей скунс есть. Язык сборки должен быть декларативным.

Абсолютно с вами согласен. На питоне я собирался (собираюсь?) реализовать только саму систему сборки. Сборочные скрипты должны быть проще питона, то что получается на SCons имхо не очень удобно.

> а чем для сборки ант не подходит?

Они же (и мэйвен, и ант) громоздкие до степени отвращения.

> Вай нот?

ну тогда пусть делают json :-) ...

назвали бы лучше Bldjad

> Сейчас меня тут заклюют насчёт питона, но товарищи вы загляните в тот C++ :-O

А что, есть *потребность* менять именно входной язык CMake'а. По-моему, его достаточно. Ну, не для всего, но, по крайней мере, для тех задач, которые следует решать средствами стандартной сборочной системы :)

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

> омерзительный (с эстетической и только с эстетической точки зрения) синтаксис.

Хых. Бэйзик как бэйзик :) Но сборочной системе, конечно, следовало бы быть более декларативной. Ну, по крайней мере, где это возможно...

>> Сейчас меня тут заклюют насчёт питона, но товарищи вы загляните в тот C++ :-O

А что, есть *потребность* менять именно входной язык CMake'а. По-моему, его достаточно. Ну, не для всего, но, по крайней мере, для тех задач, которые следует решать средствами стандартной сборочной системы :)

Рискую повториться, но таки скажу ещё раз: питон для реализации _самого_ CMake, а язык скриптов только немного причесать.

В C++-ном коде CMake очень много вещей которые предназначены для обеспечения кроссплатформенности и есть в стандартной библиотеке питона. А ещё там не стесняются использовать вот такие типы: std::vector<std::vector<std::string> > > :)

Вобщем, я считаю что реализация CMake на питоне была бы в пару-тройку раз меньше в объёме и в 9000 раз понятнее. Плюс расширяемость была бы просто великолепной.

> Имхо, CMake пока лучшее из существующих решений для кроссплатформенной сборки нативных проектов, но он не идеален.

Его бы переписать на питоне, чтобы можно было легко писать плагины и подключать их к сборке... ну и синтаксис немного подкорректировать. Сейчас меня тут заклюют насчёт питона, но товарищи вы загляните в тот C++ :-O

а ктонить пробовал SCons ...

...я-то сам не пробовал, но из тех кто пробовал — какое ощущене?

википедия говорит что оно делалось для замены autoconf/automake :-)

> ...я-то сам не пробовал,

точнее пробовал только собирать сделанные с помощью неё проекты :-)

собралось :-)

>питон для реализации _самого_ CMake, а язык скриптов только немного причесать

/me не понимает, зачем расширять код CMake'a если можно написать для него дополнительный модуль.

Вобщем, я считаю что реализация CMake на питоне была бы в пару-тройку раз меньше в объёме и в 9000 раз понятнее.

и в пару-тройку раз медленнее

> /me не понимает, зачем расширять код CMake'a если можно написать для него дополнительный модуль.

На скриптовом языке CMake нельзя написать свой генератор или расширить существующий. В частности, из-за этого существуют такие костыли как include_external_msproject (этого тоже бывает недостаточно, например когда к солюшену нужно подключить WiX-проект).

Вобщем-то почти всё о чём я говорю возникло из проблем со сборкой виндовых проектов (и немножечко Mac OS X), при использовании только под linux, CMake - просто торт.

>>Вобщем, я считаю что реализация CMake на питоне была бы в пару-тройку раз меньше в объёме и в 9000 раз понятнее.

и в пару-тройку раз медленнее

пожалуй в 1.5-2 раза я бы стерпел :)

У меня виндовый проект, VS6 + NMake. Никаких проблем.

[вброс]А на CL так ваще в три строчки!

> «type»: «program»,

«tool»: «cc»,

«input»: [«gtk_program.c»],

«packages»: [«gtk+-2.0»]

И что тут такого нечитабельного?

Расскажи теперь, почему первые два параметра записаны просто в кавычках, а вторые два еще и в квадратных скобках.

Парадокс, но так повелось. Пока удачно

>Расскажи теперь, почему первые два параметра записаны просто в кавычках, а вторые два еще и в квадратных скобках.

man json