PKG_CHECK_MODULES considerato dannoso?

Question

Vari sviluppatori scoraggiano l'utilizzo di PKG_CHECK_MODULES (ad esempio, in this answer) ma non c'è una spiegazione chiara e completa delle loro ragioni per quanto ho cercato. Quindi, chiedo:

• Perché PKG_CHECK_MODULES essere dannoso?
• Quali sono le alternative?

Io, per esempio, l'ho usato per la prima volta oggi. Ho trovato invaluably utile, specialmente per trattare con i set di biblioteca piuttosto complicati, come GTK +, dove sono tutte queste dipendenze:

-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 

Answer 1

Per anni, ho usato PKG_CHECK_MODULES e l'ho trovato per essere molto utile. Avevo visto persone lamentarsi del fatto che l'uso di PKG_CHECK_MODULES causava "errori di compilazione sottili" su varie piattaforme, ma non ho mai trovato una ragione particolarmente convincente per smettere di usarlo. Tuttavia, ritengo che sia l'obbligo del maintainer di rispondere ai reclami degli utenti, ove appropriato, quindi è sempre stato un problema problematico. Tuttavia, il mio reclamo principale con PKG_CHECK_MODULES è che causa i guasti dove non dovrebbe. Se un utente installa libfoo in /p/a/t/h e invoca uno script configure con LDFLAGS=-L/p/a/t/h, l'utente è giustificato aspettandosi che la configurazione trovi libfoo. Tuttavia, l'utente deve impostare anche PKG_CONFIG_PATH in modo che lo script configure possa trovare foo.pc in modo che la configurazione abbia esito positivo e che l'IMO sia danneggiato. Sarebbe possibile invocare AC_CHECK_LIB e quindi invocare solo PKG_CHECK_MODULES se la libreria non viene trovata tramite il meccanismo standard per evitare tale problema. Un altro problema è che è completamente possibile per PKG_CHECK_MODULES trovare un file .pc in cui le informazioni siano imprecise, causando il fallimento della compilazione. In tal caso, è necessario invocare AC_CHECK_LIB dopo il PKG_CHECK_MODULES.

In breve, utilizzare PKG_CHECK_MODULES correttamente, è necessario invocare AC_CHECK_LIBS prima, poi condizionatamente invocano PKG_CHECK_MODULES, e quindi richiamare AC_CHECK_LIBS nuovamente per convalidare le informazioni trovate da PKG_CHECK_MODULES. Tutto questo lavoro aggiuntivo da parte del manutentore solo per rendere più facile agli utenti l'installazione delle loro librerie in posizioni non standard è, IMO, assurdo. L'utente deve impostare la propria catena di strumenti per trovare le librerie attraverso i meccanismi standard.

- EDIT -

Per chiarire, non sto suggerendo che un pacchetto che utilizza una libreria che incoraggia l'uso di PKG_CHECK_MODULES dovrebbe evitare di utilizzare nel loro configury. Piuttosto, raccomando che le biblioteche non ne incoraggino l'uso e smettano di distribuire i file .pc. Il problema che si sta tentando di risolvere con i file .pc è meglio indirizzato a un livello superiore. Gli autotools sono non un sistema di gestione dei pacchetti e questo è un problema che dovrebbe essere risolto da uno strumento di gestione dei pacchetti.

Answer 2

C'è un post sul blog qui che entra in un po 'di dettagli sul lato cattivo di PKG_CHECK_MODULES:

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

o questa domanda StackOverflow:

Using the pkg-config macro PKG_CHECK_MODULES failing

Si riduce essenzialmente down to: causa errori molto inutili se qualcuno sta tentando di eseguire autoconf e non ha installato pkg-config. Ecco un esempio di un errore ho ricevuto oggi in esecuzione 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)' 

Per un utente/sviluppatore solo cercando di compilare un pacchetto, questo non urla "è necessario installare pkg-config".

Se (come suggerisce l'articolo) basta chiamare pkg-config direttamente, si ottiene di più utile errori, ad es .:

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 

Altre persone non suggeriscono di usare pkg-config a tutti; questo è un problema separato.