Using libavrdude as a standalone library

[yegorich]

So far libavrdude will be built internally as a static library. For the common usage it has to provide the following features:

• static or dynamic build (there is a related CMake option)
• install target for both the library and header file
• the header file must not include local headers like ac_cfg.h

[dl8dtl]

the header file must not include local headers like ac_cfg.h

See PR #820 - you're welcome to review it.

[dl8dtl]

Btw., with PR #826 merged, I notice it's now either a shared or a static library.
This is probably OK, but with autoconf/automake, both used to be built.

[yegorich]

Yes, this is normal CMake procedure. But there are tricks to make both like what libftdi1 makes.

Generally, it is not a problem. When you package avrdude, you would run the build twice with different options and use these artefacts. This is what Debian rules do for many CMake-based packages

[dl8dtl]

I just opened issue #827 - libavrdude.so is built but not installed.

[mcuee]

As of now, macOS and WIndows shared library build will fail.

Related discussion (including macOS patch)

• Unable to build libavrdude dynamic and static library with CMake buildsystem #952
• Now CMake will build both static and shared libs #960 (macOS shared library build is working with this pull request).

Windows share library will fail now and need more work to get it working.

• Windows shared library build problem under both VS2019 and MSYS2 #954

[mcuee]

Related issue:

• Unable to build libavrdude dynamic library under Windows and macOS #1414

As of now, it is not possible to build libavrdude.dll dynamic library under Windows.