Если вы хотите развернуть свое приложение на компьютерах клиентов, а не использовать ваше приложение только самостоятельно, мы обнаружим, что метод LIBS+= -Lxxx -lyyy
может привести к путанице, если не к проблемам.
Мы разрабатываем приложения для Linux, Mac и Windows, используя Qt. Мы отправляем полные, автономные приложения. Таким образом, все несистемные библиотеки должны быть включены в пакет развертывания. Мы хотим, чтобы наши клиенты могли запускать приложение с одного USB-накопителя для всех ОС. Из соображений совместимости платформы USB-накопитель должен быть отформатирован как FAT32, который не поддерживает символические ссылки (Linux).
Мы нашли идиому LIBS+= -Lxxx -lyyy
слишком большой для черного ящика:
Мы точно не знаем, что такое filepath библиотеки (статической или динамической), найденной компоновщиком. Это неудобно. Наш компоновщик Mac регулярно находил библиотеки, отличные от тех, которые, как мы думали, следует использовать. Это происходило несколько раз с библиотеками OpenSSL, где компоновщик Mac обнаруживал и использовал свою собственную - более старую, несовместимую - версию OpenSSL, а не нашу запрашиваемую версию.
Мы не можем позволить, чтобы компоновщик использовал символические ссылки на библиотеки, поскольку это нарушило бы пакет развертывания.
Мы хотим видеть из имени библиотеки, связываем ли мы статическую или динамическую библиотеку.
Так что для нашего конкретного случая мы используем только абсолютные пути к файлам и проверяем, существуют ли они. Мы удаляем все символические ссылки.
Сначала мы выясним, какую операционную систему мы используем, и поместим это в переменную CONFIG. И, например, для Linux 64bit, тогда:
linux64 {
LIBSSL= $$OPENSSLPATH/linux64/lib/libssl.a
!exists($$LIBSSL): error ("Not existing $$LIBSSL")
LIBS+= $$LIBSSL
LIBCRYPTO= $$OPENSSLPATH/linux64/lib/libcrypto.a
!exists($$LIBCRYPTO): error ("Not existing $$LIBCRYPTO")
LIBS+= $$LIBCRYPTO
}
Все зависимости могут быть скопированы в пакет развертывания, поскольку мы знаем их пути к файлам.