LINUX.ORG.RU

Ответ на: комментарий от AnDoR

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

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

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

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

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

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

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

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

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

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

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

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

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

NegatiV ()
Последнее исправление: NegatiV (всего исправлений: 1)
Ответ на: комментарий от waker

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

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

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

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

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

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

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

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

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

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

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

3. не нужно

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от devsdc

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

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Corey

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

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

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

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

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

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

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

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

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

[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. Что тогда удобно?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

man pkg-config

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

FXD

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Eddy_Em ☆☆☆☆☆ ()

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

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

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

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

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

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

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

conalex ★★★ ()
Ответ на: ИМХО от Stil

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Опиши ситуацию, когда тебе может не хватать 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 та самая челокекочитаемость в данном случае будет медленно, но уверено закапываться

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