autotools - songs - tag de netflix

¿PKG_CHECK_MODULES es considerado dañino? (2)

Varios desarrolladores desalientan el uso de PKG_CHECK_MODULES (por ejemplo, en esta respuesta ) pero no hay una explicación clara y completa de sus razones en lo que he buscado. Entonces pregunto:

¿Por qué PKG_CHECK_MODULES sería perjudicial?
¿Cuáles son las alternativas?

Yo, por ejemplo, lo usé por primera vez hoy. Lo encontré invaluable, especialmente para tratar con conjuntos de bibliotecas bastante intrincados, como GTK +, donde tengo todas estas dependencias:

-I/usr/lib/i386-linux-gnu/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0

Aquí hay una publicación de blog que incluye algunos detalles del lado negativo de PKG_CHECK_MODULES:

http://tirania.org/blog/archive/2012/Oct-20.html

o esta pregunta de :

El uso de la macro pkg-config PKG_CHECK_MODULES falla

Básicamente se reduce a: causa errores muy inútiles si alguien está intentando ejecutar autoconf y no tiene instalado pkg-config. Aquí hay un ejemplo de un error que recibí hoy al ejecutar autoconf && ./configure :

./configure: line 5283: syntax error near unexpected token `FFMPEG,'' ./configure: line 5283: ` PKG_CHECK_MODULES(FFMPEG, libavutil libavformat libavcodec libswscale, HAVE_FFMPEG=yes)''

Para un usuario / desarrollador que está tratando de compilar un paquete, esto no grita "es necesario instalar pkg-config".

Si (como sugiere el artículo) simplemente llama a pkg-config directamente, obtendrá errores más útiles, por ejemplo:

AC_SUBST(MONO_LIBS) AC_SUBST(MONO_CFLAGS) if pkg-config --atleast-version=2.10 mono; then MONO_CFLAGS=`pkg-config --cflags mono` MONO_LIBS=`pkg-config --libs mono` else AC_MSG_ERROR(Get your mono from www.go-mono.com) fi

Edit: en un comentario Helmut Grohne dice:

Por favor no llames a pkg-config directamente. Al hacerlo se rompe la compilación cruzada. Use AC_PATH_TOOL (PKG_CONFIG, pkg-config) o mejor PKG_PROG_PKG_CONFIG para descubrir qué $ PKG_CONFIG usar.

Supongo que esto es correcto y usted debería seguir su sugerencia, pero no lo he probado personalmente.

Otras personas sugieren no usar pkg-config en absoluto; eso es un tema aparte

Un problema importante con PKG_CHECK_MODULES es que causa fallas donde no debería. Si un usuario instala libfoo en /p/a/t/h e invoca un script de configure con LDFLAGS=-L/p/a/t/h , se justifica que el usuario busque la configuración para encontrar libfoo . Pero, el usuario también debe configurar PKG_CONFIG_PATH para que la secuencia de comandos configure pueda encontrar foo.pc para que la configure foo.pc éxito, y en mi opinión eso no funciona. Sería posible invocar AC_CHECK_LIB y luego solo invocar PKG_CHECK_MODULES si la biblioteca no se encuentra a través del mecanismo estándar para evitar ese problema. Otro problema es que es completamente posible que PKG_CHECK_MODULES encuentre un archivo .pc en el que la información sea inexacta, lo que hace que la compilación falle. En ese caso, es necesario invocar AC_CHECK_LIB después de PKG_CHECK_MODULES .

En resumen, para usar PKG_CHECK_MODULES correctamente, es necesario invocar AC_CHECK_LIBS primero, luego invocar de forma condicional PKG_CHECK_MODULES , y luego invocar AC_CHECK_LIBS nuevamente para validar la información encontrada por PKG_CHECK_MODULES . Todo este trabajo adicional por parte del mantenedor solo para facilitar que los usuarios instalen sus bibliotecas en una ubicación no estándar es absurdo. El usuario debe configurar su cadena de herramientas para encontrar bibliotecas a través de los mecanismos estándar.

- EDITAR -

Para aclarar, no estoy sugiriendo que un paquete que utiliza una biblioteca que fomenta el uso de PKG_CHECK_MODULES debería evitar usarlo en su configuración. Más bien, estoy recomendando que las bibliotecas no fomenten su uso y dejen de distribuir archivos .pc . El problema que se intenta resolver con archivos .pc se aborda mejor en un nivel superior. Las herramientas automáticas no son un sistema de administración de paquetes, y este es un problema que debe ser resuelto por una herramienta de administración de paquetes.