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

Такое ощущение, что тебя заставляют так делать.
Но нет, люди лучше будут использовать убогий json, чем фичастый и удобный yaml.

Чем это они вредные?

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

попробуй использовать поиск. на лоре были неоднократные срачи про cmake.

Каждый программист должен в своей жизни написать парсер конфиг файлов :)

1. Увеличивается время разработки приложения и его отладки.

2. Увеличивается количество ошибок в коде.

3. Нужно писать больше документации (если она требуется).

Поискал по «cmake» - нашёл кучу тредов-вопросов «а как мне сделать это в cmake» и несколько про миграцию с autotools на cmake.

Поискал по «autotools cmake» - нашёл треды опять же про миграцию с первого на второе и комментарии про то, что cmake не привязан к гнутому тулчейну, в отличие от autotools.

Срачей не нашёл, видимо, не умею в поиск :( Можно ссылку на какой-нибудь тред?

Красота json-a в его простоте. Синтаксис минимален, структуры данных однозначны и достаточны. Может, обилие скобок и может смутить не технической направленности пользователя, но мне json представляется намного более наглядным, нежели yaml со всей его заявленной дружелюбностью к человеку.

К тому же, глаз программиста более наметан на json из-за того, что ЯП высокого уровня обычно обладают более-менее нативной его поддержкой.

ну если поиск не нашел - то и я не найду. мне ведь придется этим же поиском пользоваться. а мне это даже не интересно.

1. зато не будет "недокументированных" глюков

2. бабка надвое нагадала

3. не нужно

Да не было особо срачей: cmake — единственная вменяемая система автосборки.

http://yaml.org/ Вот тебе пример минимального и однозначного синтаксиса. Страничка языка yaml - валидные данные в этом самом языке. Уж не знаю даже, что может быть более наглядным, чем это. Перегруженный синтаксисом json - явный пример оверинжиниринга в простейшей задаче. При этом yaml проще в простых случаях использования и мощнее в сложных случаях использования, чем json. Зачем пользоваться последним, кроме как для общения браузер-веб-сервер - я не могу найти объяснения, кроме влияния моды.

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

чисто для себя я юзаю boost build v2 (так как много работала с boost) и считаю его более гибким. хотя он и не такой интуитивный и надо изучать документацию. прежде чем им что-то собирать. зато для кроссплатформы он просто идеален.

а для парсера конфигов я юзаю boost::program_options. для простых конфигов он идеален.

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

неудобно задавать конкретные пути поиска библиотек

[PATHS path1 [path2 ... ENV var]]

и запрещать стандартные пути

[NO_DEFAULT_PATH]
[NO_CMAKE_ENVIRONMENT_PATH]
[NO_CMAKE_PATH]
[NO_SYSTEM_ENVIRONMENT_PATH]
[NO_CMAKE_SYSTEM_PATH]
[CMAKE_FIND_ROOT_PATH_BOTH |
 ONLY_CMAKE_FIND_ROOT_PATH |
 NO_CMAKE_FIND_ROOT_PATH]

Ну и в настройках тулчейна CMAKE_FIND_ROOT_PATH_MODE_LIBRARY. Что тогда удобно?

Вы пощупали этот jansson руками? Парсинг готовых сообщений там хороший. Но я что-то не могу там обнаружить создания json объекта. Я понимаю, что строку можно сделать при помощи sprintf, только вот либа сама должна уметь такое делать.

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

нет, пока не щупал ничего.

Да не было особо срачей

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

Ответ и для Eddy_Em тоже.

Собственно, я-то тоже за cmake. Меня интересует, по каким разумным причинам можно выбирать autotools вместо него, как делает тот же waker.

Меня интересует, по каким разумным причинам можно выбирать autotools вместо него

Только по одной-единственной: если автор хорошо знает автотулзы и не знает симейк.

У меня было так: я ни то, ни другое не знал. Покурил маны на то, на се... Потом сравнил скорость. Выбор очевиден. Тормозные автотулзы нафиг не нужны!

Только по одной-единственной: если автор хорошо знает автотулзы и не знает симейк.

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

Потом сравнил скорость. Выбор очевиден.

чего ж не make тогда? он еще быстрее. и ты не думал, что там не просто пустые циклы внутри, а реально какая-то работа делается? cmake быстрый потому что нихера не умеет.

чего ж не make тогда?

Писать вручную Makefile можно только если у тебя 0 зависимостей!

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

Я неоднократно видел, что делается совершенно ненужная работа! А cmake проверяет лишь то, что нужно!

Писать вручную Makefile можно только если у тебя 0 зависимостей!

man pkg-config

А cmake не проверяет то, что нужно!

FXD

Все он проверяет. Скажем, в моем одном старом велосипеде я из симейка на стадии создания Makefile компилял простенькую программку, которая получала данные видеокарты и заносила их в заголовочный файл + формировала нужные ключи по архитектуре для nvcc. Потом для gettext всякая шняга формируется. Нужные библиотеки ищутся, если для них нет pkg-config (а таких предостаточно бывает). Ну и т.п.

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

Руки ломать за чтение данных о системе во время компиляции. А если это билд сервер? Там обычно нет видеокарты.

Руки ломать за чтение данных о системе во время компиляции.

Мне пофиг на чье-то мнение по этому поводу.

А если это билд сервер?

Ты предлагаешь собирать 100500 вариантов одной программы (под каджую видеокарту свою)? Велосипед делался для личного пользования, кому не нравится — пусть форкают и делают как им удобно. Это опенсорс, детка!

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

http://lists.freedesktop.org/archives/beignet/2014-July/003527.html

http://cgit.freedesktop.org/beignet/commit/?id=83a44bc815f51af7eed46507b1e0a2...

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

Зачем мне лишняя проверка на старте, если ее можно сделать один раз — при компиляции? А при смене железа просто пересобрать!

А что будут делать простые мифические пользователи?

Все равно этот софт не для них. Ну и выше я уже писал:

Велосипед делался для личного пользования, кому не нравится — пусть форкают и делают как им удобно. Это опенсорс, детка!

Любые конфиги содержащие «объекты» - зло. Т.к. эти конфиг. объекты будут отражать внутренние объекты ПО. Не обязны, но так получается. Тот кто правит конфиги о внутр. строении ПО незнает и задалбывается искать нужный параметр в древовидной структуре. Ктому же внутр. объекты ПО меняются. И тогда или программист думает как отобразить новые объекты на старые конфиги, или админ радостно переписывает конфиги для новой версии ПО.

Конфиги в виде плоского списока ключ=значение рулят.

jq

Не ко мне вопрос, но всеже.

jansson щупал, сравнивал с аналогами, выбрал jansson, доволен, работает в проекте ежедневно в течение 2 с лишним лет, багов не замечено. Обратите внимание на корректное и своевременное освобождение памяти от использованных объектов, в апи есть для этого функции.

Юзать удобно, доки в избытке и легко усвояемы (в принципе, достаточно посмпотреть заголовочный jansson.h), собирается легко.

По вопросу. Не уверен, что все правильно понял, но для создания пустого объекта юзаем json_object(), для заполнения json_object_set_new().

если хватает json, то json, иначе xml

Опиши ситуацию, когда тебе может не хватать json, но хватит xml?

Конфиги в виде плоского списока ключ=значение рулят.

т.е., если в конфиг надо записать, например, какую-то иерархию — предлагаешь писать заююканный бинарь в виде key=value?

разделяй и властвуй

В топике обсуждают человекопонятный конфиг. Откуда бинарь?

Актуально еще?

http://zserge.com/jsmn.html

В Qt/KDE так и делается.

Есть ещё и libconfuse.

В топике обсуждают человекопонятный конфиг. Откуда бинарь?

да хоть даже из человекопонятного JSON, чтобы превратить его в key=value.

т.е. берем иерархию обхектов, генерим для нее JSON, потом его uuencode/base64encode/..., а результат - в key=value. в итоге и овцы сыты, и волки целы, и иерархии объектов как таковой в конфиге не видно :) но может я неправильно понял, что ты там писал, или ты вообще другой аноним.

