Until gi-docgen is declared stable support either of them.
This effectively means that hand builds and CI builds will use
gi-docgen, but distro builds use gtk-doc-tools.
We use MM_REQUIRED_VERSION to compare the running ModemManager version
with the one we require. But we don't need QMI_REQUIRED_VERSION for
anything, just remove it.
These symbols were similar to GLIB_REQUIRED_VERSION, but neither
ModemManager nor libqmi implement them in the same way as GLib does.
For the purpose of skipping deprecated APIs, ModemManager and libqmi
use the older MM_DISABLE_DEPRECATED and QMI_DISABLE_DEPRECATED macros.
The build dependency of libqmi was attempted to be updated in
commit 6db69de725, but wasn't properly done, as
only the QMI_REQUIRED_VERSION symbol was updated, not the actual
pkgconfig required version.
Reverts small part of 99832622e1.
EFI_APP_LOCATION conf var (or FWUPD_EFIAPPDIR env var) is needed for
fu_common_get_path (FU_KIND_PATH_EFIAPPDIR)
to function properly
Open file description locks are Linux-specific. If fwupd is not built
for Linux, it should use the traditional UNIX record locks (F_SETLK).
Signed-off-by: Norbert Kamiński <norbert.kaminski@3mdeb.com>
The dependencies to generate the "updating..." splash screen are non-trivial, and
pointless in headless systems. Add an option to disable the generation entirely.
Don't look for cairo, fontconfig, and freetype libraries as this will
look for *target* libraries. The presence of these libraries is used as
a proxy for the gobject-introspection libraries being available for
the make-images.py script, but as this runs at build time we don't care
about target libraries at all.
Luckily there's another script, test-deps.py, which looks for the g-i
libraries so these dependencies can be removed.
This makes a lot more sense; we can parse a firmware and export the same XML
we would use in a .builder.xml file. This allows us to two two things:
* Check we can round trip from XML -> binary -> XML
* Using a .builder.xml file we can check ->write() is endian safe
Keeping *internal* API and ABI compatibility makes working with an already
complex codebase more mentally demanding than it needs to be.
Remember: plugins should be in-tree and upstream! If your out of tree plugin
stops working then it should be upstream.
The public-facing libfwupd will remain API and ABI stable for obvious reasons.
The generate_binary.sh is a script that calls the objcopy tool and
genpeimg in the case of Windows, to generate a PE binary file.
But doesn't have to be a shell script and could be rewritten as a
python script. This will make this code to generate a PE binary
easier to extend if needed.
Also, the only reason that's a template is to define the objcopy
tool used, but this can also be passed as a positional argument.
When this is done, include:
* Including the hash
* Including anything that is not ABI stable in plugins yet
Suggested-by: Simon McVittie <smcv@debian.org>
For fuzzing we want to exclude libcurl support as it depends on other very heavy
libraries like OpenSSL or libtasn which make the fuzzing binary much larger if
linked statically.
