Стабилизировался код проекта Flare Image Library (http://repo.or.cz/w/flare.git), в рамках которого развивается форк библиотеки Corona (http://corona.sf.net/), последний релиз которой вышел в 2003 году. Библиотека написана на языке C++ и предназначена для загрузки, записи и манипулирования изображениями в распространённых форматах (PNG, JPG, BMP, TGA и т.п.). Код распространяется под открытой лицензией zlib (http://opensource.org/licenses/zlib-license.html). Библиотека может быть собрана для широкого спектра платформ и операционных систем.
Библиотека представляет картинку как массив пикселей в нескольких форматах и не зависит от сторонних графических библиотек, таких как SDL. Также во Flare во время сборки могут быть встроены дополнительные библиотеки для работы с основными форматами (PNG, JPG и т.п.), что позволяет, например, использовать её в Windows без вороха дополнительных DLL. Для сборки библиотеки используется форк (http://repo.or.cz/w/k8jam.git) системы сборки Jam, поддерж...URL: http://repo.or.cz/w/flare.git
Новость: http://www.opennet.me/opennews/art.shtml?num=33168
Кошмар, костыль на костыле.
- библиотек для загрузки/сохранения изображений уже как собак нерезанных, ещё одна не нужна
- сборка это просто абзац. Кривой форк убогого jam.
- нет нормальных релизов, за это надо расстреливать
- репозиторий - не на github. Спасибо хоть в git.
- за .gitignore в репозитории надо отбивать яйца
- в репозиторий понапихано библиотек. jpeg, png, ungif, zlib. Ждём libc.Надеюсь, такие помойки и их криворукие авторы когда-нибудь полностью вымрут.
> - репозиторий - не на github. Спасибо хоть в git.
> - за .gitignore в репозитории надо отбивать яйцачто в этом плохого?
.gitignore как раз нужен для того, чтобы каждому новичку не настраивать его заново. Тем более, что если он забудет это сделать, в репозиторий полетит бессмысленный мусор.
точку зрения понять можно: если разработчиков несколько, то у каждого почти наверняка .gitignore свой, и git pull будет упорно его мержить. с другой стороны — тут разработчиков… ну, совсем мало, мягко говоря. поэтому пока что оно никому не мешает.
Хм... а вам никогда не приходило в голову добавить свои специфичные файлы репозоторный или свой локальный .gitignore и не мучаться с мержами?
а я-то тут при чём? мне вообще без разницы, я всё равно сразу делаю бранч и мержу очень выборочно.
> Хм... а вам никогда не приходило в голову добавить свои специфичные файлы
> репозоторный или свой локальный .gitignore и не мучаться с мержами?Свой локальный .gitignore в репозитории использовать нельзя, потому что там лежит репозиторный. Использовать системный (если git такое умеет) нельзя, потому что они разные для каждого репозитория. Закоммитить нельзя, потому что потом придётся тразаться с мержами. Залить в upstream нельзя, во-первых, потому что они там не нужны, во-вторых, потому что потом кому-то понадобится наоборот их отсутстиве чтобы можно было сделать git clean. Сечёшь? .gitignore нельзя добавлять в репозиторий.
>> Хм... а вам никогда не приходило в голову добавить свои специфичные файлы
>> репозоторный или свой локальный .gitignore и не мучаться с мержами?
> Свой локальный .gitignore в репозитории использовать нельзя, потому что там лежит репозиторный.
> Использовать системный (если git такое умеет)Ну теперь проблема ясна... вы просто не знаете что умеет git, и скорее всего не умеете им пользоваться, кроме 2-3х команд...
$ man gitignore
Which file to place a pattern in depends on how the pattern is meant to be used. Patterns which should be version-controlled and distributed to other repositories via clone (i.e., files that all developers will want to ignore) should go into a .gitignore file. Patterns which are specific to a particular repository but which do not need to be shared with other related repositories (e.g., auxiliary files that live inside the repository but are specific to one user’s workflow) should go into the $GIT_DIR/info/exclude file. Patterns which a user wants git to ignore in all situations (e.g., backup or temporary files generated by the user’s editor of choice) generally go into a file specified by core.excludesfile in the user’s ~/.gitconfig.$ cat ~/.gitconfig
[core]
excludesfile = ~/.gitignore
> что в этом плохого?
>> - репозиторий - не на github. Спасибо хоть в git.Невозможность сделать fork и pull request видеть
>> - за .gitignore в репозитории надо отбивать яйца
Потому что разработчик понятия не имеет как будет работать с его поделием пользователь, какие временные файлы будет создавать его редактор, где будет создавать объектники система сборки и какие у них будут расширения и многое другое. Когда .gitignore в репозитории, его невозможно толком настроить.
>> что в этом плохого?
>>> - репозиторий - не на github. Спасибо хоть в git.
> Невозможность сделать fork и pull request видетьложь. и форкнуть можно средствами самого repo.or.cz, и mob branch есть. ну, и почта автора там светится, можно написать.
с .gitignore согласный, лишнее оно там.
Факт в том что разработка и разработчики именно на github, так что форк не на github не более ценен чем форк у тебя на локалхосте.
> Факт в том что разработка и разработчики именно на github, так что
> форк не на github не более ценен чем форк у тебя
> на локалхосте.прям таки все-все? разработчики TCC в шоке, например.
p.s. вот когда на гитхабе уберут принудительный https — тогда оно, возможно, и будет чем-то нормальным.
>- библиотек для загрузки/сохранения изображений уже как собак нерезанных, ещё одна не нужнаНужна потому, что эта представляет собой библиотеку классов.
угадай, зачем туда «напиханы» библиотеки. в новости это даже открытым текстом написано, надо только её прочитать.
> угадай, зачем туда «напиханы» библиотеки. в новости это даже открытым текстом
> написано, надо только её прочитать.Я-то прочитал. Только зачем мне копии тухлых графических библиотек, когда у меня есть свежие в системе? Потому что в винде нет?
> Я-то прочитал. Только зачем мне копии тухлых графических библиотек, когда у меня
> есть свежие в системе? Потому что в винде нет?потому что если оно найдёт системные — то соберётся с ними, с динамикой. а если нет — то есть вариант всё равно собраться.
Клёва, давайте все зависимости теперь пихать во все репозитории. "Шоб собиралось".
> Клёва, давайте все зависимости теперь пихать во все репозитории. "Шоб собиралось".ты не поверишь, но для винды так и делают.
> ты не поверишь, но для винды так и делают.Поверю. Репозитории вантузоразработчиков сразу видно по помойке.
>> ты не поверишь, но для винды так и делают.
> Поверю. Репозитории вантузоразработчиков сразу видно по помойке.ну а что поделаешь, если для m$ нормальные репы — rocket sciense? конечно, можно и забить на винду, никто не спорит. но если таки приходится писать для вин (например, хорошие деньги дают) — поневоле таскаешь с собой 100500 библиотек. или костылишь доморощеные велосипеды, что ни разу не удобней. беда.
> Кошмар, костыль на костыле.присоединяйся и чини.
спасибо, что живой!
не иначе XD
>Для сборки библиотеки используется форк системы сборки Jam
>Выпуск "релизов" в форме тарболов разработчиком не планируется, вместо этого "релизом" предлагается считать любой удобный срез git-репозитория.Молодцы, именно так и надо с мейнтенерами. Пускай лишний раз почешут репу, соображая, какую версию у пакета прописать и побольше чертыхаются, осваивая очередную систему сборки. А то обленились совсем.
проблемы маинтайнеров — это проблемы маинтайнеров. не вижу, отчего они должны становиться проблемами разработчиков. не хотите маинтаинить — не надо, никто же не настаивает.p.s. а то, что автор ясно написал: «кидайте код в свой проект» — конечно, никак не обозначает «не надо делать пакеты», угу.
> проблемы маинтайнеров — это проблемы маинтайнеров. не вижу, отчего они должны становиться
> проблемами разработчиков. не хотите маинтаинить — не надо, никто же не настаивает.Почему тогда в новости не написано что разработчик запилил это угpёбище лично для себя и оно не пранируется к использованию кем бы то ни было ещё?
> Почему тогда в новости не написано что разработчик запилил это угpёбище лично
> для себя и оно не пранируется к использованию кем бы то
> ни было ещё?нажми «поправить» и поправь, если знаешь лучше.