CMake find_library: почему пути в PATHS ищутся после путей по умолчанию? - PullRequest
0 голосов
/ 10 октября 2018

Документация CMake кажется ясной: если не указано NO_DEFAULT_PATH, cmake сначала выполняет поиск в наборе путей по умолчанию, а если библиотека не найдена, только тогда просматривает каталоги, перечисленные в PATHS.Существует несколько других NO_*, чтобы исключить некоторые путей по умолчанию для cmake.

Я знаю, как преодолеть это поведение.Например, я могу сделать то, что предложено здесь , а именно выполнить два поиска: первый с NO_DEFAULT_PATH, а второй без него.Если первое удастся, второе будет пропущено.Win.

Однако этот вопрос не о , как добиться того, чего я хочу (я знаю, как взломать).Вопрос почему мне нужно это сделать?Почему cmake не смотрит первым в указанных путях?Мне кажется логичным сначала использовать их: если пользователь указывает какие-то подсказки, возможно, мне следует сначала использовать их и вернуться к значениям по умолчанию, если они не работают ...

Есть ли веская причинаМне не хватает текущей реализации?Я полагаю, что так, я сомневаюсь, что люди в cmake делают вещи без уважительной причины ...

Редактировать : когда я сказал «пользователь указывает некоторые подсказки», я не имел в видук фактическому HINTS аргументу find_library.Это было больше общих «подсказок».Однако, как предлагается в комментарии, HINTS действительно сканируется перед системными путями.Меня беспокоит документация cmake:

Поиск путей, указанных в опции HINTS.Это должны быть пути, рассчитанные системным самоанализом, например подсказка, указанная в местоположении другого уже найденного элемента.Жестко закодированные предположения должны быть указаны с опцией PATHS.

Тот факт, что HINTS не был разработан для получения жестко закодированных полных путей, заставляет меня думать, что это может произойти в будущем, поэтому яЯ не уверен, что это решение.Но, может быть, это так?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...