Comments 16
Извините за оффтопик, но почему первая картинка в bmp?
Кстати, LGPL в принципе не запрещает статическую линковку, просто нужно быть готовым по первому требованию выдать пользователю набор .o и .a файлов, с помощью которых он может перелинковать приложение с собственной версией lgpl библиотеки. Не так уж это и страшно для проприетарного приложения.
Спасибо за уточнение. Действительно:
"«For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights»"
Добавлю в статью.
"«For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights»"
Добавлю в статью.
Я одного не пойму: зачем включать в статью объяснение терминов open source / free software, если сам не разбираешься в вопросе?
Ваше толкование open source и free software содержит весьма серьёзные ошибки.
Ваше толкование open source и free software содержит весьма серьёзные ошибки.
Какие?
Если под «Free software» понимать определение FSF/Столлмана, а под «Open source software» понимать определение OSI, то эти 2 множества лицензий не взаимоисключающие, как вы пишете («open source означает копилефт, free — нет»). Эти 2 определения _ничего_ не говорят о копилефтности. Соответствующие множества лицензий, «open source» и «free», совпадают на 99%, тк эти определения довольно близки. GNU GPL удовлетворяет обеим определениям, её можно назвать и опенсорсной, и свободной. MIT — тоже. Семейство BSD — тоже. И то это очень грубо (насколько я знаю, удовлетворение пунктам обоих определений у всех этих лицензий не стопроцентное).
В свою очередь, открытые/свободные лицензии делятся на «вирусные» (aka копилефтные) — GNU GPL, и либеральные (пермиссивные) — MIT, BSD, Apache.
Так что разница между терминами достаточно субъективная. Термином «свободное ПО» обычно пользуются сторонники GPL и копилефта, чтобы подчеркнуть социальную роль такого ПО. Термином «опенсорсное ПО» — сторонники либеральных лицензий, чтобы подчеркнуть, что им больше важен технический аспект, совместная работа над кодом. Ещё раз повторюсь, это всё очень грубо, как минимум потому что хесть принципиальные расхождения между некоторыми второстепенными пунктами определений и их трактовкой, а ещё всё усложняется из-за аспектов технического характера, например лицензирование ПО при линковке (см. LGPL).
В свою очередь, открытые/свободные лицензии делятся на «вирусные» (aka копилефтные) — GNU GPL, и либеральные (пермиссивные) — MIT, BSD, Apache.
Так что разница между терминами достаточно субъективная. Термином «свободное ПО» обычно пользуются сторонники GPL и копилефта, чтобы подчеркнуть социальную роль такого ПО. Термином «опенсорсное ПО» — сторонники либеральных лицензий, чтобы подчеркнуть, что им больше важен технический аспект, совместная работа над кодом. Ещё раз повторюсь, это всё очень грубо, как минимум потому что хесть принципиальные расхождения между некоторыми второстепенными пунктами определений и их трактовкой, а ещё всё усложняется из-за аспектов технического характера, например лицензирование ПО при линковке (см. LGPL).
Вообще, вы во многом правы. Почитав текст LGPL-лицензии я понял, что не стоило опираться на чтение только производных статей, а почитать самому тексты лицензий. Поленился, это да. Не подскажете, как лучше всего поступить? Наверно, стоит временно вывести статью в черновики, исправить раздел, лучше ознакомившись с информацией, и вернуть его обратно? Не знаете что при этом случится с ссылкой на статью (она используется в рамках других статей цикла)?
Почему-то очень мало кто знает про две полезные опции CMake:
1. Out-of-tree build, без перехода в build папку вручную
Очень часто бывает неудобно писать скрипты вида:
mkdir build
cd build
cmake…
cd…
Вот более лаконичный эквивалент:
mkdir build
cmake -H. -Bbuild
2. Компиляция средствами CMake
Когда мы сгенерировали файлы проекта, надо запустить компиляцию:
make -Cbuild -j
или
ninja -Cbuild -j Debug
или
call vcsetvars.bat
devenv build\ALL_BUILD.sln /build Debug
фи. Можно проще: cmake --build build --config Debug
1. Out-of-tree build, без перехода в build папку вручную
Очень часто бывает неудобно писать скрипты вида:
mkdir build
cd build
cmake…
cd…
Вот более лаконичный эквивалент:
mkdir build
cmake -H. -Bbuild
2. Компиляция средствами CMake
Когда мы сгенерировали файлы проекта, надо запустить компиляцию:
make -Cbuild -j
или
ninja -Cbuild -j Debug
или
call vcsetvars.bat
devenv build\ALL_BUILD.sln /build Debug
фи. Можно проще: cmake --build build --config Debug
Ух ты. Круто, спасибо! Попробуй завтра (хм… даже сегодня уже) и добавлю в статью.
Вообще, я вот хочу ещё с find_package разобраться и тоже про него добавить что-нибудь. Вроде, полезная штука должна быть.
Вообще, я вот хочу ещё с find_package разобраться и тоже про него добавить что-нибудь. Вроде, полезная штука должна быть.
Он хороший, но надо понимать его ограничения. Если мы пишем маленькую утилиту, то несомненно find_package(Qt) и готово. С другой стороны, если у нас большой коммерческий продукт, то возникают вопросы: какая версия библиотеки в наличии; как наложить свои патчи, которые нельзя влить в upstream; как тонко настроить опции компиляции; что делать когда библиотека пропала из интернета (см. leftpad истерию три недели назад). Тут принцип «все свою ношу с собой» подходит лучше.
Добавил в статью. Спасибо.
Sign up to leave a comment.
Капелька рефлексии для С++. Часть вторая: публикация на GitHub