gphoto / libgphoto2

The libgphoto2 camera access and control library.
GNU Lesser General Public License v2.1
1.05k stars 325 forks source link

Inconsistent --cflags between gphoto2-config and pkg-config #664

Open danfe opened 3 years ago

danfe commented 3 years ago

It had been brought to my attention that currently (as of version 2.5.27) inconsistent compilation flags are reported when obtained via standard pkg-config(8) or shipped gphoto2-config script:

$ pkg-config --cflags libgphoto2
-I/usr/local/include/gphoto2 -I/usr/local/include
$ gphoto2-config --cflags
-I/usr/local/include/gphoto2

Tobias suggested to simply add ${PREFIFX}/include path to the script, so both commands would report two paths, but I actually don't see why -I/usr/local/include/gphoto2 needs to be reported at all, as gphoto2's own library usage and other consumers include headers as gphoto2/gphoto2*.h, ergo just the -I${PREFIX}/include should be sufficient.

msmeissn commented 3 years ago

i took a short look and did not see anything that might cause it, also nothing between 2.5.26 and 2.5.27 looks relevant. perhaps libgphoto.pc pulls in another with -I/usr/local/include (e.g. libexif?)

danfe commented 3 years ago

i took a short look and did not see anything that might cause it

Just to clarify this a bit: you believe that only -I/usr/local/include/gphoto2 should be returned?

also nothing between 2.5.26 and 2.5.27 looks relevant.

Oh, I didn't mean to imply that this had changed in between these versions, 2.5.26 behaves idendically and most likely earlier versions would do as well.

msmeissn commented 3 years ago

Well, our code only returns -I/usr/local/include/gphoto2, so the other -I comes from another library ... Likely a pkg-config styledependency, where there is probably only libexif.

gphoto2-config does not follow library dependencies when reporting cflags.

ok, so this persists already for a while.... not sure what to do. these days pkgconfig is the standard though, we might be able to slowly get rid of gphoto2-config

danfe commented 3 years ago

Well, our code only returns -I/usr/local/include/gphoto2

Okay, but if your code, and other consumers' code I've seen, would typically #include <gphoto2/gphoto2-foo-bar.h>, wouldn't it make more sense to return -I/usr/local/include instead?

these days pkgconfig is the standard though, we might be able to slowly get rid of gphoto2-config

Makes sense, I very much agree.

msmeissn commented 3 years ago

i am indifferent here. for system includes the /usr/include would also already cover that.

danfe commented 3 years ago

for system includes the /usr/include would also already cover that.

That's true for GNU/Linux, but some of the better operating systems install third-party software under different prefix, e.g. /usr/local for FreeBSD or /usr/pkg for NetBSD.

hfiguiere commented 3 years ago

Maybe gphoto2-config should be dropped or just wrap a call to pkg-config + a deprecation warning.