pragma comment (lib, ...): Линковка разных библиотечных файлов в зависимости от конфигурации

Предположим, что вы разрабатываете какую-то очень полезную библиотеку. Или не очень полезную. Или уже разработали, давно выложили на github, и развиваете её дальше. Насколько удобно и легко будет включить вашу библиотеку в проект "постороннему" человеку? Назовём его, для определённости, Посторонним В.

Типичный набор действий В. по включению библиотеки в проект:

1. Прописывает в свойствах проекта путь к заголовочным файлам.
2. Прописывает в свойствах линковщика путь к библиотекам.
3. Указывает названия необходимых библиотек.

Всё? Чаще всего, нет. Посторонним В. меняет конфигурацию проекта с Debug на Release (или наоборот), и вписывает всё то же самое. Почти, да не совсем - очень часто путь к Debug и Release версии файлов библиотеки отличается, поскольку по умолчанию названия библиотечных файлов для Debug и Release одинаковые. На случай, если наш В. использует дополнительные конфигурации - кроме стандартных Debug и Release, данное действие повторяется для всех конфигураций.

Если предоставляемая библиотека содержит целый набор LIB файлов, требуется как-то выбрать нужные (что не всегда очевидно для Посторонним). Или просто указать все библиотеки (в каждой конфигурации проекта) - мало ли, какая из них содержит требуемую функцию.

А теперь прекращаем издеваться над В. и остальными, и делаем всё по-человечески.

Библиотека POCO и error C2039: ... : is not a member of "global namespace"

Есть проект в MSVC++. Есть файл, использующий ряд популярных WIN API вызовов - CreateProcess, CreateFile, и им подобные. Всё собирается, всё замечательно.
В какой-то момент решаем использовать функционал из прекрасной библиотеки POCO. Включаем заголовочный файл для требуемого модуля - например, "Poco/Logger.h", и наш проект перестаёт собираться, жалуясь на то, что его любимые WIN API вызовы вдруг пропали.

В процессе раскопок выяснилось, что в POCO есть файл, unwindows.h, который включается его собственными заголовками. Данный файл просто и со вкусом, через #undef, убирает ряд annoying macros (по его скромному мнению)  - да-да, те самые CreateFile, и прочие. К чести сказать, удаляет не всегда, а только в том случае, если не выставлен #define с именем POCO_NO_UNWINDOWS - другими словами, как мне кажется, в 99% случаев. Вы ведь сразу выставили данный #define для каждого проекта, в котором используете WIN API вызовы, как только стали использовать POCO? Вот и я почему-то "поленился".

Причина, возможно, в том, что весь функционал, предоставленный данными API вызовами, существует в POCO, и таким способом разработчику "ненавязчиво намекают" на переход на средства библиотеки. Кроме как "тонким издевательством" такой "пиар" назвать не могу.