В Qt/KDE так и делается.

LOL :)

Админы с тобой несогласны. Например у тебя в иерархии десятки объектов со свойством max_size. Админу надо настоить max_size оного из модулей(это насторойка модуля для адмимна, и мембер класса для программиста). Админ грепает конфиг по имени модуля и ненаходит ничего(программист 10 раз изменил свой подход к декомпозиции предметн. области модуля). Админ грепает по max_size и приходит в задумчивость, в каждом модуле 10 объектов, и у каждого есть max_size. Знаешь почему много вложенных if'ов плохой код стайл? Таже фигня с конфигами, только вложенность сделана из твоей «логичной» иерархии. Человекопонятный конфиг должен легко читаться глазами, ну или грепаться по словам из предметоной области.

админ, представь себе что в конфиг надо записать gui layout. т.е. окошки, их расположение, вложенность в друг друга, взаимосвязи. все это настраивается юзером. как ты это без иерархии сделаешь?

Опиши ситуацию, когда тебе может не хватать json, но хватит xml?

да любая ситуация, где тебе не захочется писать слово «type»

<list itemsType="SomeClass">
    <SomeClass>
        <SomeType1 id="memberID1">ValueFor_memberID11</SomeType1>
        <SomeType2 id="memberID2">ValueFor_memberID12</SomeType1>
    </SomeClass>
    <SomeClass>
        <SomeType1 id="memberID1">ValueFor_memberID21</SomeType1>
        <SomeType2 id="memberID2">ValueFor_memberID22</SomeType1>
    </SomeClass>
</list>

Т.е. понятно, что этот нулевой пример и в JSON прекрасно пишется, но с JSON та самая челокекочитаемость в данном случае будет медленно, но уверено закапываться