Тема неправильная — "для ленивых".
Я не ленивый. Но мне неинтересно собирать буст с нуля. Я никогда его не собирал и не буду собирать.
Я просто с некоторых пор начал ценить своё время. Время потраченное на изучение "как собрать буст для своей студии" я лучше потрачу на что-то более благородное — проведу время с семьёй. На крайняк подумаю над архитектурой будущей программы.
Что я получу в результате билда? Готовый бинарники которые можно слить с нета?
Море фана? В гробу я видал такой фан. Терпеть не могу собирать опенсорс-проекты с их убитой поддержкой.
Любителям буста под виндой — может кто не знает —
есть на sourceforge проект Boost C++ Libraries. Они распространяют исходники буста + собранные библиотеки в виде инсталяторов. Буст собран под многие версии msvc. Вот ссылка на последнюю версию http://sourceforge.net/projects/boost/files/boost-binaries/1.57.0/
A>Любителям буста под виндой
Скорее всего, такой любитель использует Visual Studio. А если он использует Visual Studio 2013, то там есть NuGet из коробки ( во всех версиях, включая Express ), причем достаточно новый, чтобы поддерживать установку native package. А еще, есть добрые люди которые выложили boost в репозиторий nuget.org, причем разбили его удобно на компоненты. Соответственно, все что нужно это установить пакет boost ( все хедеры ) + если используются компилируемые библиотеки ( вроде RegEx или Thread ) то добавить в проект соответствующий компонент ( можно как в виде lib так и source файлов ). А что совсем удобно, Nuget создаст файл package.conf, который можно залить в репозиторий вместе с проектом и ваши коллеги при сборке автоматически получат все нужные бустовины и не будут на вас ругаться, что им приходится какой то b2 собирать
Если любитель буста под виндой вместо Visual Studio 2013 использует более страую версию, он может невозбранно доставить туда плагин для nuget со всеми плюшками ( по крайней мере для 2010,2012 точно, для более старых версий — надо проверять )
гораздо более продвинутое средство для вендузятников, в виде менеджера пакетов, для использующих MinGW и не желающих использовать проприетарное от M$: MSYS2, с пакетным менеджером pacman, от любителей Arch
список доступных пакетов:
Здравствуйте, Abyx, Вы писали:
A>Здравствуйте, andyp, Вы писали:
A>непонимаю как можно быть настолько ленивым что не набрать в консоли "b2"
а я все время забываю, как буст собирать к очередному разу и начинаю материться. ищешь how to build boost, install boost — нифига. какие-то бусовские примеры. набираешь make — нифига,
читаешь — install — нифига, там ссылка на каой-то html, в нем нифига
запускаешь boostrap.sh — падает
вспоминаешь, что был какой-то jam, гуглишь, заходишь в утилитки, там какой-то перловский make скрипт, который тоже не работает
заходишь в папку build — там какие-то файлы v2
я последний раз уже плюнул на это, использовал только заголовки. кстати, b2 из консоли — у меня тоже не рабоатет
A>Сижу под эксперссом 2010, плагинов нет. Если и пересяду на новую студию, то она тоже будет в бесплатной редакции.
В 2013 express плагинов/расширений нет, но есть NuGet сразу и можно еще поставить PyTools ( но плагинов нет )
Но есть еще 2013 Community — это почти Professional но бесплатная и с некоторыми ограничениями. Там есть плагины ( но опять же NuGet есть и так из коробки )
A>>Любителям буста под виндой _>Скорее всего, такой любитель использует Visual Studio. А если он использует Visual Studio 2013, то там есть NuGet из коробки ( во всех версиях, включая Express ), причем достаточно новый, чтобы поддерживать установку native package. А еще, есть добрые люди которые выложили boost в репозиторий nuget.org, причем разбили его удобно на компоненты. Соответственно, все что нужно это установить пакет boost ( все хедеры ) + если используются компилируемые библиотеки ( вроде RegEx или Thread ) то добавить в проект соответствующий компонент ( можно как в виде lib так и source файлов ). А что совсем удобно, Nuget создаст файл package.conf, который можно залить в репозиторий вместе с проектом и ваши коллеги при сборке автоматически получат все нужные бустовины и не будут на вас ругаться, что им приходится какой то b2 собирать
_>Если любитель буста под виндой вместо Visual Studio 2013 использует более страую версию, он может невозбранно доставить туда плагин для nuget со всеми плюшками ( по крайней мере для 2010,2012 точно, для более старых версий — надо проверять )
Для Visual C++ 2010 Express Edition NuGet можно поставить, а затем и Boost. Здесь Boost 1.54-1.57. Библиотеки можно брать как в виде исходников (ага, будут компилироваться прям в вашем проекте с вашими настройками), так и в виде бинарников (VC100-VC120 и VC140CTP6)
пакеты хостятся на sf.net, а он, в свою очередь, использует зеркала. так, при запросе какого-нить файла, sf выдает рандомное зеркало. в твоем примере одно из зеркал отвалилось, при повторном запуске попал на "живое" зеркало.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, pykd_team, Вы писали:
_>В 2013 express плагинов/расширений нет, но есть NuGet сразу и можно еще поставить PyTools ( но плагинов нет ) _>Но есть еще 2013 Community — это почти Professional но бесплатная и с некоторыми ограничениями. Там есть плагины ( но опять же NuGet есть и так из коробки )
Ну вот, еще один повод переехать, как только закончу с текущими проектами.
Здравствуйте, Abyx, Вы писали:
A>Здравствуйте, andyp, Вы писали:
A>непонимаю как можно быть настолько ленивым что не набрать в консоли "b2"
а как новичку узнать что надо набрать b2? причем для того чтобы его сделать — сначала запустить "bootstrap.bat"
Здравствуйте, PM, Вы писали:
PM>Т.е. вы за тотальное статическое связывание с необходимыми библиотеками?
Только для тех небольших библиотек, которые редко обновляются и обновления там некритичные.
Для динамических нужны репозитории собранных [cpp] + h + lib + dll под каждую нужную версию.
PM>Как насчет оперативного исправления критических уязвимостей в той же OpenSSL?
Этих тюленей всё равно ещё собирать нужно под Win, что не так то просто сделать (эл.подписи всякие для https).
И вообще если нужно обновить OpenSSL, то нужно его обновить. Явно. До нужной тебе версии. Дин.либа в комплекте.
PM>А еще разные библиотеки используют разные системы сборки, не только make, см. название темы.
Всегда же собираются lib/dll и уже их можно подключить. И идеальная сборка это список cpp + пути include. Больше ничего.
PM>И как быть в кросс-платформенных проектах, где нужна сборка под Windows таким широко распространенным компилятором как Visual C++ ?
Настройки сборок под разные платформы или в разных форматах, или в общем типа CMake. В чём проблема?
PM>Моя точка зрения в начальном сообщении заключалась в том, что вспомогательные скрипты могут облегчить жизнь программисту.
Но зачем жизнь усложнять (усложнили) изначально? Вот в чём вопрос.
PM>Потому как в мире С++ нет совершенства, и в реальности приходится иметь дело с зоопарком библиотек, систем сборок, пакетных менеджеров.
Да всё там просто, в мире C++, ещё бы все программисты толковым образом собирали свои творения.
Здравствуйте, Abyx, Вы писали: A>непонимаю как можно быть настолько ленивым что не набрать в консоли "b2"
Ну вот есть такая фишка для очень ленивых. Там еще вроде бы b2 слепить надо, позвав bootstrap. Еще это немного времени, потраченного на сборку, экономит.
Здравствуйте, Don Reba, Вы писали:
DR>Каковы шансы, что человек, которому лень собрать буст прочитает эту вики?
так и Arch не для ленивых
только ради буста, наверное, не стОит это использовать. но с другой стороны, вместе с бустом установятся и его зависимости.
хоть мне и крайне редко приходится "трогать" вендус, но если приходится, мне намного комфортнее использовать MSYS2, ибо в нем есть все(почти) что мне нужно для кодинга, и линукс-лике среда.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, andyp, Вы писали:
A>Ну вот есть такая фишка для очень ленивых. Там еще вроде бы b2 слепить надо, позвав bootstrap. Еще это немного времени, потраченного на сборку, экономит.
Там этого времени 5 минут, если -jN не забывать.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, pykd_team, Вы писали:
_>Но есть еще 2013 Community — это почти Professional но бесплатная и с некоторыми ограничениями.
А что за ограничения, лицензионные? Я так и не нашел разницу в функционале.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, sunheretic13, Вы писали: S>Здравствуйте, andyp, Вы писали: S>Тема неправильная — "для ленивых". S>Я не ленивый.
Это точно. Откопал топик и проспамился, не лень же было
Манифест
According to Larry Wall, the original author of the Perl programming language, there are three great virtues of a programmer; Laziness, Impatience and Hubris
Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful and document what you wrote so you don't have to answer so many questions about it. Impatience: The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least pretend to. Hubris: The quality that makes you write (and maintain) programs that other people won't want to say bad things about.
Посмотрел ваше детище. Очень круто. У меня есть старая версия msys, в которой были все нужные мне библиотеки собственноручно собранные и т.д.
А теперь это все стало не нужным. Это очень хорошо, ибо обновлять это добро было тем еще квестом
В общем я посмотрел, позапускал обновления и установку всякого из репы и вот столкнулся с проблемой. Иногда при скачивании пакета он как будто теряет связь с сервером. Пишем, мол таймаут вышел, ошибка скачивания. А потом через секунду запускаешь обновление второй раз и все проходит молниеносно. Использую последнюю версию x64. Что это может быть? (на всякий случай, с интернетом у меня все ок, это точно).
Вот лог проблемы
$ pacman -S make
разрешение зависимостей...
проверка конфликтов...
Будет загружено: 3,76 MiB
Будет установлено: 14,40 MiB
:: Приступить к установке? [Y/n] y
:: Получение пакетов ...
libltdl-2.4.6-1-x86_64 28,0 KiB 0,00B/s 00:00 ##################### 100% ошибка: не удалось получить файл 'libunistring-0.9.4-2-x86_64.pkg.tar.xz' из downloads.sourceforge.net : Connection timed out after 10621 milliseconds
предупреждение: не удалось получить некоторые файлы
libgc-7.2.d-1-x86_64 60,2 KiB 873K/s 00:00 ##################### 100% ошибка: не удалось получить файл 'libguile-2.0.11-3-x86_64.pkg.tar.xz' из downloads.sourceforge.net : Connection timed out after 10538 milliseconds
предупреждение: не удалось получить некоторые файлы
guile-2.0.11-3-x86_64 761,1 KiB 1504K/s 00:01 ##################### 100%
make-4.1-2-x86_64 387,5 KiB 585K/s 00:01 ##################### 100%
ошибка: не удалось завершить запрос (непредвиденная ошибка)
Обнаружены ошибки, пакеты не были обновлены.
Повторный запуск
$ pacman -S make
разрешение зависимостей...
проверка конфликтов...
Здравствуйте, niXman, Вы писали:
X>пакеты хостятся на sf.net, а он, в свою очередь, использует зеркала. так, при запросе какого-нить файла, sf выдает рандомное зеркало. в твоем примере одно из зеркал отвалилось, при повторном запуске попал на "живое" зеркало.
Понятно. А то я привык в редхатовскому yum. А он пробует зеркала самостоятельно, не прерывая сессию. Думал тут так же должно быть
Здравствуйте, Ops, Вы писали:
Ops>А что за ограничения, лицензионные? Я так и не нашел разницу в функционале.
Аналогично — никакой разницы я не заметил, и только покрыл себя матом за то, что узнал о существовании этой версии спустя пару дней после того, как я продлил подписку MSDN. Как я понял, единственное ограничение там на размер организации.
Здравствуйте, pykd_team, Вы писали:
_>Скорее всего, такой любитель использует Visual Studio. А если он использует Visual Studio 2013, то там есть NuGet из коробки ( во всех версиях, включая Express ), причем достаточно новый, чтобы поддерживать установку native package. А еще, есть добрые люди которые выложили boost в репозиторий nuget.org, причем разбили его удобно на компоненты. Соответственно, все что нужно это установить пакет boost ( все хедеры ) + если используются компилируемые библиотеки ( вроде RegEx или Thread ) то добавить в проект соответствующий компонент ( можно как в виде lib так и source файлов ). А что совсем удобно, Nuget создаст файл package.conf, который можно залить в репозиторий вместе с проектом и ваши коллеги при сборке автоматически получат все нужные бустовины и не будут на вас ругаться, что им приходится какой то b2 собирать
А не в курсе, как можно толково подружить CMake и Nuget? Чтобы CMake искал boost и установленный пользователем, и полученный через Nuget? И можно было выбирать, какой именно использовать.
K>Аналогично — никакой разницы я не заметил, и только покрыл себя матом за то, что узнал о существовании этой версии спустя пару дней после того, как я продлил подписку MSDN. Как я понял, единственное ограничение там на размер организации.
собственно, да, пишут, что разница только в использовании:
1) индивидуальные разработчики могут использовать как угодно ( кстати, интересно, если ИП работает на крупную организацию? )
2) все организации могут использовать неограниченно для обучения, в научных целях, для разработки open source
3) во всех остальных случаях 5 лицензий на организацию, для крупных организаций ( > 250 рабочих станиций или 1млн$ выручки в год ) — лицензия не подходит ( кроме п.2 )
Хз в чём проблема собрать. Неужели ещё кто-то сидит и руками всё прописывает в консоли? Ровно один раз нагулить .bat для сборки. И при выходе нового буста нужно просто запустить бат на выполнение — и буст собирается под все используемые студии, все платформы, все конфигурации и все комбинации рантайма.
Здравствуйте, push, Вы писали:
P>Хз в чём проблема собрать. Неужели ещё кто-то сидит и руками всё прописывает в консоли? Ровно один раз нагулить .bat для сборки. И при выходе нового буста нужно просто запустить бат на выполнение — и буст собирается под все используемые студии, все платформы, все конфигурации и все комбинации рантайма.
как-то у вас все легко получается. подЕлитесь ссылочкой на батник собирающий openssl (lib и dll) из исходников?
Работает на Windows, Linux, MacOS X. Требуется установленный Perl, на Windows пытается использовать его из установленного Git. По соседству лежат скрипты для сборки Boost и V8.
Ленивый программист способен автоматизировать многое, и в первую очередь скрипты сборки своего проекта.
Здравствуйте, Ops, Вы писали:
S>>нет. пост в стиле "не стоит называть всех, кто не хочет тарахаться (в плохом смысле этого слова), ленивыми". Ops>Трахаться ты будешь потом, когда разные рантаймы вылезут.
Ты не понял, он заставит с этим трахаться таких как ты.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, PM, Вы писали:
PM>Скрипт на Python подойдёт? https://github.com/aspectron/jsx/blob/master/extern/build_openssl.py PM>Работает на Windows, Linux, MacOS X. Требуется установленный Perl, на Windows пытается использовать его из установленного Git. По соседству лежат скрипты для сборки Boost и V8.
PM>Ленивый программист способен автоматизировать многое, и в первую очередь скрипты сборки своего проекта.
Хорошие библиотеки не требуют 100500 зависимостей, которые нужно искать и собирать отдельно, притом без пакетного менеджера.
Хорошие template-библиотеки вообще не требуют сборки, только прописывания в include-путях.
А когда чтобы собрать A нужно сначала собрать В,C,D,E,F и чтобы ещё всякие X,Y,Z установлены были, а для B нужны P,Q,R, а для Q ещё S,T, а для T ещё V,W, то это не система сборки, а тупые разработчики, причём всех библиотек сразу в данной линейке, которые требуют хотя бы 1 внешнюю зависимость и не тянут с собой исходники или либы того варианта, который для них лучший в данной вариации, причём с настроенным make'ом.
Здравствуйте, EyeGem, Вы писали:
PM>>Ленивый программист способен автоматизировать многое, и в первую очередь скрипты сборки своего проекта.
EG>Хорошие библиотеки не требуют 100500 зависимостей, которые нужно искать и собирать отдельно, притом без пакетного менеджера. EG>Хорошие template-библиотеки вообще не требуют сборки, только прописывания в include-путях.
Согласен. А еще хорошо быть богатым, здоровым, и никогда не стареть.
EG>А когда чтобы собрать A нужно сначала собрать В,C,D,E,F и чтобы ещё всякие X,Y,Z установлены были, а для B нужны P,Q,R, а для Q ещё S,T, а для T ещё V,W, то это не система сборки, а тупые разработчики, причём всех библиотек сразу в данной линейке, которые требуют хотя бы 1 внешнюю зависимость и не тянут с собой исходники или либы того варианта, который для них лучший в данной вариации, причём с настроенным make'ом.
Я правильно понял, что вы против зависимостей от сторонних библиотек? И всю необходимую функциональность реализуете заново в каждом новом проекте?
EG>Пакеты маст дай, короче. Линукс вэй билд из эвил.
И конечно же вы как умный разработчик, давно решивший проблему зависимостей, сейчас поделитесь правильным рецептом.
Здравствуйте, PM, Вы писали:
PM>Я правильно понял, что вы против зависимостей от сторонних библиотек? И всю необходимую функциональность реализуете заново в каждом новом проекте?
Нет, конечно.
EG>>Пакеты маст дай, короче. Линукс вэй билд из эвил. PM>И конечно же вы как умный разработчик, давно решивший проблему зависимостей, сейчас поделитесь правильным рецептом.
Уже поделился в прошлом ответе.
Просто их код нужно включать в свой проект в подпапку, скажем, etc/ или other/
Причём в той версии которая сейчас нужная и правильная для проекта.
Любые апдейты (скажем, безопасности), менеджить через обновление этих папок. Явное!
И делать make с учётом возможности использования или не использования этого кода.
В идеале для сборки любого проекта достаточно накидать cpp файлов в новый список, прописать include-пути и всё.
Многие, правда, этому не следуют, добавляя кодогенерацию и сборку всяких левых тестов в тот же make-файл и завязывая всё на этот make-файл.
Фу так делать!
Здравствуйте, EyeGem, Вы писали:
EG>>>Пакеты маст дай, короче. Линукс вэй билд из эвил. PM>>И конечно же вы как умный разработчик, давно решивший проблему зависимостей, сейчас поделитесь правильным рецептом.
EG>Уже поделился в прошлом ответе.
EG>Просто их код нужно включать в свой проект в подпапку, скажем, etc/ или other/ EG>Причём в той версии которая сейчас нужная и правильная для проекта.
EG>Любые апдейты (скажем, безопасности), менеджить через обновление этих папок. Явное!
EG>И делать make с учётом возможности использования или не использования этого кода. EG>В идеале для сборки любого проекта достаточно накидать cpp файлов в новый список, прописать include-пути и всё.
Т.е. вы за тотальное статическое связывание с необходимыми библиотеками? Как насчет оперативного исправления критических уязвимостей в той же OpenSSL?
А еще разные библиотеки используют разные системы сборки, не только make, см. название темы.
И как быть в кросс-платформенных проектах, где нужна сборка под Windows таким широко распространенным компилятором как Visual C++ ?
Моя точка зрения в начальном сообщении заключалась в том, что вспомогательные скрипты могут облегчить жизнь программисту. Потому как в мире С++ нет совершенства, и в реальности приходится иметь дело с зоопарком библиотек, систем сборок, пакетных менеджеров.
Здравствуйте, PM, Вы писали:
PM>Я правильно понял, что вы против зависимостей от сторонних библиотек? И всю необходимую функциональность реализуете заново в каждом новом проекте?
как вы могли так плохо о нас подумать? разумеется, мы ориентируемся на передовые методики JS!