[RFC 01/21] build-aux: Add a tool to generate xml parse/format functions

[Daniel P. Berrangé]

On Wed, Jul 01, 2020 at 12:06:36AM +0800, Shi Lei wrote:
> >On Wed, Jun 10, 2020 at 09:20:29AM +0800, Shi Lei wrote:
> >> This tool is used to generate parsexml/formatbuf functions for structs.
> >> It is based on libclang and its python-binding.
> >> Some directives (such as genparse, xmlattr, etc.) need to be added on
> >> the declarations of structs to direct the tool.
> >>
> >> Signed-off-by: Shi Lei <shi_lei at massclouds.com>
> >> ---
> >>  build-aux/generator/directive.py | 839 +++++++++++++++++++++++++++++++
> >>  build-aux/generator/go           |  14 +
> >>  build-aux/generator/main.py      | 416 +++++++++++++++
> >>  build-aux/generator/utils.py     | 100 ++++

> >
> >> +if __name__ == "__main__":
> >
> >> +
> >> +    libclang_path = os.environ.get('libclang_path')
> >> +    assert libclang_path, 'No libclang library.'
> >> +    Config.set_library_file(libclang_path)
> >
> >I'm wondering if we really need this at all ? AFAICT, the libclang
> >python library works fine without it, so this is only required if
> >trying to use a non-standard libclang, which I think ought to be
> >possible already by setting LD_LIBRARY_PATH
> > 
> 
> I'm working on Ubuntu. On Ubuntu 20.04 LTS and 18.04, I find:
> 
> # ldconfig -p | grep libclang
>         libclang-10.so.1 (libc6,x86-64) => /lib/x86_64-linux-gnu/libclang-10.so.1
>         libclang-10.so (libc6,x86-64) => /lib/x86_64-linux-gnu/libclang-10.so
> 
> There's no libclang.so!
> 
> If I install python3 bindings from the standard apt repository, it works!
> By default, this version just find 'libclang-10.so'.
> 
> But if I use 'pip3' to install python3 bindings, it doesn't work.
> Because it is another verison. This version find 'libclang.so' and it can't find it!
> 
> So I think we can retain these lines to adapt to the distinction among platforms.

Generally libvirt only cares about working against the distro provided
versions of packages.  So if the apt installed python binding works
that is sufficient.

If we want to support an alternative libclang though, I'd suggest that
instead of trying to figure it out magically, just have an optional
arg to configure, eg  --with-libclang=/lib/x86_64-linux-gnu/libclang-10.so

By default don't set any libclang in the python binding - just let it
use its built-in default.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|