On Mon, 4 Jan 2021 at 12:22, Daniel P. BerrangĂ© <[email protected]> wrote:
> > Question to Paolo -- it seems pretty fragile to have to explicitly
> > list "these source files need these extra CFLAGS" in half a dozen
> > meson.build files, because it's pretty non-obvious that adding
> > eg '#include "block/nbd.h"' to a .c file means that you also
> > need to update the meson.build file to say "and now it needs these
> > extra CFLAGS". Isn't there some way we can just have the CFLAGS
> > added more globally so that if we use gnutls.h directly or
> > indirectly from more .c files in future it Just Works ?
>
> The actual usage of gnutls should be confined to the crypto/ code.
>
> The rest of QEMU should only ever be using QEMU's TLS abstractions
> and not directly be tied to GNUTLS. So ideally the gnutls flags
> should only ever be added in the crypto/meson.build, and anything
> which depends on that should then get the flags indirectly.

Unfortunately include/crypto/tlscreds.h leaks this implementation
detail, because it defines:

struct QCryptoTLSCreds {
    Object parent_obj;
    char *dir;
    QCryptoTLSCredsEndpoint endpoint;
#ifdef CONFIG_GNUTLS
    gnutls_dh_params_t dh_params;
#endif
    bool verifyPeer;
    char *priority;
};

So every file that uses the tlscreds.h header must be
compiled with the GNUTLS flags, even if it doesn't itself
care about the underlying implementation.

(Maybe there's a way to keep the internals of the QCryptoTLSCreds
struct private to the crypto/ source files ?)

thanks
-- PMM

Reply via email to