| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
mingw/llvm . fixes https://github.com/gphoto/libgphoto2/issues/890
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consistently use the same notation and formatting for all
camlib Makefile-files, which uses
* common $(camlib_cflags)
* common $(camlib_cppflags)
* common $(camlib_dependencies)
* common $(camlib_ldflags)
* common $(camlib_libadd)
and then groups additional related definitions together,
making it obvious when e.g. bar_la_LIBADD adds FOO_LIBS
but bar_la_CPPFLAGS forgot to add FOO_CFLAGS.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Factor out the i18n definitions into i18n.h include files:
One include file each for libgphoto2 and for libgphoto2_port.
This removes the complete
#ifdef ENABLE_NLS
# include <libintl.h>
# undef _
# define _(String) dgettext (GETTEXT_PACKAGE, String)
# ifdef gettext_noop
# define N_(String) gettext_noop (String)
# else
# define N_(String) (String)
# endif
#else
# define _(String) (String)
# define N_(String) (String)
#endif
block (which in some occasions defines even more macros)
and replaces it with a single line
#include "libgphoto2/i18n.h"
for camlibs and libgphoto2 itself and with
#include "libgphoto2_port/i18n.h"
for iolibs and libgphoto2_port itself.
This gives us two central locations to change the defintions.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are five libgphoto2 internal *.h include files inside the
source tree's `libgphoto2/` folder. Internal means they are part
of the libgphoto2 implementation, and are not part of the public
libgphoto2 API or ABI. These files have names which are so
generic that it is difficult to see from a `#include` statement
that the included file is actually part of libgphoto2:
bayer-types.h
bayer.h
exif.h
gamma.h
jpeg.h
While building, an additional file is created inside the `libgphoto2/`
folder with a name which does hint to its relationship with libgphoto2:
gphoto2-endian.h
To reduce the probability of accidental conflicts with include files
which might also be called the same very generic name, this changes
the use of these include files to a preprocessor directive like
#include "libgphoto2/bayer.h>
instead of
#include "bayer.h"
To enforce the need for the "libgphoto2/" part in the #include
preprocessor directive, this also removes the respective `-I`
arguments for the `libgphoto2` subdir (both in source tree and in
build tree) from `*_CPPFLAGS`.
This change was inspired by `libgphoto2/` and `camlibs/stv0680/`
containing very different include files both called `bayer.h`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
C preprocessor macros beginning/ending with underscores are
reserved for system use as well as macros containing a double
underscore anywhere, so application software macros are
supposed to be named differently.
For a header file gphoto2-abilities-list.h, this
consistently uses a macro name
LIBGPHOTO2_GPHOTO2_ABILITIES_LIST_H
for the usual
#ifndef LIBGPHOTO2_GPHOTO2_ABILITIES_LIST_H
#define LIBGPHOTO2_GPHOTO2_ABILITIES_LIST_H
... content of the header file ...
#endif /* !defined(LIBGPHOTO2_GPHOTO2_ABILITIES_LIST_H) */
Found using "clang -Weverything".
This should work, unless when run with an ancient C preprocessor
which might only the first 8 or 10 characters to distinguish
macro names and ignores the remainder of the name.
|
|
|
| |
stdint.h has wide adoption at this point, so it should be safe to use.
|
| |
|
|
|
|
|
| |
gcc warnings.
Fixed strcat incorrect 3rd argument
|
| |
|
| |
|
|
|
|
|
|
| |
building better with Visual C
https://github.com/gphoto/libgphoto2/issues/33
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The usleep() function is defined to be provided by unistd.h.
On Linux this is pulled in indirectly so the missing includes
don't cause build problems, but on Mingw32 the explicit include
of unistd.h is required. Since sleep() is not available on
Mingw32, #define it to usleep(). Remove some _POSIX_C_SOURCE
macros which restricted code to 1993 POSIX standard which
blocks use of usleep().
git-svn-id: https://svn.code.sf.net/p/gphoto/code/trunk/libgphoto2@14997 67ed7778-7388-44ab-90cf-0a291f65f57c
|
|
|
|
| |
git-svn-id: https://svn.code.sf.net/p/gphoto/code/trunk/libgphoto2@14790 67ed7778-7388-44ab-90cf-0a291f65f57c
|
|
|
|
| |
git-svn-id: https://svn.code.sf.net/p/gphoto/code/trunk/libgphoto2@14789 67ed7778-7388-44ab-90cf-0a291f65f57c
|
|
|
|
| |
git-svn-id: https://svn.code.sf.net/p/gphoto/code/trunk/libgphoto2@14608 67ed7778-7388-44ab-90cf-0a291f65f57c
|
|
|
|
| |
git-svn-id: https://svn.code.sf.net/p/gphoto/code/trunk/libgphoto2@14469 67ed7778-7388-44ab-90cf-0a291f65f57c
|
|
|
|
| |
git-svn-id: https://svn.code.sf.net/p/gphoto/code/trunk/libgphoto2@14466 67ed7778-7388-44ab-90cf-0a291f65f57c
|
|
|
|
| |
git-svn-id: https://svn.code.sf.net/p/gphoto/code/trunk/libgphoto2@14248 67ed7778-7388-44ab-90cf-0a291f65f57c
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The picture numbering in the PAT can contain holes from pictures having
been deleted using the frames builtin menu.
These holes are a problem as if we keep deleting all but the
highest numbered picture and adding new pictures the picture
number could reach 254 / 255 which have special meaning.
This patch moves the renumbering of pictures from our own delete functon to
the commit function, so that we also fix any holes in the picture numbers
caused by the frames internal delete.
git-svn-id: https://svn.code.sf.net/p/gphoto/code/trunk/libgphoto2@13673 67ed7778-7388-44ab-90cf-0a291f65f57c
|
|
|
|
|
|
|
|
| |
When a pciture is deleted from the menu within the frame the PAT entry contains
0x00 instead of 0xFE (and the the other pictures don't get renumbered).
git-svn-id: https://svn.code.sf.net/p/gphoto/code/trunk/libgphoto2@13671 67ed7778-7388-44ab-90cf-0a291f65f57c
|
|
git-svn-id: https://svn.code.sf.net/p/gphoto/code/trunk/libgphoto2@13654 67ed7778-7388-44ab-90cf-0a291f65f57c
|