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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxx>
> >> ---
> >>  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 :|




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux