https://www.opennet.ru/openforum/vsluhforumID3/71496.html Расти Рассел (http://en.wikipedia.org/wiki/Rusty_Russell) (Paul "Rusty" Russel), являющийся разработчиком таких систем как netfilter/iptables и lguest, в своем блоге (http://rusty.ozlabs.org/?p=140) поделился идеями по разработке библиотек на языке Си, в контексте развития своего нового проекта CCAN (http://ccan.ozlabs.org/index.html) - аналога архива CPAN для языка Си, в котором представлены (http://ccan.ozlabs.org/list.html) небольшие модули с реализацией определенных функций. <br><br><br>Поводом для написания статьи послужил анализ исходных текстов библиотеки для обработки динамических массивов разреженных данных по хеш-индексу Judy (http://judy.sourceforge.net/) и свободного аудио-кодека codec2 (http://codec2.org/):<br><br><br><br>- Подготовка существующего кода для пакетирования в библиотеку нарушает наглядность, в основном, из-за большого объема инфраструктуры пакетной информации, требуемой для autoconf, и, даже если исходные тексты, как это часто делается, поместить в src/, порядка не добави...<br><br>URL: http://rusty.o https://www.opennet.ru/openforum/vsluhforumID3/71496.html#75 Wed, 03 Nov 2010 02:59:11 GMT Ничего страшного. К pkg-config приучается же народ понемногу. А если на паре-тройке основных платформ будет, то и остальные потянутся. А пока можно просто смотреть - если что-то определено - брать инфу, если нет - автотулзы, по старинке. В общем, вопрос маркетинга в основном.<br> https://www.opennet.ru/openforum/vsluhforumID3/71496.html#74 Tue, 02 Nov 2010 15:30:24 GMT &gt; Пункт 1 легко исправляется выбором правильного инструмента для сборки проекта.<br>&gt; http://sourceforge.net/projects/mk-configure/<br>&gt; Один (под)проект -- один Makefile.<br>&gt; Одна команда для сборки проекта -- mkcmake.<br>&gt; Все.<br><br>Ээ, он уже больше не на bmake? или стал таскать с собой?<br> https://www.opennet.ru/openforum/vsluhforumID3/71496.html#73 Mon, 25 Oct 2010 13:45:30 GMT &gt; Пункт 1, как раз - чуть ли не единственный разумный пункт. autotools<br>&gt; это вообще дикость.<br><br>http://sourceforge.net/projects/mk-configure/<br>http://mova.org/~cheusov/pub/mk-configure/mkc-presentation.pdf<br><br>&gt; Вместо того, чтобы держать в среде информацию о<br>&gt; ней же и модифицировать при изменениях среды, идёт длиннющая и неудобочитаемая<br>&gt; последовательность эвристик, тупо повторяющаяся для каждого пакета.<br><br>Состояния среды можно держать в mkc-mk/sys.mk,<br>но в конкретно imake даже хуже на практике.<br><br>&gt; Как и за идею отказаться от вменяемой<br>&gt; диагностики и обработки ошибок и тупо завершать программу. Да и рекомендация<br>&gt; свалить проблемы плюсовиков на них самих, мягко говоря, не идеальна.<br><br>+2<br> https://www.opennet.ru/openforum/vsluhforumID3/71496.html#72 Mon, 25 Oct 2010 13:29:25 GMT Пункт 1 легко исправляется выбором правильного инструмента для сборки проекта.<br><br>http://sourceforge.net/projects/mk-configure/<br><br>Один (под)проект -- один Makefile.<br>Одна команда для сборки проекта -- mkcmake.<br>Все.<br> https://www.opennet.ru/openforum/vsluhforumID3/71496.html#71 Mon, 25 Oct 2010 07:29:13 GMT гм.. уже посмотрел..<br><br> https://www.opennet.ru/openforum/vsluhforumID3/71496.html#70 Sat, 23 Oct 2010 09:13:26 GMT &gt;[оверквотинг удален]<br>&gt;&gt; #define PRId32 "d" /* int32_t */<br>&gt;&gt; #define PRId64 "lld" /* int64_t */<br>&gt; Отлично. Вы эти макросы в реальной жизни пробовали применять? Впрочем, вижу, пробовали:<br>&gt;&gt; [code]printf("%" PRIdLEAST64, some_value)[/code] религия не позволяет?<br>&gt; увы, религия не позволяет. Потому что:<br>&gt; 1. такой способ записи подходит только в лабораторных условиях. _Читать_ (а наглядность<br>&gt; - главное достоинство printf-like форматирования) подобный код - задача не для<br>&gt; слабонервных. Попробуйте туда засунуть ещё пару целочисленных значений, да с какими-нибудь<br>&gt; модификаторами для разнообразия, и результат показать здесь. А потом оценить количество<br>&gt; людей, которым понравится портабельность _такой_ ценой.<br><br>Этот вопрос не ставился. Был вопрос о реальности портабельности &#171;родными&#187; средствами языка. Это не говоря о том, что описываемые вами ситуации в рамках нормальной программы &#8212; редкость. Часто повторяющиеся *printf() выносятся https://www.opennet.ru/openforum/vsluhforumID3/71496.html#69 Sat, 23 Oct 2010 07:38:15 GMT &gt; #define PRId8 "d" /* int8_t */<br>&gt; #define PRId16 "d" /* int16_t */<br>&gt; #define PRId32 "d" /* int32_t */<br>&gt; #define PRId64 "lld" /* int64_t */<br><br>Отлично. Вы эти макросы в реальной жизни пробовали применять? Впрочем, вижу, пробовали:<br><br>&gt; [code]printf("%" PRIdLEAST64, some_value)[/code] религия не позволяет?<br><br>увы, религия не позволяет. Потому что:<br><br>1. такой способ записи подходит только в лабораторных условиях. _Читать_ (а наглядность - главное достоинство printf-like форматирования) подобный код - задача не для слабонервных. Попробуйте туда засунуть ещё пару целочисленных значений, да с какими-нибудь модификаторами для разнообразия, и результат показать здесь. А потом оценить количество людей, которым понравится портабельность _такой_ ценой.<br><br>2. от того, что я придумаю макрос PRIdLEAST64 там, где его нет, "стандартная для платформы" реализация printf не научится волшебным образом понимать эт https://www.opennet.ru/openforum/vsluhforumID3/71496.html#68 Sat, 23 Oct 2010 01:04:46 GMT &gt;&gt; Всего лишь заголовочный файл.<br>&gt; П-цаны, _откуда_ , _откуда_ , скажите, сделайте милость, всплыл этот дурацкий inttypes.h<br>&gt; в вопросе форматирования сообщения fprintf'ом? Кое-кто здорово заменил исходную задачу<br>&gt; той, с которой ему удобно сражаться, и понеслось...<br><br>Вы это серьёзно? Или вы в inttypes.h ни разу не заглядывали?<br>[code]<br>/* fprintf macros for signed integers */<br>#define PRId8 "d" /* int8_t */<br>#define PRId16 "d" /* int16_t */<br>#define PRId32 "d" /* int32_t */<br>#define PRId64 "lld" /* int64_t */<br>[/code]<br>И т.д.<br><br>&gt;[оверквотинг удален]<br>&gt; классический fprintf.<br>&gt; В результате 4 (четырёх) попыток ответа на вопрос, как отформатировать fprintf'ом вывод<br>&gt; типов size_t, off_t и int16_t, я дождался от Вас только предложения<br>&gt; форматировать size_t при помощи модификатора z (непортабельного в заметной степени), ненужных<br>&gt; мне, в общем, сведений о том, как форматировать ptrdiff_t и п https://www.opennet.ru/openforum/vsluhforumID3/71496.html#67 Sat, 23 Oct 2010 00:43:48 GMT &gt; Всего лишь заголовочный файл.<br><br>П-цаны, _откуда_ , _откуда_ , скажите, сделайте милость, всплыл этот дурацкий inttypes.h в вопросе форматирования сообщения fprintf'ом? Кое-кто здорово заменил исходную задачу той, с которой ему удобно сражаться, и понеслось...<br><br>&gt; Мимо. :)<br><br>Это точно, точнее не скажешь. <br><br>Итого, подведём промежуточные итоги. Исходным тезисом являлось утверждение о том, что (ANSI-) C'шный рантайм обладает достаточной портабельностью и универсальностью, чтобы можно было не задумываясь применять его в широкопортабельных проектах (порты с Ubuntu/32 на Debian/64 не в счёт). В качестве примера такой универсальной функции приводился классический fprintf.<br><br>В результате 4 (четырёх) попыток ответа на вопрос, как отформатировать fprintf'ом вывод типов size_t, off_t и int16_t, я дождался от Вас только предложения форматировать size_t при помощи модификатора z (непортабельного в заметной степени), ненужных мне, в общем, сведений о том, как форматировать ptrdiff_t и предложения таскать за собой _реа