Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge libgphoto2_port buildsystem into the libgphoto2 buildsystem #731

Draft
wants to merge 37 commits into
base: master
Choose a base branch
from

Conversation

ndim
Copy link
Member

@ndim ndim commented Oct 12, 2021

This will merge the libgphoto2_port/configure.ac and assorted files into the top-level configure.ac. The basic idea is to get both configure.ac and libgphoto2_port/configure.ac cleaned up first, both to refamiliarize myself with them and to make the later merge simpler. Only then will I do the actual merge.

At this time, this is still work in progress. There will be force pushes for some time.

Changes and Features:

  • configure --help will now print the help for the libgphoto2_part in addition to the libgphoto2 part of the build.
  • Running configure should be faster.
  • Require newer autoconf version. Old requirement was 2.62 (from 2008-04-06). New requirement is 2.69 (from 2012-04-25, like libexif).
  • Require newer automake version. Old requirement was 1.9 (from 2004-07-28). New requirement is 1.14 (from 2013-06-20, as opposed to libexif requiring 1.14.1).
  • Require newer gettext version. Old requirement was 0.14.1 (from 2004-01-30), new requirement will be 0.18.3 (from 2013-07-07, like libexif) or 0.19.1 (from 2014-06-10, allows make dist without updating all the *.po files). Exact version TBD.
  • Will require newer libtool (TBD).
  • Removed some hacks required to work with tools from early 2000s Debian oldoldstable.

Remarks:

  • As of 2021-10-15, Debian oldoldstable ships the following tool versions: autoconf 2.69, automake 1.15, gettext 0.19.8.1, and libtool 2.4.6. Being quite old by definition, Debian oldoldstable should not be a bad place to take a hint about tool versions from.
  • Also regarding build tool versions, you only need those tools to build a dist tarball from a git working tree. That release tarball (or any of the official release tarballs) should then build on even older systems.

@ndim ndim force-pushed the merge-buildsystems branch 2 times, most recently from 91df327 to 459e7d9 Compare October 13, 2021 23:37
@ndim ndim linked an issue Oct 15, 2021 that may be closed by this pull request
@ndim ndim force-pushed the merge-buildsystems branch from 226eaea to cf50ed6 Compare October 31, 2021 09:18
@ndim
Copy link
Member Author

ndim commented Oct 31, 2021

As of cf50ed6, this needs probably another 20 to 30 commits until the actual merge, and then another 10 to clean up the merge fallout. Still working on this in the background, occasionally committing smaller independent issues I have run into directly to the master branch.

ndim added 23 commits October 31, 2021 11:30
Make the compiler warnings work with clang in addition to gcc.
This came up then the pedantic build tests failed on FreeBSD 13.

To achieve this, we add -Werror=unknown-warning-option to
the CFLAGS for clang to abort immediately on encountering
an unknown warning option. This means we now only add warnings
which the compiler (both clang and gcc) actually supports.

As configure tests that compiling is possible for each
warning flag, this should not introduce compatibility
issues where builds which used to work now do not.

However, you can always opt to not use the generated CFLAGS
by setting CFLAGS to empty when running your build like

    make all check CFLAGS=
These did not work with C++ on FreeBSD 13 anyway, due to
c++98 not working there, which the old pedantic compilation
just assumed was working without testing it in configure.

The new pedantic compilation tests offer a multitude of
language standards including c++98, but only tries building
the pedantic compilation tests for those language standards
for which configure has shown that building programs is
possible at all.
Always define the test programs, but only conditionally test them.

This makes certain they can be build, the sources are added
to the dist tarball, etc.
Add a pedantic compile test for c++20 in addtion to the existing
ones for c++98, c++11, c++14, and c++17.
Use m4_pattern_forbid to find unnoticed GP_ strings
in the configure and config.status scripts.
We still do not use LTDL_INIT() as LTDL_INIT insists on
us shipping libltdl sources in our release tarballs and
we still do not like shipping 3rd party sources.

This now checks locations other than the default include
and linker paths, so that configure should find libltdl
by itself now on e.g. FreeBSD.
Update the checks for jpeg-turbo libjpeg to try libjpeg.pc
with PKG_CHECK_MODULES first, and also to allow explicitly
set LIBJPEG_CFLAGS and LIBJPEG_LIBS.

The old mechanism did not allow specifying the location
of libjpeg at all. It only allowed either disabling
libjpeg or using libjpeg from the default include and
linker paths. So this also changes the places in the
Makefiles where we used to add @LIBJPEG@ to the linker to
both link with $(LIBJPEG_LIBS) and compile with
$(LIBJPEG_CFLAGS).

The new configure logic keeps --without-jpeg to force-
disable libjpeg, but updates the detection of libjpeg
to first try the LIBJPEG_* variables if given, otherwise
try PKG_CHECK_MODULES for libjpeg, and only then falls
back to the old way of just trying the default include
and link locations for libjpeg.

Also, this mentions more information in the configure
summary if not building with libjpeg, and it makes sure
to call libjpeg "jpeg-turbo libjpeg" to help people with
finding the proper system package to install.

