Отличная политика – есть только Unix, а все остальное ниипёт! Потребуется тебе, например, libiconv под Windows скомпилировать, распакуешь ее архив и обнаружишь там ахиренных размеров configure и маленький файлик README.woe32, в котором английским по белому написано:
Installation on Woe32 (WinNT/2000/XP/Vista, Win95/98/ME):
Building requires the mingw or cygwin development environment (includes gcc).
MS Visual C/C++ with "nmake" is no longer supported.
Вот так! Херня эта ваша Windows, нет Бога кроме Unix и autotools пророк его!
Не понимаю. Если в этом есть какой-то прагматизм, то он с оттенком снобизма и сепаратизма. Мол, мы, Ъ-ру Unix-оиды и нам нужен только Unix, а если тебе вдруг понадобились какие-то из наших инструментов, то давайте к нам на Колыму в Unix. А разработчики кроссплатформенного софта, видать, ими рассматриваются как шпионы или предатели истинной веры. Ну или просто мазохисты: мол, мосье хочеть познать толк в извращениях, ну тогда вот тебе библиотека с configure – острота ощущений обеспечена!
Впрочем, я забыл. Для Unix-оидов кроссплатформенность означает возможность скомпилировать программу на разных версиях Unix-а.
PS. Вообще, как я понял, если в C/C++ программе потребовалось работа с кодировками, то нужно либо брать версию 1.9.2 libiconv, скомпилированную когда-то добрым человеком под Win32. Либо использовать здоровенный ICU. Либо же задействовать QTextCodec из еще более здоровенной Qt.
35 комментариев:
Я не совсем понимаю, в чем здесь разработчики не правы? Они сделали библиотеку для unix систем. Потом уже решили, что и в windows она может пригодиться, портировали. Но видимо поддерживать порт желающих нет.
Если бы они заявляли, что это кросплатформенная библиотека, и для сборки под windows нужны инструменты типа cygwin и т.п. тогда да, можно было бы их упрекнуть. А в данной ситуации помоему все честно.
Вы неправы Евгений :)
Проблема, как мне кажется, не в том, что кто-то там вам там не хочет. Просто есть определенные ресурсы - время и человек.
Это бесплатная библиотека и разработчик поддерживает, то что надо ему. Вам надо - потратьте некоторое ваша время для поддержки Вин32 и подарите людям.
Не думаю что они откажутся от вашей помощи :)
@4ybaka:
>Если бы они заявляли, что это кросплатформенная библиотека, и для сборки под windows нужны инструменты типа cygwin
А они об этом и заявили. В файле README.woe32 как раз и описывается, как настроить и скомпилировать под Windows с помощью cygwin и mingw.
@Sanik: для некоторых библиотек (например, pcre и libcurl) мне приходится именно этим и заниматься. И там это еще возможно, поскольку библиотеки маленькие. А вот с libiconv уже страшно.
Имхо, корень зла в допотопном autotools, который уже давно пора отправить на свалку истории. Ну или был бы он, хотя бы ориентирован на Perl или Python, чтобы кроссплатформенность обеспечивалась автоматом. Так нет же, ихних configure -- это чистый unix-овый shell-скрипт.
Не держались бы Unix-оиды за свои autotools, да поменьше бы использовали у себя в коде #ifdef-ы HAVE_*, то и ситуация была попроще бы.
Там ничего не сказано про кроссплатформенность. Там сказано как настроить и собрать. Я не уверен, что эти две вещи можно приравнивать друг к другу.
@4ybaka: а вот я уверен, поскольку наличие таких инструкций и есть признание факта, что платформа поддерживается.
@4ybaka:
Да и сама постановка:
>Они сделали библиотеку для unix систем.
Вызывает вопрос: а что мешало не затачивать библиотеку под Unix изначально? Что в libiconv (перекодирование символов из одной кодировки в другую) такого системно-зависимого?
Никсоиды вообще люди суровые, они и своих бьют http://www.rsdn.ru/forum/philosophy/4033590.flat.aspx#4033590 чтобы все боялись :)
Вот еще пример OCaml 3.12.0 был выпущен еще в начале августа, бинарников под виндовс до сих пор нет http://caml.inria.fr/download.en.html
@Rustam:
>Никсоиды вообще люди суровые, они и своих бьют
Формально они правы. Но я бы, если бы знал, что существующая многие годы реализация memcpy корректно обрабатывает пересекающиеся фрагменты памяти, не решился бы ее изменить согласно стандарта.
Формально да правы.
Реально полная дурь. Там даже скорость выполнения совершенно не увеличится, раз уж функция лежит в библиотеке и следовательно вызывается через call, то проверка на пересечение практически никак ни повлияет на производительность.
@Rustam:
угу, так и есть. Но, видимо, власть в руки получил какой-то standard-nazy :)
Ну а я и не призываю вас поддерживать autotools :)
Переделайте под cmake или scons...
надо поточнее формулировать свои претензии, а то иначе можно нарваться на совсем неполиткорректный ответ насчет говновинды и далее по тексту
поточнее, видимо, будет заявить претензию к autotools; их никто божественными отнюдь не считает, и наоборот часто называют autocrap и autohell
кроме того, кое-кто собирает программы под винду не выходя из под линукса -- т.е. одним мейк-файлом и бинарники, и экзешники; я пробовал так по мелочам
еще в голову приходит мысль приспособить команднострочный msvc в качестве компилятора под cygwin; но я ниче про это не знаю
> Переделайте под cmake или scons...
раз и навсегда решить проблему лучше именно так
@Sanik:
>Ну а я и не призываю вас поддерживать autotools :)
Переделайте под cmake или scons...
Что делать мне в этой ситуации, мне понятно. Я другого понять не могу -- почему разработчиков не волнуют проблемы настоящей кроссплатформенности. Ведь очевидно же, что autotools ее не обеспечивают. Тем не менее, продолжают за них держаться.
@имя:
А говновинда и есть говновинда. И деятели, которые выпускают свои библиотеки только со студиными проектными файлами (или с MS-specific извратами внутри), в моих глазах ничуть не лучше хардкорных Ъ-GNU-программистов.
Да и проблема, с технической точки зрения, упирается даже не в отсутствие make-файлов. А в отсутствие нормальных заголовочных файлов -- там только заготовки для модификации посредством configure.
колымой, как показывает этот пример, является винда, а не юникс -- под именно под ней тебе придется ишачить, в то время как под юниксами за тебя работают авторы библиотеки и аутотулз
если не согласен -- можешь привести пример полезной бесплатной библиотеки кроссплатформенного направления, не имеющей лучшего юникс-аналога, и поставляемой только со студиными проектными файлами (или с MS-specific извратами внутри)?
Ну те кто реально заботится о кроссплатформенности, делают так чтобы было комфортно компилировать и на win и на никсах (включая и мак) как примеры boost, wxWidgets, QT, Python.
@имя:
пример и обсуждение показывает, что есть желание делить мир на хороший Unix (или Windows) и плохой Windows (или Unix). Посему разработчики решают -- вот об этом мы думаем, поскольку это классно, а вот об этом пускай у других голова болит.
Я не считаю, что это конструктивно.
Что до примеров, то лет 9 назад искал библиотеку для работы с почтой. Нашел какую-то, названия сейчас уже не помню, она была под MSVC++ заточена. Хотя очень продвинутая.
>как примеры boost, wxWidgets, QT, Python
А в Ruby, например, для конфигурирования расширений под конкретную платформу используют ruby-скрипты (отрывочная документация здесь: http://ruby-doc.org/stdlib/libdoc/mkmf/rdoc/index.html).
Получается что-то вроде configure, но зато кроссплатформенное.
> Я не считаю, что это конструктивно.
А производители ноутбуков тоже ведут себя почему-то неконструктивно. Они почему-то заботятся только о тех пользователях, что сидят под крышей, и почти никто не выпускает по-настоящему кросспогодные ноутбуки, пригодные для работы под дождем, падающем прямо на клавиатуру.
А для тех, кто хочеть работать на ноуте под дождем, большинство производителей почему-то дает обидные README с указанием "используй cygwin^Wпалатку"
@имя: не, неудачная аналогия, не катит.
я вот лично для себя, как не программиста, а как просто-пользователя-читателя-интернет, не представляю винды без cygwin
хотя бы для того, чтобы понадергать чего-то с инета, обработать перлом, заархивировать и залить на КПК читать
отношение к платформам действительно разное -- если юникс это "наша" платформа, то винды -- неизбежное зло
думаешь одному тебе не интересно поддерживать либу под винду? очевидно нет, разрабам libiconv тоже неинтересно
или допустим pdf-ки читать на КПК неудобно, так что я зачастую их обрабатываю самописными скриптами в несколько строк, превращая в упрощенный хтмл
винду я фактически использую, когда надо пожаловаться в саппорт интернет-провайдеров, либо когда мне лень нагуглить, как запустить какую-то железку под линуксом
>отношение к платформам действительно разное -- если юникс это "наша" платформа, то винды -- неизбежное зло
А мне уже давно неинтересно делить платформы на хорошие и плохие. Нахлебался и там, и там, и в других местах. Так что, по большому счету, хрен редьки не слаще.
Я хорошо понимаю разработчиков каких-то прикладных программ -- им зачастую достаточно одной платформы, чтобы разработка их кормила. Или разработчиков специализированных программных инструментов (для бодания с COM под Windows, скажем).
Но вот не понятно мне, как разработчикам такой библиотеки, как libiconv, не подумать о миллионах (а счет именно на такие порядки идет) потенциальных пользователей их творения на других платформах.
Разработчикам, например, ICU или Crypto++, или OpenSSL не пофиг.
если бы их и правда были миллионы, и они воспринимали винду БЕЗ CYGWIN-а как "нашу/свою" систему, а не ту, которую терпят и плюются -- либа давно была бы приспособлена к сборке
так что несходятся концы
да кстати, насчет миллионов -- англоязычным юзерам (читай в США, где большинство бабла) эта либа не очень нужна
в дебиане, допустим, ее нет, т.к. похожая функциональность включена вообще в libc
>либа давно была бы приспособлена к сборке
Дык когда-то давно и была приспособлена. Потом почему-то забили на это. А без сборки она точно мало кому нужна.
чисто практически, выбирая либу с возможностью кроссплатформенной реализации, я *обязательно* выясню, будет ли она кроссплатформенна; но выяснять "можно ли ее собрать без cygwin" я точно не буду; хотя, если есть 2 примерно одинаковые либы, не-аутохелл система сборки будет плюсом
@имя:
я поступаю аналогично, но вот как раз альтернативы libiconv слишком монстроузные (ICU, Qt).
Системно зависимого там думаю особо ничего и нет, ведь и под windows ее можно собрать.
В далеком 1998(9) им просто нужна была такая библиотека, поэтому она была написана с использованием принятых в той среде средств. Ну а то, что она до сих пор собирается с использованием тех самых средств нет ничего удивительного. Вам самим интересно переделывать скрипты для сборки проекта, который Вы правите от случая к случаю? При условии, что у Вас есть более интересные задачи.
@4ybaka:
к сожалению, использование autotools и только autotools характерно для многих проектов и сейчас. Кроме libiconv я вижу это на примерах pcre (там вручную нужно править файлы) и libcurl.
Ну справедливости ради стоит заметить, что pcre наряду с curl будут еще постарше iconv - у curl в 1999 уже 6 версия была. Так что это можно считать проблема проектов с большой историей.
На счет libcurl-а я, наверное, погорячился. У него в дистрибутиве какие-то файлы для cmake присутствуют.
Отправить комментарий