Кто-то тут недавно молился на OpenSource.
Вот вам небольшая сказка на ночь, характерная для openSource лично по моему опыту.
Итак, решил тут по надобности собрать из исходников торрент-качалку — Halite
Нашел на их сайте инструкцию как это сделать под Виндой в MSVC2008. Я уже давно под MSVC2010 сижу, но опыт сборки OpenSource подсказывал мне, что таки лучше собрать под VC2008. Ок, нашел 2008, установил
Итак, погнали.
1) Собираем Boost.
2) А да, для сборки Boost-а надо bjam собрать
3) Собираем OpenSSL
4) А да, для сборки OpenSSL надо Питон качать
5) Качаем проект Halite и видим зависимости от каких-то Loki, STLSoft, ну и конечно libtorrent.
6) качаем Loki, прописываем пути
7) Качаем STLSoft, прописываем пути
8) Пытаемся собрать таки libtorrent. Ну, не сразу, с качанием нескольких версий, но все-таки удалось собрать libtorrent
9) тадаааа... мы добралиьс до нужного нам проекта halite.
10) Пути на все либы в проекте прописаны черти как — приходится это самому все править ручками.
11) Ок, вроде все пути видит.
12) Запускаем Build проекта.
Тадаа!!!! 108 ошибок!!!
Есть надежда все-таки что он что-то не нашел, но нет, надежды не оправдываются, ошибки в коде или что-то по версиям либ не сошлось.
Стираем нахер все эти гребаные либы, удаляем MSVC2008, форматируем диск, идем спать. Будь они прокляты!!!
а всё виной — глав-торчок столман, который распространял свои полоумные идеи, и теперь куча шериданов зомби, трактуя эти полоумные идеи по-своему и делая их ещё хуже, направляет лучи опенсорса туда куда надо и не надо, высерая периодически поделки под ярлычком "opensource". самое забавное, что если говно сделать opensource говном, то оно по-прежнему останется говном. парадокс.
з.ы. что касается лицензий, то большинство проектов под GPL можно смело отправлять на помоечку, а тех кто использует GPL — на метанчик. ибо истинное православное свободное ПО только под BSD-like лицензиями.
з.з.ы. свобода в GPL такая же, как и в россии демократия
Здравствуйте, Anpek, Вы писали:
A>Кто-то тут недавно молился на OpenSource. A>Вот вам небольшая сказка на ночь, характерная для openSource лично по моему опыту.
Где явно сказано, что и как качать, и где скачать версии либ, готовых для билда.
For the purposes of this guide get the latest shipped source archive from the Halite sf.net project page. Extract the archive somewhere, it contains the libtorrent, Loki, STLSoft and OpenSSL versions used to build that particular release.
Из идеи скачать последние версии либ (вы бы ещё ночной снапшот скачали) выйти ничего хорошего не могло. Человек же, который так делает при условии что автор выложил полный готовый к сборке архив, у меня как у программиста вызывает недоумение
A>Тадаа!!!! 108 ошибок!!! A>Есть надежда все-таки что он что-то не нашел, но нет, надежды не оправдываются, ошибки в коде или что-то по версиям либ не сошлось. A>Стираем нахер все эти гребаные либы, удаляем MSVC2008, форматируем диск, идем спать. Будь они прокляты!!!
Гады. Изобрели кампутер, понапридумывали программ...
Все правильно, так и должно быть. Штатный способ сборки:
./configure && make
Windows и MacOS собираются по остаточному принципу, дань кроссплатформенности. Обычно в этих целях выделена виртуальная машина где <b>один раз</b> все настроено и клепаются билды. Делать <b>вменяемую</b> систему сборки под Windows и MacOS — долго и требует <b>очень</b> высокой квалификации. Для Qt сделали — с трудом, годами правя многочисленные баги , плача и колясь — но сожрали таки кактус. Там теперь под виндой тоже собирается nmake. А вот Oracle с Virtualbox, к примеру — не смогли. Литерально. И написали на форуме — что мол "вот примерные инструкции по памяти как мы настраивали билд машины". У кого то даже получается собрать, на таких как на героев смотрят.
Так что это в целом не open source, а toolchain'ы сборки в Windows и MacOS. Они слабо преднозначены для сборки сложных, имеющих большое количество зависимостей программ. Это я говорю как человек, который такие программы собирает начиная с Visual Studio 6.0 .
Здравствуйте, Eye of Hell, Вы писали:
EOH>Так что это в целом не open source, а toolchain'ы сборки в Windows и MacOS. Они слабо преднозначены для сборки сложных, имеющих большое количество зависимостей программ. Это я говорю как человек, который такие программы собирает начиная с Visual Studio 6.0 .
Вообще то это autoconf и т.п. — это давно устаревшие, кривые и неудобные системы сборки. Есть нормальные современные кроссплатформенные инструменты, но до сих пор многие пользуются устаревшими. Т.е. под виндой и маком то сам autoconf работает, но реальную кроссплатформенность на нём делать — это повеситься. )))
Далее, единственное отличие у линуха (кстати у мака такая же схема, если вы не в курсе — это же bsd по сути) от винды, это централизованное место хранение инклудов и библиотек, хотя его и не обязательно использовать. Но это нисколько не мешает собирать использовать любые библиотеки и под виндой. Просто прописываем пути.
Мы использую в своих проектах множество опенсорс (только не GPL — брррр) библиотек и под виндой и под линухом и под маком. И никогда особых проблем не было — авторы библиотек предусматривали нормальное (нативное) построение. А потом просто пути прописываем (для windows) в нашей нормальной системе сборки и всё.
Здравствуйте, Eye of Hell, Вы писали:
EOH>Так что это в целом не open source, а toolchain'ы сборки в Windows и MacOS. Они слабо преднозначены для сборки сложных, имеющих большое количество зависимостей программ. Это я говорю как человек, который такие программы собирает начиная с Visual Studio 6.0 .
если бы людей действительно интересовала сборка проектов под разными осями, они бы писали конфиги для мавена. Вместо этого они таки да — плачут, колются, и рассказывают, какие плохие эти ваши венда с макосью, в которой мавен доступен из коробки. Опенсорс такой опенсорс.
Здравствуйте, Yarik_L, Вы писали:
EOH>>Так что это в целом не open source, а toolchain'ы сборки в Windows и MacOS. Они слабо преднозначены для сборки сложных, имеющих большое количество зависимостей программ. Это я говорю как человек, который такие программы собирает начиная с Visual Studio 6.0 .
Y_L>если бы людей действительно интересовала сборка проектов под разными осями, они бы писали конфиги для мавена.
Да-а? И с каких это пор Maven научился собирать что-то кроме явы?
И нафига он в теме про boost?
Y_L> Вместо этого они таки да — плачут, колются, и рассказывают, какие плохие эти ваши венда с макосью, в которой мавен доступен из коробки. Опенсорс такой опенсорс.
Вам, видимо, всё равно, в какую тему такие реплики вставлять.
Здравствуйте, alex_public, Вы писали:
EOH>>Так что это в целом не open source, а toolchain'ы сборки в Windows и MacOS. Они слабо преднозначены для сборки сложных, имеющих большое количество зависимостей программ. Это я говорю как человек, который такие программы собирает начиная с Visual Studio 6.0 .
_>Вообще то это autoconf и т.п. — это давно устаревшие, кривые и неудобные системы сборки.
Чего это Вы заговорили про autoconf?
Autotools вообще-то изначально предполагались и разрабатывались под очень специфическую цель: собрать продукт на машине, где нет ничего, кроме того, что описано по требованиям Posix.
Соответственно, они обязательны только для весьма специфического софта — грубо говоря, компилятор C, binutils, улучшения системных средств, и собственно средства поддержки сборки.
И для этой цели они ничуть не устаревшие.
Но никто Вас не заставляет их использовать; более того — рекомендуется использовать то, что Вам удобнее и при этом адекватно работает.
Понимаю, что "у кого что болит...", но вроде бы ни одно из обсуждаемых тут средств не использует autotools для себя. Boost так точно не использует.
Здравствуйте, Yarik_L, Вы писали:
Y_L>Здравствуйте, netch80, Вы писали:
N>>Да-а? И с каких это пор Maven научился собирать что-то кроме явы?
Y_L>с таких
Плагин на левом сайте? Не считается (по крайней мере пока не будет поддержан или в исходной поставке, или кем-то из великих)
Здравствуйте, netch80, Вы писали:
N>>>Да-а? И с каких это пор Maven научился собирать что-то кроме явы?
Y_L>>с таких
N>Плагин на левом сайте? Не считается (по крайней мере пока не будет поддержан или в исходной поставке, или кем-то из великих)
этот сайт как раз и есть "кто то из великих" для проекта, все плагины с него есть в центральном репозитории и соответственно могут быть вызваны напрямую из командной строки. Этого достаточно?
Здравствуйте, Yarik_L, Вы писали:
Y_L>>>с таких N>>Плагин на левом сайте? Не считается (по крайней мере пока не будет поддержан или в исходной поставке, или кем-то из великих) Y_L> этот сайт как раз и есть "кто то из великих" для проекта, все плагины с него есть в центральном репозитории и соответственно могут быть вызваны напрямую из командной строки. Этого достаточно?
На maven.apache.org оно числится как "а вот ещё такая херня есть, мы, так уж и быть, их опишем".
Отсутствие всякого упоминания возможности собирать что-то кроме Java на главной странице — показывает отношение к этому проекту.
Я собственно не против потенциальной возможности такое использовать — хотите, так пожалуйста. Меня сильно смущает именно предложение как "универсального" средства — средства, сделанного для Java, работающего через Java, к которому возможность другой сборки пристроена кое-как сбоку, не числится в основных средствах и чревато отсутствием поддержки, как только закончится настроение у очередного энтузиаста.
А ещё вместо потенциального "а вот его таки можно собрать" Вы бы лучше рассказали, как именно Maven поможет тут справиться со всей спецификой сборки под Windows, включая особенности версий, пути к участвующим средствам, как с автоопознанием, так и с явным заданием (вдруг кто-то хочет для части файлов применить другой компилятор), и так далее. А то принципиальное умение чего-то собрать вызовом одного gcc без указания пути (или аналогом подобного для Windows) как-то не впечатляет...
Здравствуйте, Anpek, Вы писали:
A>Есть надежда все-таки что он что-то не нашел, но нет, надежды не оправдываются, ошибки в коде или что-то по версиям либ не сошлось. A>Стираем нахер все эти гребаные либы, удаляем MSVC2008, форматируем диск, идем спать. Будь они прокляты!!!
Собирать свободный софт в несвободной ОС — занятие не для слабонервных. В том же Linux обычно всё куда проще.
Здравствуйте, Eye of Hell, Вы писали:
EOH>Все правильно, так и должно быть. Штатный способ сборки: EOH>
EOH>./configure && make
EOH>
EOH>Windows и MacOS собираются по остаточному принципу, дань кроссплатформенности. Обычно в этих целях выделена виртуальная машина где <b>один раз</b> все настроено и клепаются билды. Делать <b>вменяемую</b> систему сборки под Windows и MacOS — долго и требует <b>очень</b> высокой квалификации.
Это решается куда проще даже без разных систем сборки. Берется тетрадочка. Бумажная. И в ней подробно и точно документируется все что делается. Какая виртуальная машина, какая версия гостевой ОС, как ее ставили, потом что именно и каких версий ставили, какие настройки вводили и т.п.
Точно, ничего не пропуская. Потом все это переносится в компьютер в файл. Или сразу набивается в какой-то параллельно запущенный текстовый редактор не так важно.
Здравствуйте, Michael7, Вы писали:
M>Это решается куда проще даже без разных систем сборки. Берется тетрадочка. Бумажная. И в ней подробно и точно документируется все что делается. Какая виртуальная машина, какая версия гостевой ОС, как ее ставили, потом что именно и каких версий ставили, какие настройки вводили и т.п.
А еще лучше записывать не в тетрадочку, а сразу в скрипт. И обозвать потом этот скрипт сборочным.
Здравствуйте, netch80, Вы писали:
N>Чего это Вы заговорили про autoconf?
Я отвечал как раз на реплику что типа ./configure && make — это правильный способ и это проблемы windows и mac, что там с этим сложнее.
А на самом деле это всё устаревшие техники вообще не подходящие для кроссплатформенных продуктов.
N>Понимаю, что "у кого что болит...", но вроде бы ни одно из обсуждаемых тут средств не использует autotools для себя. Boost так точно не использует.
Вот как раз с Бустом у меня ни разу нигде проблем не было и это хороший пример качественного опенсорс проекта с удобной кроссплатформенной сборкой.
этот сайт как раз и есть "кто то из великих" для проекта, все плагины с него есть в центральном репозитории и соответственно могут быть вызваны напрямую из командной строки. Этого достаточно? 