This is the first time we make it possible to build with
jpeg-turbo libjpeg on e.g. FreeBSD.
This makes changes easier to read in diffs.
This makes it easier to see and merge changes.
Occasionally, not quoting macro arguments leads to
weird problems.

So we try to consistently quote the arguments to
avoid these kinds of problems.
This puts AM_PO_SUBDIRS before AM_GNU_GETTEXT to fix the

error: `po-directories' is already registered with AC_CONFIG_COMMANDS.

and puts the -DLOCALEDIR together with the gettext
setup.
# Conflicts:
#	libgphoto2_port/configure.ac
Make the two gphoto-m4 directories identical in preparation for
using just one of them.
Only use a single gphoto-m4/ subdir - namely that in
libgphoto2_port/gphoto-m4/. This prevents us from
needing to synchronize the *.m4 files.

We can do that by switching from recursive make for the
gphoto-m4 subdirectories to using

    include path/to/gphoto-m4/Makefile-files

from both the top-level Makefile.am and libgphoto2_port/Makefile.am
using %reldir% (introduced in automake 1.14).
This helps with editing the *.m4 files in the proper editor
mode.
The "localedir" variable has been introduced by autoconf-2.59c.

We are requiring at least autoconf-2.62, so we do not need to
define and AC_SUBST "localedir" any more.
Fix the GP_SLEEP invocation in the Gentoo hack which adds the ptp2
camlib if the only camlib requested is canon, as modern Canon cameras
use the ptp2 camlib, not the canon camlib.
This adds a list of tool releases with their respective release
dates and why they are important for libgphoto2 (libexif
requirements, notable bug fixes and features).
ndim added 14 commits October 31, 2021 13:27
This gives us a few more features and bug fixes and fewer workarounds.

autoconf 2.69 is the same autoconf version requirement as libexif
uses.

autoconf 2.69 has been released 2012-04-25. If you ever need to build a
post 2021 libgphoto2 from git on a system with pre 2.69 autoconf, you
can always prepare a tarball using "make dist" on a system with autoconf
2.69 or later, and build that tarball on the older machine.
This gives us a few more features, and a few less conditionals
conditionally reimplementing features added to automake
before automake 1.14.

automake 1.14 is almost the same automake version requirement
as libexif uses (libexif requires 1.14.1).

automake 1.14 has been released 2013-06-20. If you ever
need to build a post 2021 libgphoto2 from git on a
system with pre 1.14 automake, you can can always
prepare a tarball using "make dist" on a system with
automake 1.14 or later, and build that tarball on the
older machine.
Spacing improves readability.
Put one header file per line in the the argument to
AC_CHECK_HEADERS().

This improves readability, makes diffs easier to read,
allows for easier sorting, etc.
Put one function name per line in the the argument to
AC_CHECK_FUNCS().

This improves readability, makes diffs easier to read,
allows for easier sorting, etc.
This gives us a few more features and fixes to rely
on which are present in libtool 2.4.2 (released
2011-10-18), which is older than our autoconf,
automake, and gettext requirements.

Update the libtool initialization to use the more
modern (modern in the sense of libtool 1.9b from
2004-08-29) LT_INIT macro.

We still do not use LTDL_INIT() as that insists on
us shipping libltdl sources in our release tarballs.
@ndim ndim force-pushed the merge-buildsystems branch from cf50ed6 to 4a8e1ea Compare October 31, 2021 12:32
@ndim
Copy link
Member Author

ndim commented Nov 18, 2021

Actually unifying the two configure.ac scripts into one will NOT happen in time for 2.5.28, but many of the preparations will.

@ndim
Copy link
Member Author

ndim commented Nov 4, 2022

As PR #855 shows, unifying the two configure.ac scripts is also useful to eliminate the need to duplicate code and the chance to build in inconsistent environments.

@ndim
Copy link
Member Author

ndim commented Jan 30, 2024

FTR, I am resuming work on this.

@axxel
Copy link
Contributor

axxel commented Sep 17, 2024

Random thought from an outsider: maybe better replace the whole thing with e.g. CMake? That is at least my thought every time I look at my console while tons of 'noise' gets spit out by make and I have to scroll just to find some warnings... ;).

Disclaimer: I have no idea how much work that would be, I'm just a happy CMake user in other projects.

@hfiguiere
Copy link
Member

maybe better replace the whole thing with e.g. CMake?

HELL NO

@axxel
Copy link
Contributor

axxel commented Sep 17, 2024

HELL NO

Ah, someone who likes their autotools ;). Maybe you can help me solve my problem regarding the usability. Is there an autoconf/configure/make option to do away will all the noise and have a make run with a single compiler warning actually let me see that in my terminal window without scrolling 10 to 30 pages up?

@msmeissn
Copy link
Contributor

make --quiet

already helps.

@axxel
Copy link
Contributor

axxel commented Sep 17, 2024

Thanks for the hint, although it made no significant difference IMHO. But now I found configure --enable-silent-rules and that basically does what I wanted to achieve with my cmake suggestion.

@hfiguiere
Copy link
Member

this should be enabled by default.

@ndim
Copy link
Member Author

ndim commented Sep 18, 2024

Enable silent rules by default PR: #1021

Update: PR #1021 has been merged.

@axxel axxel mentioned this pull request Dec 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants