We probably do not need to dist-upgrade (or upgrade), and dist-upgrade
can take a long time on the github runners.
We only had this while trying to work out how to work around the
libgd-dev dependency issue, so we can remove the dist-upgrade step.
Work around libgd-dev dependency issue apparently caused by a 3rd party
repository with PHP and nginx and related stuff like libgd.
So we remove nginx and libgd3 to get rid of the relevant 3rd party
packages which pull in their libgd, and only then install libgd-dev
which then comes from Ubuntu proper and works.
As we need neither nginx nor php, this should work for libgphoto2.
This appears to be a reoccuring problem on github runners, so keeping
this workaround in place looks like the way to go for the future.
See also https://github.com/actions/runner-images/issues/6153
and recursively follow the linked issues and comments for more
information.
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.
Commit e47c13fd8e updates the
libgphoto2_port version from 0.12.0 to 0.12.1, but fails to
update libgphoto2_port/NEWS accordingly.
This updates libgphoto2_port/NEWS with the 0.12.1 version number,
thus fixing the "make distcheck" target's part checking NEWS.
Change the libgphoto2_port version from 0.12.0 to 0.12.1 so that
the libgphoto2 pkgconfig files can require libgphoto2_port >= 0.12.1
due to new symbols added.
This will not catch all possible build/install/link messups, but
will not hurt anyone and could catch some messups.
Introduce GP_CHECK_PROG macro to allow users to override
the autodetection of tools, instead of the autodetection
overriding the user's explicit wish.
GP_CHECK_PROG([SORT, [sort], [text line sorting tool])
will now allow calling
./configure SORT="mysort"
and have subsequent builds use that given value without
checking PATH. When calling `configure` without SORT=,
AC_PATH_PROG will look for `sort` in `PATH` and set
`SORT` to the value it has found.
For comparison, here is the old buggy method:
AC_ARG_VAR([SORT], [sort], [text line sorting tool])
AC_PATH_PROG([SORT], [sort], [no])
When called as `configure SORT="mysort"`, the expanded
AC_PATH_PROG will just look in `PATH` for `sort` and
set `SORT` to the `sort` it found, completely ignoring
the SORT= value given on the `configure` command line.
Only sleep after configure warning message if the output goes to
an interactive terminal (isatty()) and therefore sleeping actually
has a chance to be noticed by someone watching.
It makes more sense to use the provided m4_pattern_ignore()
macro than writing our own error messages.
Yes, our own error message could be more helpful to the
uninitiated user by mentioning the package and the m4 file
name to install which provide the required macro.
However, those file names and package names can and do change
with time or by operating system.
Remove additional AM_CONDITIONAL definitions for HAVE_LIBCURL
and HAVE_LIBXML2.
Those two AM_CONDITIONALS are already defined by GP_CHECK_LIBRARY.
If not having the addtional definitions exposes a bug, then that
bug should be fixed, not papered over with the additional definitions.
Complete what adding the gp_init_localedir() function implied:
* only set success flag in the success case
* consistent use of "initialize" spelling
* add analogous gp_port_init_localedir() function
* implement and document edge cases
* update NEWS
The function is called from gp_abilities_list_new() so existing code
will carry on working as before. Non-standard installations of
libgphoto2 can call the initialisation function with their choice of
locale dir. The function includes code to ensure it's only run once.
