Age | Commit message (Collapse) | Author |
|
As of 0.8.0, libQuotient has a build-time option for selecting either
Qt 5 or Qt 6, which required adding infrastructure to change the name
of the library target to prevent conflicts. Since I had to do this in
my patchset for 0.7.2, the patchset is now greatly simplified.
I still needed to make a few changes to other files to move the header
install location though. I have also made some changes to the
`pkg-config` description file to make it more responsive to the
selected build configuration. These changes should probably be
upstreamed as the file is otherwise incorrect for Qt 6 builds.
|
|
|
|
After CMake has finished installing the header files in the package
directory, a pass is run over all of them to replace all instances of
`# include <Quotient/` with `# include <QuotientE2EE/` to ensure that
the nested header includes work against the new install location. The
regular expression I used is sufficiently flexible to support a variety
of white-space scenarios and should be future-proofed for the inclusion
of new headers in the future.
|
|
Since adding encryption support changes the ABI, it is not feasible to
simply replace the official package's files and require users to
recompile all downstream software.
To work around that, I have modified the build system of this package
to install everything as `QuotientE2EE` instead of `Quotient`. So the
headers are installed to `/usr/include/QuotientE2EE` instead of
`/usr/include/Quotient`, the library itself is installed as
`libQuotientE2EE.so` instead of `libQuotient.so` and the `pkg-config`
and CMake configuration files have been renamed and adjusted
accordingly to allow compilation against this separate library.
As a side-effect of this, it should be possible to have `libquotient`
and `libquotient-encryption` installed at the same time - there are no
conflicting files between these packages now.
The preprocessor macros passed to the compiler are unchanged, as are
the CMake configuration options passed during the build process. At
least in theory, all that needs to change in downstream software is
to make the downstream build system use the `QuotientE2EE` library
instead of `Quotient` and to include headers from the `QuotientE2EE`
system directory instead of `Quotient` - all other variables should be
able to remain unchanged.
The header files are an interesting case, as they expect to be
installed in a directory named `Quotient`. This is something I don't
think I can change in the build system itself without moving the entire
source tree or separating the headers from the source, so I'll probably
have to leave the headers as-is during the build, and then change them
in the `package()` step. All that should need to change in the headers
is replacing instances of `#include <Quotient` with
`#include <QuotientE2EE` - everything else should continue to work.
|
|
Namely the `quotest` program and the Android NDK build files, as those
will conflict with the official `libquotient` package regardless of how
we change the name/location of the headers/library.
|
|
I've made a bunch of changes to the `PKGBUILD` script to make it more
closely meet the Arch Linux packaging guidelines.
- The package description is now less than 100 characters in length. It
should be below 80 according to the guidelines, but my understanding
is that since this is a modification of an official Arch package, it
should include the official package's description.
- The `license` has been changed from `LGPL2` to `LGPL2.1`. The former
is not listed in `/usr/share/licenses/common` which produces an error
in `namcap`. And the latter is more correct anyway.
- `gcc` and `make` have been removed from `makedepends` because we are
allowed to assume that all `base-devel` packages are already
installed. `git` has also been removed from `makedepends` because it
is not needed during the actual package build process (only to clone
the AUR Git repository).
- Inversely, I've added all transient dependencies (dependencies which
would otherwise automatically be pulled by `pacman` due to it being a
dependency further down the tree) to `depends` as per recent
guidelines and `namcap` output. This means that, in addition to the
top-level dependencies `libolm`, `qt5-multimedia` and
`qtkeychain-qt5` we also need to explicitly specify `gcc-libs`,
`glibc` and `openssl` (and `qt5-base` but that was already present).
I am honestly yet to see any other AUR package which explicitly lists
`glibc` as a dependency, and interestingly enough the official
`libquotient` package doesn't list it either, but as far as I can
tell from reading BBS/Wiki packages, I am indeed supposed to do this.
See https://bbs.archlinux.org/viewtopic.php?id=249846
- Added the soname (`libQuotient.so=0.7-64`) to `provides` to help
packages which look for sonames instead of Arch package names. The
soname is generated from the first two digits of `pkgver`.
- Switched from `sha512sums` to `sha256sums` so that I can just copy
the source checksum from the official Arch package when updating.
- Adjusted `source` to use `pkgver` so that bumping `pkgver` is enough
to cause the new source version to be downloaded instead of the old.
- Use `cmake -B <build dir> -S <source dir>` instead of manually
creating directories, as per the CMake packaging guidelines.
- Use `cmake --build` and `cmake --install` instead of manually calling
`make` as per the CMake packaging guidelines
- Remove `CMAKE_INSTALL_LIBDIR` because it is no longer needed (I don't
know if it was ever needed at all)
- Change `CMAKE_BUILD_TYPE` from `Release` to `None` as per the CMake
packaging guidelines. This causes CMake to use the system-provided
build settings (i.e. those specified in `/etc/makepkg.conf`)
verbatim, without adding additional optimisations or debugging
information.
- Note that the CMake changes listed above have already been applied to
the official `libquotient` package.
- Use `pkgver` when accessing the source directory directly, again so
that only `pkgver` has to be updated to make the new version work.
|
|
|
|
|
|
|
|
|
|
|