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

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

annulen (10.03.2010 14:36:07)

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

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

annulen (10.03.2010 14:37:48)

>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 )

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

KblCb (10.03.2010 14:59:04)

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

JackyTreehorn (10.03.2010 15:00:50)

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

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

k0l0b0k (10.03.2010 15:08:59)

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

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

annulen (10.03.2010 15:13:16)

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

Gukl (10.03.2010 15:17:53)

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

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

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

tailgunner (10.03.2010 15:18:08)

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

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

Gukl (10.03.2010 15:19:54)

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

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

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

mkfifo (10.03.2010 15:21:21)

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

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

mkfifo (10.03.2010 15:24:09)

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

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

k0l0b0k (10.03.2010 15:28:45)

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

boo32 (10.03.2010 15:29:01)

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

> Хотя никто не мешает написать свою прослойку, 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))

:-)

mkfifo (10.03.2010 15:32:19)

Вай нот?

Gukl (10.03.2010 15:46:19)

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

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

r (10.03.2010 15:50:18)

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

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

r (10.03.2010 15:51:55)

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

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

r (10.03.2010 16:08:51)

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

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

Displacer (10.03.2010 17:04:19)

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

a3 (10.03.2010 17:08:07)

> для хеллоуворлда на 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})

Reset (10.03.2010 17:32:04)

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

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

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

rudchenkos (10.03.2010 17:32:28)

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

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

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

rudchenkos (10.03.2010 17:33:36)

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

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

rudchenkos (10.03.2010 17:35:32)

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

Reset (10.03.2010 17:37:37)

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

Reset (10.03.2010 17:38:48)

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

lester_dev (10.03.2010 17:40:25)

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

Reset (10.03.2010 17:42:49)

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

Mystra_x64 (10.03.2010 17:45:49)

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

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

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

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

rudchenkos (10.03.2010 17:46:30)

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

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

rudchenkos (10.03.2010 17:48:49)

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

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

AlexM (10.03.2010 17:57:32)

> Вай нот?

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

mkfifo (10.03.2010 18:03:59)

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

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

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

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

AlexM (10.03.2010 18:14:45)

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

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

AlexM (10.03.2010 18:16:51)

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

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

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

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

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

rudchenkos (10.03.2010 18:22:23)

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

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

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

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

mkfifo (10.03.2010 18:25:04)

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

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

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

mkfifo (10.03.2010 18:25:50)

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

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

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

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

annulen (10.03.2010 18:32:55)

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

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

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

rudchenkos (10.03.2010 18:38:07)

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

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

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

rudchenkos (10.03.2010 18:39:39)

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

JackyTreehorn (10.03.2010 18:42:16)

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

JackyTreehorn (10.03.2010 18:42:50)

> "type": "program",
> "tool": "cc",
> "input": ["gtk_program.c"],
> "packages": ["gtk+-2.0"]

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

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

xintrea (10.03.2010 19:10:12)

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

vertexua (10.03.2010 19:24:42)

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

man json

lester_dev (10.03.2010 20:11:13)