> Для сравнения: бесплатному решению требуется порядка 10 минут на запись фильма объёмом 10 Гб, а при установленном драйвере Paragon NTFS for Mac 12 – около минуты с небольшим.
Честно говоря, какие-то детские проблемы — как можно не понимать что используемые глобально сущности не могут быть определены локально? А именно в этом проблема в обоих примерах.
Касательно разруливания этого в CMake, красивое решение для встроенной в проект библиотеки — set(MYLIB_DEFINITIONS "-DFOO" PARENT_SCOPE). Так логика установки флагов остаётся у библиотеки, а родительский проект получает оные после add_subdirectory так же как это обычно получается после find_package.
Ещё надёжнее решение с configure_file — так (как вы заметили) флаги не будут болтаться в командах, их нельзя будет забыть включить, но библиотеке в любом случае надо будет передавать родителю MYLIB_INCLUDE_DIRS (source и binary пути к заголовочным файлам — не забудьте что сгенерённый после configure_file заголовок попадает в binary директорию), и MYLIB_LIBRARY (тут просто имя цели библиотеки) с упомянутым PARENT_SCOPE. Решение с configure_file также удобнее в плане выноса библиотеки в самостоятельный проект — т.е. такой который можно без изменений как установить в систему через make install, так и включить непосредственно в проект, причём для проекта разница также будет всего в одной строке — find_package vs. add_subdirectory.
> При использовании configure_file следует помнить, что теперь проставления препроцессорных определений «снаружи» конкретного проекта через add_definitions работать не будет
А вот так делать и не нужно. Библиотека должна конфигурироваться через CMake — родительский проект должен только установить высокоуровневые cmake-переменные, а не лезть в низкоуровневые флаги компилятора. При этом если эти настройки действительно повлияют на флаги, оные вернутся родителю описанным выше способом.
Нет, странно выглядит то что вы несколько примеров нужных фич языка оформили как полное ТЗ. Я вас поправил.
> Грубо говоря, если нужно сделать свой велосипед, почему бы не использовать хотя бы стандартные гайки
Если уж опускаться до аналогий, то зачем если нужен велосипед, выпиливать его из самолёта? А стандартных гаек там достаточно — в плане синтаксиса ничего нового не изобретено.
> Однако, имеется определённый порог вхождения, отсутсвие или слабая выразительность многих привычных языковых средств.
Это «отсутсвие или слабая выразительность» для системы сборки — как мана небесная, поскольку на cmake всё-таки собирают проекты, а не часы рисуют. Для этого выразительности не только хватает — её столько, что многие вещи сильно упрощаются, а писать хитровыгнутые конструкции желание пропадает. Я достаточно насмотрелся на SCons'овские скрипты от питонистов, которые во всю используют «привычные языковые средства» — разбираться в этом невозможно. Как результат, порог вхождения как раз намного ниже, чем если бы использовался язык общего назначения.
> Сильно сомневаюсь что можно найти, хоть какой то код на CMake, который будет выглядеть проще и лаконичнее чем аналог на любой распостранёной скриптоте общего назначения.
Как-бы DSL всегда быть проще и лаконичнее языков общего назначения. Несколько примеров я привёл выше.
> то встроить поддержку CMake в ваше любимое IDE
Да, давайте выбирать язык для системы сборки на основании лёгкости встраивания его в моё любимое IDE. Да и про лёгкость я бы поспорил — если и понадобится глубокий разбор cmake, то пожалуй проще будет разобрать его синтаксис, чем js, где нужное определение цели возможно придётся вытаскивать через несколько замыканий.
Этот пример я комментировать не буду, потому что это ненормальное программирование. А вот примеров из реальной жизни можно привести много:
— Нормальное раскрытие переменных а-ля make (message(«Building ${FOO} with ${BAR}» вместо плясок с кавычками и плюсами)
— В том числе рекурсивное (${FOO_${BAR}}) которое иначе потребовало бы запаковку значений в словари и обратно
— Отсутствие необходимости писать кавычки почти везде
— Нормальный foreach по содержимому массива
— Форсирование повторения условия в endif/endfor/end* что сильно увеличивает читабельность
— Именованные аргументы на мой взгляд сделаны очень удобно
— Правильная передача значений в дочерние CMakeLists.txt и обратно (PARENT_SCOPE)
— Кэшированные переменные и все их атрибуты
— Макросы
Почему вы думаете что свой язык чем-то хуже любого существующего и/или что существующий язык способен эффективно решать все возможные проблемы так что его нужно использовать и в системе сборки? Системы сборки с существующими языками (m4, python) мы уже видели, они отвратительны.
> А если платформа желает стать стандартом для движка СКВ git в интернете, ей необходимо понравиться всем — и «нищебродам», и «толстосумам»
Нет. Не надо мешать инструменты использующиеся в корпоративной среде и в разработке свободных проектов — это совершенно разные классы и требования, часто несовместимые. Эти миры пересекаются очень слабо, а если и пересекаются то скорее в другую сторону — «на работах» ставят то к чему привыкли работники.
> на работе программерам развернули движок, они к нему привыкли, он им нравится, дома они начинают искать хостинг на этом движке или разворачивать его самостоятельно, для себя, в результате в сети появляется открытый сервис на этом движке.
Причины по которым разворачивать движок не имеет смысла я уже озвучил, а очередной бесплатный глобальный хостинг должен чем-то привлечь пользователей, для которых GitHub уже стандарт.
> Сравните цену за GitLab с поддержкой с приведенным выше тарифом. Пятьдесят баксов в год! Всего пятьдесят баксов. Это мы с вами, скинувшись напополам, могли бы приобрести на двоих. Как вам разница в сто раз? Не аргумент, чтобы смотреть с оптимизмом?
Ещё раз, основной массе свободных проектов это и бесплатно не нужно. Конкуренция на корпоративном рынке и её последствия для GH как хостинга — это отдельная тема, которую я обсуждать не вижу смысла. И причин для оптимизма тут нет, поскольку если конкуренция на корпоративном рынке отрицательно скажется на состоянии GH, то пострадает сообщество.
Судя по статистике переходов с хабра, библиотека многих интересует. Сделал туториал: github.com/AMDmi3/libSDL2pp-tutorial и постараюсь написать по нему статью.
Не станет, как не стал за 7 лет gitorious. Собственные установки таких движков имеют смысл при закрытой разработке в больших командах. Для открытой разработки это ненужные накладные расходы на поддержку инфраструктуры и, главное, отрыв от сообщества.
> Для одного проекта они будут актуальны. Для сообщества они уменьшаются в соответствие с количеством используемых сайтов и долей проектов на них.
Предпосылки и вытекающие из них рассуждения неверны. Потерять половину репозиториев ничем не лучше чем все. Свободные проекты это не песок который остаётся песком если отсыпать половину, а набор уникальных сущностей, проблема у значительной части которых — проблема всех. При этом чем больше хостингов, тем больше вероятность потери одного из них. Вы, грубо говоря, предлагаете RAID0 для увеличения надёжности. Кроме того, проекты с почившего хостинга в любом случае переезжают на самый популярный, т.е. в перспективе получаем, опять таки, один GitHub. Каждый отдельный репозиторий или пользователь не выигрывает ничего, но теряет аудиторию и удобство взаимодействия, сообщество теряет целостность, а эти факторы куда важнее, чем гипотетический переезд раз в десятилетие.
При этом всём, компрометация github как единственного хостинга будет означать неизбежность перехода на полноценную децентрализацию (одной из попыток такое сделать был gitchain) и такие проекты наконец начнут развиваться. Этот момент тоже не имеет смысла оттягивать.
> Откуда должны взяться альтернативы в идеальном случае? Я не спрашивал про текущую ситуацию.
Не вижу смысла отвечать на чисто гипотетический вопрос.
> Вы пытаетесь убедить остальных, что GitHub должен быть единственным сайтом, на котором происходит F/OSS разработка.
Я говорю о том что GitHub обладает наибольшей аудиторией и игнорировать это крайне глупо — на любом другом хостинге ваш проект будет отдалён, если не отрезан от этой аудитории, а в открытой разработке доступность — один из самых критичных факторов. При этом все риски гитхаба будут актуальны и на любом другом существующем хостинге.
> Я говорю, что он должен быть не единственным таким сайтом.
То есть всё-таки предлагаете. Тогда раскрывайте мысль: сколько должно быть сайтов, по каким критериям нужно определять на каком сайте хостить проект, хостить ли на одном или сразу на нескольких, и т.д. Если на одном, то чем не-github будет лучше github, а если на нескольких, собираетесь ли вы зеркалировать issues и wiki (при всех проблемах с этим, которые сами же перечислили) или нет (значит с возможностью потери данных плюс с необходимостью разбираться с дубликатами).
> Судя по вашему профилю на BitBucket, проекты, находящиеся там вы всё‐таки не игнорируете
То есть количество репозиториев и дата вам ничего не говорит? На вопрос вы не ответили.
> Кстати, вы так и не ответили на вопрос о том, откуда должны взяться альтернативы GitHub, если их никто не будет использовать по причине непрактичности.
Вопрос некорректен ибо содержит ложные предпосылки. Альтернативам не надо браться — они есть сейчас. Не нужные в данный момент по причине более низкой популярности, но, в принципе, готовые занять место гитхаба случись что с ним.
> … с файлами в определённом формате. Который на разных сайтах может различаться.
Даже если кто-то ещё не поддерживает markdown, разметка wiki — это в любом случае plaintext.
> Только если есть скрипты для эскпорта и импорта. Иначе вам придётся их писать, при этом обязательно вылезет то, что разные сайты поддерживают разные возможности.
При чём тут разные сайты? Одна миграция — один скрипт на всех.
> Корректный failover может быть невозможен по причине потери данных из‐за недоступности сайта. Чем бы вы не пользовались (даже если сайтов несколько) вам нужно периодически сохранять резервную копию issues и wiki, но если сайт используется один, то тут возникают проблемы, т.к. для непопулярных сайтов не написаны скрипты импорта.
Сохранять надо только issues, потому что wiki, повторюсь, обычный git репозиторий. При чём тут непопулярные сайты я не понял.
> Кстати, объясните‐ка мне, откуда появится «следующий по популярности сервис», если по вашему мнению точка взаимодействия одна?
Одна, потому что всё что хостится вне гитхаба выпадает из сообщества. Однако не все это понимают, поэтому другие хостинги ещё существуют.
> У вас — может быть. Другим нравится бо́льшая отказоустойчивость этой модели: тот же fossil (в одном репозитории сам код, wiki и issues) не просто так возник.
«Не просто так» им никто не пользуется.
Минусы github мне прекрасно известны, мне интересно что вы предлагаете в качестве альтернативы.
> Пары команд? Вы забываете про wiki и issue tracker. Если вторую и третью команду за вас ещё не написали, то просто так вы не отделаетесь. Плюс ещё нужно найти все места, где вы использовали старый URL и переделать его на новый.
wiki это такой же git репозиторий. С issue пока сложнее, но экспортировать их не проблема.
> А точка взаимодействия F/OSS сообщества ни в коем случае не должна быть ровно одна, потому что это порождает единую точку отказа.
Нет тут точки отказа. Точка взаимодействия по своей природе подразумевайт failover на следующий по популярности сервис в случае проблем с текущим. И да, она должна быть одна, потому что любое другое количество кратно уменьшает эффективность взаимодействия и увеличивает накладные расходы.
> Если бы github был каким‐нибудь «распределённым» p2p сайтом, который никак не может закрыть один человек (здесь — владелец GH), то ещё можно было бы подумать. Защищённость сообщества от различных форс‐мажоров — это тоже чисто практическое соображение.
Распределённое VCS хранилище это, конечно, замечательно, но повода использовать его нет и не будет, пока работает github.
Подробное описание процесса тестирования будет?
> договорился — оплатил — забрал из закладки.
Касательно разруливания этого в CMake, красивое решение для встроенной в проект библиотеки — set(MYLIB_DEFINITIONS "-DFOO" PARENT_SCOPE). Так логика установки флагов остаётся у библиотеки, а родительский проект получает оные после add_subdirectory так же как это обычно получается после find_package.
Ещё надёжнее решение с configure_file — так (как вы заметили) флаги не будут болтаться в командах, их нельзя будет забыть включить, но библиотеке в любом случае надо будет передавать родителю MYLIB_INCLUDE_DIRS (source и binary пути к заголовочным файлам — не забудьте что сгенерённый после configure_file заголовок попадает в binary директорию), и MYLIB_LIBRARY (тут просто имя цели библиотеки) с упомянутым PARENT_SCOPE. Решение с configure_file также удобнее в плане выноса библиотеки в самостоятельный проект — т.е. такой который можно без изменений как установить в систему через make install, так и включить непосредственно в проект, причём для проекта разница также будет всего в одной строке — find_package vs. add_subdirectory.
> При использовании configure_file следует помнить, что теперь проставления препроцессорных определений «снаружи» конкретного проекта через add_definitions работать не будет
А вот так делать и не нужно. Библиотека должна конфигурироваться через CMake — родительский проект должен только установить высокоуровневые cmake-переменные, а не лезть в низкоуровневые флаги компилятора. При этом если эти настройки действительно повлияют на флаги, оные вернутся родителю описанным выше способом.
Нет, странно выглядит то что вы несколько примеров нужных фич языка оформили как полное ТЗ. Я вас поправил.
> Грубо говоря, если нужно сделать свой велосипед, почему бы не использовать хотя бы стандартные гайки
Если уж опускаться до аналогий, то зачем если нужен велосипед, выпиливать его из самолёта? А стандартных гаек там достаточно — в плане синтаксиса ничего нового не изобретено.
Нет, нужен DSL на котором удобно писать скрипты сборки. Собственно, такой и получился.
Это «отсутсвие или слабая выразительность» для системы сборки — как мана небесная, поскольку на cmake всё-таки собирают проекты, а не часы рисуют. Для этого выразительности не только хватает — её столько, что многие вещи сильно упрощаются, а писать хитровыгнутые конструкции желание пропадает. Я достаточно насмотрелся на SCons'овские скрипты от питонистов, которые во всю используют «привычные языковые средства» — разбираться в этом невозможно. Как результат, порог вхождения как раз намного ниже, чем если бы использовался язык общего назначения.
> Сильно сомневаюсь что можно найти, хоть какой то код на CMake, который будет выглядеть проще и лаконичнее чем аналог на любой распостранёной скриптоте общего назначения.
Как-бы DSL всегда быть проще и лаконичнее языков общего назначения. Несколько примеров я привёл выше.
> то встроить поддержку CMake в ваше любимое IDE
Да, давайте выбирать язык для системы сборки на основании лёгкости встраивания его в моё любимое IDE. Да и про лёгкость я бы поспорил — если и понадобится глубокий разбор cmake, то пожалуй проще будет разобрать его синтаксис, чем js, где нужное определение цели возможно придётся вытаскивать через несколько замыканий.
— Нормальное раскрытие переменных а-ля make (message(«Building ${FOO} with ${BAR}» вместо плясок с кавычками и плюсами)
— В том числе рекурсивное (${FOO_${BAR}}) которое иначе потребовало бы запаковку значений в словари и обратно
— Отсутствие необходимости писать кавычки почти везде
— Нормальный foreach по содержимому массива
— Форсирование повторения условия в endif/endfor/end* что сильно увеличивает читабельность
— Именованные аргументы на мой взгляд сделаны очень удобно
— Правильная передача значений в дочерние CMakeLists.txt и обратно (PARENT_SCOPE)
— Кэшированные переменные и все их атрибуты
— Макросы
Нет. Не надо мешать инструменты использующиеся в корпоративной среде и в разработке свободных проектов — это совершенно разные классы и требования, часто несовместимые. Эти миры пересекаются очень слабо, а если и пересекаются то скорее в другую сторону — «на работах» ставят то к чему привыкли работники.
> на работе программерам развернули движок, они к нему привыкли, он им нравится, дома они начинают искать хостинг на этом движке или разворачивать его самостоятельно, для себя, в результате в сети появляется открытый сервис на этом движке.
Причины по которым разворачивать движок не имеет смысла я уже озвучил, а очередной бесплатный глобальный хостинг должен чем-то привлечь пользователей, для которых GitHub уже стандарт.
> Сравните цену за GitLab с поддержкой с приведенным выше тарифом. Пятьдесят баксов в год! Всего пятьдесят баксов. Это мы с вами, скинувшись напополам, могли бы приобрести на двоих. Как вам разница в сто раз? Не аргумент, чтобы смотреть с оптимизмом?
Ещё раз, основной массе свободных проектов это и бесплатно не нужно. Конкуренция на корпоративном рынке и её последствия для GH как хостинга — это отдельная тема, которую я обсуждать не вижу смысла. И причин для оптимизма тут нет, поскольку если конкуренция на корпоративном рынке отрицательно скажется на состоянии GH, то пострадает сообщество.
Предпосылки и вытекающие из них рассуждения неверны. Потерять половину репозиториев ничем не лучше чем все. Свободные проекты это не песок который остаётся песком если отсыпать половину, а набор уникальных сущностей, проблема у значительной части которых — проблема всех. При этом чем больше хостингов, тем больше вероятность потери одного из них. Вы, грубо говоря, предлагаете RAID0 для увеличения надёжности. Кроме того, проекты с почившего хостинга в любом случае переезжают на самый популярный, т.е. в перспективе получаем, опять таки, один GitHub. Каждый отдельный репозиторий или пользователь не выигрывает ничего, но теряет аудиторию и удобство взаимодействия, сообщество теряет целостность, а эти факторы куда важнее, чем гипотетический переезд раз в десятилетие.
При этом всём, компрометация github как единственного хостинга будет означать неизбежность перехода на полноценную децентрализацию (одной из попыток такое сделать был gitchain) и такие проекты наконец начнут развиваться. Этот момент тоже не имеет смысла оттягивать.
> Откуда должны взяться альтернативы в идеальном случае? Я не спрашивал про текущую ситуацию.
Не вижу смысла отвечать на чисто гипотетический вопрос.
Я говорю о том что GitHub обладает наибольшей аудиторией и игнорировать это крайне глупо — на любом другом хостинге ваш проект будет отдалён, если не отрезан от этой аудитории, а в открытой разработке доступность — один из самых критичных факторов. При этом все риски гитхаба будут актуальны и на любом другом существующем хостинге.
> Я говорю, что он должен быть не единственным таким сайтом.
То есть всё-таки предлагаете. Тогда раскрывайте мысль: сколько должно быть сайтов, по каким критериям нужно определять на каком сайте хостить проект, хостить ли на одном или сразу на нескольких, и т.д. Если на одном, то чем не-github будет лучше github, а если на нескольких, собираетесь ли вы зеркалировать issues и wiki (при всех проблемах с этим, которые сами же перечислили) или нет (значит с возможностью потери данных плюс с необходимостью разбираться с дубликатами).
> Судя по вашему профилю на BitBucket, проекты, находящиеся там вы всё‐таки не игнорируете
То есть количество репозиториев и дата вам ничего не говорит? На вопрос вы не ответили.
> Кстати, вы так и не ответили на вопрос о том, откуда должны взяться альтернативы GitHub, если их никто не будет использовать по причине непрактичности.
Вопрос некорректен ибо содержит ложные предпосылки. Альтернативам не надо браться — они есть сейчас. Не нужные в данный момент по причине более низкой популярности, но, в принципе, готовые занять место гитхаба случись что с ним.
Тогда о чём вообще разговор?
> Просто не игнорируйте другие сайты.
В чём должно выражаться «не игнорирование»?
Даже если кто-то ещё не поддерживает markdown, разметка wiki — это в любом случае plaintext.
> Только если есть скрипты для эскпорта и импорта. Иначе вам придётся их писать, при этом обязательно вылезет то, что разные сайты поддерживают разные возможности.
При чём тут разные сайты? Одна миграция — один скрипт на всех.
> Корректный failover может быть невозможен по причине потери данных из‐за недоступности сайта. Чем бы вы не пользовались (даже если сайтов несколько) вам нужно периодически сохранять резервную копию issues и wiki, но если сайт используется один, то тут возникают проблемы, т.к. для непопулярных сайтов не написаны скрипты импорта.
Сохранять надо только issues, потому что wiki, повторюсь, обычный git репозиторий. При чём тут непопулярные сайты я не понял.
> Кстати, объясните‐ка мне, откуда появится «следующий по популярности сервис», если по вашему мнению точка взаимодействия одна?
Одна, потому что всё что хостится вне гитхаба выпадает из сообщества. Однако не все это понимают, поэтому другие хостинги ещё существуют.
> У вас — может быть. Другим нравится бо́льшая отказоустойчивость этой модели: тот же fossil (в одном репозитории сам код, wiki и issues) не просто так возник.
«Не просто так» им никто не пользуется.
Минусы github мне прекрасно известны, мне интересно что вы предлагаете в качестве альтернативы.
wiki это такой же git репозиторий. С issue пока сложнее, но экспортировать их не проблема.
> А точка взаимодействия F/OSS сообщества ни в коем случае не должна быть ровно одна, потому что это порождает единую точку отказа.
Нет тут точки отказа. Точка взаимодействия по своей природе подразумевайт failover на следующий по популярности сервис в случае проблем с текущим. И да, она должна быть одна, потому что любое другое количество кратно уменьшает эффективность взаимодействия и увеличивает накладные расходы.
> Если бы github был каким‐нибудь «распределённым» p2p сайтом, который никак не может закрыть один человек (здесь — владелец GH), то ещё можно было бы подумать. Защищённость сообщества от различных форс‐мажоров — это тоже чисто практическое соображение.
Распределённое VCS хранилище это, конечно, замечательно, но повода использовать его нет и не будет, пока работает github.