libgphoto2+gphoto2 builds fail looking for gphoto2/gphoto2-foo.h include file #717
Comments
|
The "proper" way to fix this would be to change the instead of We should have done that in #452 already. Anybody disagreeing? |
|
hmm. kamera uses <gphoto2.h> , needs adaption then. our tooling (gphoto2, gtkam) uses gphoto2/gphoto2.h already. but i think the change is okay, some packages might need to adjust |
|
Or we change to |
|
Or we can have both, basically going back to the Anyway, I would really like to fix this in order to be able to build Let's consider the not uncommon case of the Linux distro providing a As it stands, we have which leads to
So our preferred source way of including libgphoto2 header files never actually does what is expected! If we change the the possibilities for a build are
If we change the the possibilities for a build are
I prefer build failures over silently building something unexpected. This leaves us the last two options, because both of them never produce a build using wrong headers:
So this boils down to how stable do we want our API to be. The |
In the *.pc files, use a C preprocessor include path both with
and without the gphoto2/ path component:
Cflags: -I${includedir} -I${includedir}/gphoto2
This allows both the preferred way to include gphoto2 headers
#include <gphoto2/gphoto2.h>
#include <gphoto2/gphoto2-camera.h>
and also the early 2000s legacy way (still in use by kamera and others)
#include <gphoto2.h>
#include <gphoto2-camera.h>
to produce builds with the libgphoto2 headers actually corresponding
to the *.pc files in use.
Any other option for the *.pc file Cflags either produces
unintended build failures or builds which use the wrong header
files (the `-I${includedir}/gphoto2` option), or breaks the
`#include <...>` part of the libgphoto2 API from the early 2000s
still in use by kamera and others (the `-I${includedir}` option).
For details, see gphoto#717 and
gphoto#717 (comment)
Fixes: gphoto#717
In the *.pc files, use a C preprocessor include path both with
and without the gphoto2/ path component:
Cflags: -I${includedir} -I${includedir}/gphoto2
This allows both the preferred way to include gphoto2 headers
#include <gphoto2/gphoto2.h>
#include <gphoto2/gphoto2-camera.h>
and also the early 2000s legacy way (still in use by kamera and others)
#include <gphoto2.h>
#include <gphoto2-camera.h>
to produce builds with the libgphoto2 headers actually corresponding
to the *.pc files in use.
Any other option for the *.pc file Cflags either produces
unintended build failures or builds which use the wrong header
files (the `-I${includedir}/gphoto2` option), or breaks the
`#include <...>` part of the libgphoto2 API from the early 2000s
still in use by kamera and others (the `-I${includedir}` option).
For details, see gphoto#717 and
gphoto#717 (comment)
Fixes: gphoto#717
In the *.pc files, use a C preprocessor include path both with
and without the gphoto2/ path component:
Cflags: -I${includedir} -I${includedir}/gphoto2
This allows both the preferred way to include gphoto2 headers
#include <gphoto2/gphoto2.h>
#include <gphoto2/gphoto2-camera.h>
and also the early 2000s legacy way (still in use by kamera and others)
#include <gphoto2.h>
#include <gphoto2-camera.h>
to produce builds with the libgphoto2 headers actually corresponding
to the *.pc files in use.
Any other option for the *.pc file Cflags either produces
unintended build failures or builds which use the wrong header
files (the `-I${includedir}/gphoto2` option), or breaks the
`#include <...>` part of the libgphoto2 API from the early 2000s
still in use by kamera and others (the `-I${includedir}` option).
For details, see gphoto#717 and
gphoto#717 (comment)
Fixes: gphoto#717
Describe the bug
When there are no
gphoto2/gphoto2-*.hinclude files in the C preprocessor's default include path, building gphoto2 fails when trying to#includeagphoto2/gphoto2-foo.hinclude file:The reason is that both
libgphoto2.pcandlibgphoto2_port.pcboth containbut the gphoto2 source code uses
which we have declared the standard way of including libgphoto2 headers.
We have removed the symlink which used to link
${includedir}/gphoto2/gphoto2to${includedir}/gphoto2in #452 after #444, and that symlink used to hack this to work.libgphoto2 and gphoto2 version
To Reproduce
On a system which does not have any gphoto2 headers installed in the C preprocessor path,
The text was updated successfully, but these errors were encountered: