Это делается одной командой include_directories.
Ваш тоже не работает, у вас при изменении заголовочных файлов не пересоберутся объектники зависящие от них, и одной строкой вы это никак не исправите.
Достаточно того что в CMake вы описываете суть проекта на высоком уровне — «взять все исходные файлы» и «собрать из них бинарник», а не цепочку трансформаций списка файлов, суть которой нельзя понять не вчитываясь и которую придётся переписывать целиком если структура изменится (скажем, добавится ещё один уровень каталогов) — две гибкие и понятные строки всяко изящнее десятка строк лапши.
А так, среди всего прочего, с CMake вы получаете из коробки контроль за зависимостями по include'ам (без этого вообще нельзя), поддержку переопределения компилятора/флагов/префикса/destdir и т.д. что необходимо для переносимой сборки, генерацию solution'ов для IDE и много чего ещё, это даже не затрагивая того что может потенциально понадобиться позже при развитии проекта и что на make двумя строчками сделать может и не получиться (поиск зависимостей, установка, интегрированное тестирование, кросс-компиляция), причём переносимо и без необходимости помнить об особенностях каждой целевой системы.
Надо бы знать что CMake занимается ничем иным как генерацией Makefile'ов, поэтому надобность в make не пропала особенно при использовании CMake. Кроме того, для простых проектов (несколько исходных файлов, без внешних зависимостей — как в примере из статьи) CMake, пожалуй, будет overkill'ом и make останется лучшим выбором.
Очень дельное замечание, но я бы добавил ещё два улучшения:
Удаление bin из PREFIX, что возвращает ему стандартный смысл (не путь к директории с исполняемыми файлами, а префикс дерева директорий с определённой структурой, содержащего в том числе и поддиректорию bin)
Использование ?= для определения PREFIX, что позволит менять его через окружение
Это нужно чтобы проект мог правильно и не требуя лишних телодвижений (как-то изменение Makefile или явное указание аргументов make) собраться и установиться у человека с настроенными в окружении компилятором, флагами и путями для установки (например, CC=clang CFLAGS=-g -Wall PREFIX=$HOME/custom_apps). То же самое нужно для сборки проекта через source-based пакетные системы, например порты FreeBSD (а скорее всего верно и для portage/aur/slackbuilds/brew/...).
Это не костыли, а UNIX-way: совершенно не нужно усложнять программу поддержкой многопоточности, когда можно просто запустить параллельно несколько её копий. Как правило, последнее ещё и эффективнее.
Спасибо за наводку на статью — я помнил что что-то такое пролетало, но найти не осилил.
Насчёт ремапа — как я сказал, при невозможности прочитать с диска X ZFS читает с других дисков и сразу пишет на X, так что ремапить таки должно. Но без ERC неизвестно что там происходило — возможно при висящем в очереди диска запросе на чтение последующий запрос на запись тоже ставился в очередь, а учитывая что первый мог висеть неизвестно сколько мог и не выполниться. На самом деле меня бы устроил ремап сразу при чтении, когда хосту выдаётся содержимое резервного сектора, будь там хоть мусор хоть нули — ZFS это проглотит ибо хранит чексуммы на все блоки, зато последующие чтения гарантировано не будут давать задержку (и опять таки, содержимое ZFS восстановит). Но такой специфический режим вряд-ли предусмотрен.
Ничего не написано про виды сбоев. У меня есть не слишком серьёзный, но все же показательный опыт эксплуатации шестидискового массива под ZFS на нескольких поколениях дисков (500GB Seagate (ST3500630AS), 1TB Hitachi (HDT721010SLA360), 2TB Seagate (ST32000542AS), 3TB Seagate (ST3000VX000-1CU166)). Нагрузка не считая пассивно лежащих данных — немного раздач торрентами, много сборки ПО, иногда большие базы данных с аналитикой и похожие штуки. Итак, я видел два вида сбоев:
1) Диск умирает целиком и полностью
2) Диск покрывается бэдами и каждое обращение к такому сектору вызывает задержку (время на попытки прочитать сектор * количество retry, заданное в системе)
Так вот первый случай — великое счастье (разумеется, только когда у вас массив с избыточностью), потому что диск спокойно вытаскивается, меняется по гарантии и засовывается обратно, при этом процессы работающие с данными на массиве этого даже не замечают. А второй — действительно проблема. В моих случаях то-ли сектора не remap'пились (где-то я слышал что на дешёвых десктопных дисках remap'пятся только сектора которые не получилось записать), то-ли их было достаточно много — в общем, машина еле ворочалась поскольку все процессы на ней в итоге ждут чтения с этого посыпавшегося диска (а каждая попытка чтения битого сектора, судя по логам — около 4 секунд).
При этом не совсем понятно что делать с диском дальше — насколько я знаю, диски с количеством бэдов до определённого числа по гарантии не меняют, а сектор, грубо говоря, может быть всего один, но в каком-нибудь часто используемом месте. На самом деле их много и надо бы найти их все, но для этого нужно либо запустить scrub на массиве (не вариант, потому что массив и без него практически неработоспособен), либо вытаскивать диск (оставить в машине тоже нельзя, ибо он занимает место под запасной, а оставлять массив в DEGRADED не хочется), искать отдельную машину куда его воткнуть, там упорно сканировать поверхность либо в надежде добить количество бэдов до гарантийного случая либо попытаться их всё-таки заремаппить и надеяться что новых не появится.
Так вот, из описанного выше набора дисков, 1 Seagate (кажется 2TB) продемонстрировал «первый случай» через неделю после покупки и был поменян безо всяких трудностей, после чего массив служил верой и правдой порядка 25000 часов (по Power_On_Hours), а из Hitachi сразу 3 диска показали «случай 2» почти сразу (тогда массив использовался без активной нагрузки, поэтому я прожил с ними аж около 700 часов, после чего вернулся на Seagate). Вот если диски «работают» так — пусть они не умирают хоть веками, на деле ими можно пользоваться только как подставкой под кофе.
Выводы которые я сделал для себя:
— Применительно к статистике типа представленной в статье, критически важен характер сбоев и учёт описанного «случая 2».
— Не факт что работающий диск на деле работоспособен. Без активной нагрузки (а статистика как раз от компании, занимающейся бэкапами) проблемы можно и не заметить.
— Не факт что часто умирающие диски хуже долгоживущих
— Если источник статистики — одна партия дисков, статистика скорее всего недостоверна (это я предполагаю что мне всё-таки не повезло с партией Hitachi), но к данной статье это не относится
— Ну и разумеется, о чём я никогда не устану говорить — никакие НЖМД использовать без избыточности категорически нельзя.
PS. Для полноты данных, недавно «случаем 2» посыпался и диск из пачки 2TB Seagate (два диска оттуда сейчас используются в зеркале в десктопе), зря я думал что это «фишка» исключительно Hitachi. Но после 3.5 с лишним лет непрерывной работы ему простительно. А вот последняя шестёрка 3TB барракуд работает уже 7220 часов без единого сбоя, последний scrub (это процедура ZFS при которой перечитываются все данные и проверяется их целостность) — 2 октября 2013. Что касается 500-ток, то могу сказать что на hitachi я с них переехал только из-за нехватки места — наработки у них 12500 часов, почти у всех есть единицы Reallocated_Sector_Ct/Reported_Uncorrect/Current_Pending_Sector/Offline_Uncorrectable но на работе это никак не сказывалось.
Говорят что риголит весьма абразивен и хорошо ко всему липнет, плюс легко поднимается в воздух от малейшего воздействия. Это кажется довольно серьёзной проблемой для солнечной энергетики.
WinAMP последний раз видел лет 10 назад, потом пересел с Windows на FreeBSD и хотя аналоги (XMMS) были, стало понятно насколько этот интерфейс неудобен. Поэтому пересел сначала на mpd, потом на moc, коим пользуюсь и по сей день.
В чём выражается проприетарность? Википедия говорит «patent free», документация есть в msdn — по всему выходит что формат открытый. А сжатие — это уже зависит от потребностей в каждом конкретном случае. В конкретно данном случае куда важнее простота, выражающаяся в отсутствии зависимости от SDL2_image.
Думаю, куда-то влететь прямо камерой чтобы её повредить достаточно сложно. Карточка в любом случае должна уцелеть.
Я ездил с GoPro, правда мне он нужен не как регистратор, а для картографирования. В качестве регистратора он не очень подходит т.к. живёт всего 2.5 часа от одной зарядки и быстро забивает карточку. Ещё кажется что представленное статье устройство гораздо лучше снимает ночью (у GoPro1 вообще ничего не видно, GoPro3 ночью ещё не пробовал). Но для меня GoPro оно бы не заменило, ибо видео — те-же 2.5 часа, в худшем качестве и неудобном формате.
Там, по сути, всего лишь пара десятков строковых операций на выделение статусной части, при использовании словаря поиск по std::map на каждую категорию классификации (точное совпадение, если не найдено каноническая форма, если не найдено ...). Только нечёткий поиск требует перебора словаря, но по крайней мере из данных OSM по России до него доходит меньше 2% названий. В реальности у меня куда большую часть времени съедает парсинг OSM XML (так как я ещё не сделал поддержку OSM PBF), а на чистых текстовых данных на моём i7 в один поток обрабатывает 200000 названий/сек (проверял на самом же словаре, т.е. тут до нечёткого поиска дело не доходит никогда, всегда срабатывает точное совпадение).
Для Nominatim подход со словарём точно не подойдёт, а причёсывание статусной части — настолько тривиальная операция что проще реализовать её там с нуля, возможно в виде более подходящем для всех языков мира. У меня, впрочем, сложилось впечатление что главная проблема nominatim — неумение правильно интерпретировать запрос, и на данный момент поиск на openstreetmap.ru (внутри использует движок полнотекстового поиска sphinx) выглядит намного более работоспособным (там, насколько я знаю, данные никак не обрабатываются, но запрос разбирается достаточно умно).
Я плохо знаком с реализуемым вами процессом для пользователей (точнее не знаком) поэтому не могу оценить — например, возможно ли в вашем случае уточнение с помощью названия города или нет…
Нет — пришлось бы делать разные словари для разных городов, причём словари по большей части бы пересекались. Есть возможность вынести общую часть в отдельный файл и подключать его в частных, но это лишние хлопоты.
И выражение «ошибки неприемлемы» я честно говоря не до конца понимаю. Есть технологический параметр — цена ошибки… Вы наверное не имеете в виду что в вашем случае он бесконечный? Или я наверное не до конца понимаю какую задачу вы решаете.
Привожу написание названий улиц в базе OSM к одному виду, исправляя попутно ошибки. В OpenStreetMap очень ценят работу участников проекта, поэтому испортить добавленное кем-нибудь название — немыслимо, поэтому да — цена весьма высока.
Правда был ещё такой критерий — сложность добавления новых топонимов в список (фактически на это требуется программист). Я думаю в вашем случае этой проблемы нет, если я верно понял…
Нет, там просто текстовый словарь с названием улицы на строчку. Да, я лично тоже думаю что написать 7 раз «N-й Нижний переулок» проще чем набирать скобки для диапазона. Словарь также удобнее грепать и обрабатывать другими способами.
Ваш тоже не работает, у вас при изменении заголовочных файлов не пересоберутся объектники зависящие от них, и одной строкой вы это никак не исправите.
Но для
CMake на самом деле нафиг не сдался.
А так, среди всего прочего, с CMake вы получаете из коробки контроль за зависимостями по include'ам (без этого вообще нельзя), поддержку переопределения компилятора/флагов/префикса/destdir и т.д. что необходимо для переносимой сборки, генерацию solution'ов для IDE и много чего ещё, это даже не затрагивая того что может потенциально понадобиться позже при развитии проекта и что на make двумя строчками сделать может и не получиться (поиск зависимостей, установка, интегрированное тестирование, кросс-компиляция), причём переносимо и без необходимости помнить об особенностях каждой целевой системы.
Итого:
Это нужно чтобы проект мог правильно и не требуя лишних телодвижений (как-то изменение Makefile или явное указание аргументов make) собраться и установиться у человека с настроенными в окружении компилятором, флагами и путями для установки (например, CC=clang CFLAGS=-g -Wall PREFIX=$HOME/custom_apps). То же самое нужно для сборки проекта через source-based пакетные системы, например порты FreeBSD (а скорее всего верно и для portage/aur/slackbuilds/brew/...).
Насчёт ремапа — как я сказал, при невозможности прочитать с диска X ZFS читает с других дисков и сразу пишет на X, так что ремапить таки должно. Но без ERC неизвестно что там происходило — возможно при висящем в очереди диска запросе на чтение последующий запрос на запись тоже ставился в очередь, а учитывая что первый мог висеть неизвестно сколько мог и не выполниться. На самом деле меня бы устроил ремап сразу при чтении, когда хосту выдаётся содержимое резервного сектора, будь там хоть мусор хоть нули — ZFS это проглотит ибо хранит чексуммы на все блоки, зато последующие чтения гарантировано не будут давать задержку (и опять таки, содержимое ZFS восстановит). Но такой специфический режим вряд-ли предусмотрен.
1) Диск умирает целиком и полностью
2) Диск покрывается бэдами и каждое обращение к такому сектору вызывает задержку (время на попытки прочитать сектор * количество retry, заданное в системе)
Так вот первый случай — великое счастье (разумеется, только когда у вас массив с избыточностью), потому что диск спокойно вытаскивается, меняется по гарантии и засовывается обратно, при этом процессы работающие с данными на массиве этого даже не замечают. А второй — действительно проблема. В моих случаях то-ли сектора не remap'пились (где-то я слышал что на дешёвых десктопных дисках remap'пятся только сектора которые не получилось записать), то-ли их было достаточно много — в общем, машина еле ворочалась поскольку все процессы на ней в итоге ждут чтения с этого посыпавшегося диска (а каждая попытка чтения битого сектора, судя по логам — около 4 секунд).
При этом не совсем понятно что делать с диском дальше — насколько я знаю, диски с количеством бэдов до определённого числа по гарантии не меняют, а сектор, грубо говоря, может быть всего один, но в каком-нибудь часто используемом месте. На самом деле их много и надо бы найти их все, но для этого нужно либо запустить scrub на массиве (не вариант, потому что массив и без него практически неработоспособен), либо вытаскивать диск (оставить в машине тоже нельзя, ибо он занимает место под запасной, а оставлять массив в DEGRADED не хочется), искать отдельную машину куда его воткнуть, там упорно сканировать поверхность либо в надежде добить количество бэдов до гарантийного случая либо попытаться их всё-таки заремаппить и надеяться что новых не появится.
Так вот, из описанного выше набора дисков, 1 Seagate (кажется 2TB) продемонстрировал «первый случай» через неделю после покупки и был поменян безо всяких трудностей, после чего массив служил верой и правдой порядка 25000 часов (по Power_On_Hours), а из Hitachi сразу 3 диска показали «случай 2» почти сразу (тогда массив использовался без активной нагрузки, поэтому я прожил с ними аж около 700 часов, после чего вернулся на Seagate). Вот если диски «работают» так — пусть они не умирают хоть веками, на деле ими можно пользоваться только как подставкой под кофе.
Выводы которые я сделал для себя:
— Применительно к статистике типа представленной в статье, критически важен характер сбоев и учёт описанного «случая 2».
— Не факт что работающий диск на деле работоспособен. Без активной нагрузки (а статистика как раз от компании, занимающейся бэкапами) проблемы можно и не заметить.
— Не факт что часто умирающие диски хуже долгоживущих
— Если источник статистики — одна партия дисков, статистика скорее всего недостоверна (это я предполагаю что мне всё-таки не повезло с партией Hitachi), но к данной статье это не относится
— Ну и разумеется, о чём я никогда не устану говорить — никакие НЖМД использовать без избыточности категорически нельзя.
PS. Для полноты данных, недавно «случаем 2» посыпался и диск из пачки 2TB Seagate (два диска оттуда сейчас используются в зеркале в десктопе), зря я думал что это «фишка» исключительно Hitachi. Но после 3.5 с лишним лет непрерывной работы ему простительно. А вот последняя шестёрка 3TB барракуд работает уже 7220 часов без единого сбоя, последний scrub (это процедура ZFS при которой перечитываются все данные и проверяется их целостность) — 2 октября 2013. Что касается 500-ток, то могу сказать что на hitachi я с них переехал только из-за нехватки места — наработки у них 12500 часов, почти у всех есть единицы Reallocated_Sector_Ct/Reported_Uncorrect/Current_Pending_Sector/Offline_Uncorrectable но на работе это никак не сказывалось.
в воздухот малейшего воздействия. Это кажется довольно серьёзной проблемой для солнечной энергетики.github.com/AMDmi3/libSDL2pp
Я ездил с GoPro, правда мне он нужен не как регистратор, а для картографирования. В качестве регистратора он не очень подходит т.к. живёт всего 2.5 часа от одной зарядки и быстро забивает карточку. Ещё кажется что представленное статье устройство гораздо лучше снимает ночью (у GoPro1 вообще ничего не видно, GoPro3 ночью ещё не пробовал). Но для меня GoPro оно бы не заменило, ибо видео — те-же 2.5 часа, в худшем качестве и неудобном формате.
Для Nominatim подход со словарём точно не подойдёт, а причёсывание статусной части — настолько тривиальная операция что проще реализовать её там с нуля, возможно в виде более подходящем для всех языков мира. У меня, впрочем, сложилось впечатление что главная проблема nominatim — неумение правильно интерпретировать запрос, и на данный момент поиск на openstreetmap.ru (внутри использует движок полнотекстового поиска sphinx) выглядит намного более работоспособным (там, насколько я знаю, данные никак не обрабатываются, но запрос разбирается достаточно умно).
Нет — пришлось бы делать разные словари для разных городов, причём словари по большей части бы пересекались. Есть возможность вынести общую часть в отдельный файл и подключать его в частных, но это лишние хлопоты.
Привожу написание названий улиц в базе OSM к одному виду, исправляя попутно ошибки. В OpenStreetMap очень ценят работу участников проекта, поэтому испортить добавленное кем-нибудь название — немыслимо, поэтому да — цена весьма высока.
Нет, там просто текстовый словарь с названием улицы на строчку. Да, я лично тоже думаю что написать 7 раз «N-й Нижний переулок» проще чем набирать скобки для диапазона. Словарь также удобнее грепать и обрабатывать другими способами.