| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
https://github.com/gphoto/libgphoto2/issues/770
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Add automake based example project using libgphoto2 to have
the CI builds ensure that building a libgphoto2 frontend
with this libgphoto2 is possible.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 because we did not properly communicate and enforce that
back when we were still stabilizing the API)
#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 https://github.com/gphoto/libgphoto2/issues/717 and
https://github.com/gphoto/libgphoto2/issues/717#issuecomment-1018040615
Fixes: https://github.com/gphoto/libgphoto2/issues/717
|
| |
|
|
|
| |
Use #pragma to allow GNU style range designators in the
camlibs/pentax/js0n.c state machine table initializers.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This catches clang in a clang specific C preprocessor conditional
before clang gets a chance to mess up at pretending to be gcc.
The camlibs/pentax/js0n.c state machine tables use a lot of both
GNU style range designators [ a ... b ], and later overrides some
of the values in the range. This is not very pure C, but relatively
effient to code, so we can accept silencing some warnings here.
Fixes: https://github.com/gphoto/libgphoto2/issues/761
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
https://github.com/gphoto/gphoto2/issues/480
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
https://github.com/gphoto/gphoto2/issues/477
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow the --with-jpeg=yes configure argument again. This
was broken by commit ea00220b6f44a00c2efa792c538f1804ebe183c2.
The GP_LIBJPEG macro in the configure script now handles the following cases:
--with-jpeg=no
--without-jpeg
Do not use libjpeg. Do not autodetect it either.
--with-jpeg
--with-jpeg=yes
Autodetect libjpeg. If not found, abort.
<no argument given>
--with-jpeg=auto
--with-jpeg=autodetect
Autodetect libjpeg. If found, use it.
However, it does *NOT* handle
--with-jpeg=/path/to/somewhere
at this time. Set LIBJPEG_CFLAGS and/or LIBJPEG_LIBS
instead to specify which libjpeg to compile with and
link against.
This mostly matches the behaviour from before commit
ea00220b6f44a00c2efa792c538f1804ebe183c2, which was
--with-jpeg=no
--without-jpeg
Do not use libjpeg. Do not autodetect it either.
--with-jpeg
--with-jpeg=yes
--with-jpeg=<any value other than "no">
Autodetect libjpeg. If found, use it. Otherwise, silently
ignore the user's wish to build with libjpeg.
<no argument given>
Autodetect libjpeg. If found, use it.
If someone is running configure with --with-jpeg=yes and
libjpeg cannot be used, we can assume that building without
using libjpeg is not the outcome the user expects.
Fixes: https://github.com/gphoto/libgphoto2/issues/759
Closes: https://github.com/gphoto/libgphoto2/pull/760
|
| |
|
|
|
|
|
| |
Have git ignore the gp-gettext-setup.mk files which
commit d18b440a72407fc371ec17a2a983976b813e5d97
added to the list of files being generated during
builds.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The vscode documentation[1] says that the editor use a directory
named ".vscode", not "+.vscode".
".vscode" is also what the original commit[2] in pull request 100[3]
contained.
However, commit e9fafcd89d3e88767670800f684c58eee727b84f
probably contained a cut and paste error and added the
ignore pattern for directories called "+.vscode".
[1]: https://code.visualstudio.com/docs/editor/workspaces
[2]: https://github.com/gphoto/libgphoto2/pull/100/commits/d8ff05da8cf5c4790c6e8f0dd4dda34b382ec585
[3]: https://github.com/gphoto/libgphoto2/pull/100
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
https://github.com/gphoto/gphoto2/issues/465
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
https://github.com/gphoto/libgphoto2/issues/753
|
| |
|
|
|
| |
Make the gettext domain consistency checks more verbose to help
debugging https://github.com/gphoto/libgphoto2/issues/751.
|
| | |
|
| |
|
|
|
|
|
| |
Add pull-translations target to make it easier to pull translations
from the Translation Project:
make pull-translations
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This requires gettext version 0.18.3 or later, and it removes
the GP_GETTEXT_HACK which used to generate a po/Makevars file
from the po/Makevers.template.
gettext 0.18.3 is the same gettext version requirement
as libexif uses.
gettext 0.18.3 has been released 2013-07-07, which is
a similar timeframe of the autoconf, automake and libtool
releases we require.
If you ever need to build a post 2021 libgphoto2 from
git on a system with pre 0.18.3 gettext, you can can
always prepare a tarball using "make dist" on a system
with gettext 0.18.3 or later, and build that tarball
on the older machine.
Not generating the po/Makevars file any more means that
we need additional consistency checks for the parts of
po/Makevars which cannot be derived from the Autoconf
standard set of AC_SUBST()ed Makefile.in variables.
|
| | |
|
