IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The bindings generator can't generate proper bindings for
virDomainSetThrottleGroup() (because of typed parameters in the
arguments) so implement it manually.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The bindings generator can't generate proper bindings for
virDomainGetAutostartOnce() (because of int* in the arguments) so
implement it manually.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
When -Ibuild flag is passed to compiler then build/ can be dropped
from includes. This is safe to do, because the prefix is only on
local includes (#include "") not system ones (#include <>).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The generator.py generates a (per module) table of functions it
generated code for and stores it in ${module}-export.c file. The
file is then #include-d in corresponding override.c in the table
of all methods implemented in the module.
Now, problem is with naming of the file because the ".c" suffix
might suggest the file needs to be compiled. Well, it doesn't.
It's way closer to being a header file, so change the suffix to
".c.inc".
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Soon generator.py is going to be ran from a build directory which
is different than the source directory. Allow specifying these
directories on the cmd line.
And while at it, introduce new "c+py" output mode in which both C
and Python files are generated. While this is a fallback mode if
no output mode is selected, we need this new mode so that
aforementioned directories can be specified.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
We use various C library functions like printf, strcmp, free
but don't have the corresponding #includes, getting them
indirectly via Python.h. This is a bad idea as Python.h is
not guaranteed to provided these, and indeed will omit them
when Py_LIMITED_API is greater then 0x030a0000.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The bindings generator can't generate proper bindings for FD passing so
the bindings need to be implemented manually both the python wrapper and
the C backend.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Currently we always generate both the C code and Python code at the same
time. To cope with following changes to the build process, we want to be
able to generate C and Python separately.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The python generator needs to know whether certain functions were
skipped in the C generator. This is achieved by the C generator
deleting skipped functions as it runs. This is an unhelpful side
effect as it makes it impossible to run the python generator
without first running the C generator.
This refactors buildStubs to get rid of the global side effects
it has, by providing some helper functions for buildWrappers
to use.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
As a side effect of generating the C code, the buildStubs methods
checks for various unsupported types and reports errors. This is
an undesirable side effect, if we want to skip C code generation.
Splitting function type validation out into a separate method
allows better reuse.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The buildStubs method has a side effect of loading and parsing the API
XML files, which the buildWrappers method then relies on.
Splitting API loading into a separate method will facilitate running
only the buildWrappers method in future.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Instead of having three separate methods for generating python
wrappers, merge them all together.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Now that we're using common data structures for all the main libvirt,
QEMU and LXC APIs, several of the functions have code duplication
that can be eliminated.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Now that we only use a single dict for tracking all enums, we
only need a single function for registering them.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
A single invokation of the generator only handles processing of one
libvirt API module, so there is no need to use separate dicts for
tracking enums.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Now that we only use a single dict for tracking all functions, we
only need a single function for registering them.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
A single invokation of the generator only handles processing of one
libvirt API module, so there is no need to use separate dicts for
tracking skipped functions.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
A single invokation of the generator only handles processing of one
libvirt API module, so there is no need to use separate dicts for
tracking functions.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
With libvirt-8.2.0 there's a new API:
virDomainQemuMonitorCommandWithFiles(). Since the API has both
input and output arguments we need to provide an alternative
implementation. Moreover, since FD passing works only on
UNIX-like systems we can query the returned FDs for their flags
and construct mode for python File object.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Provide a manual override for the virNodeDeviceGetAutostart() API
modeled on what's done for the network and storage APIs.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
The way that virNodeDevice method name fixup is written makes it
hard to find via grep (matching the virNodeDevice prefix and then
matching only the operation like "Get", "Lookup", ...). Expand
the string matching to match the pattern of other cases.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
In the 7.3.0 release we are going to have three new public APIs:
virNodeDeviceDefineXML()
virNodeDeviceUndefine()
virNodeDeviceCreate()
The first one is slightly problematic, because it takes
virConnectPtr argument and thus our generator wants to put its
wrapper under virConnect python class, which is correct, but
what's incorrect is the name it chooses for the method:
defineXML(). Such method already exists and wraps
virDomainDefineXML() around. Also, the name is rather confusing
anyway - it's missing the 'nodeDevice' prefix.
Fortunately, the fix is easy - add another case into nameFixup().
The story with virNodeDeviceCreate() is similar. Except, this time
the class in which the method was put is correct. But the name is
still wrong, because our generator matched 'virNodeDeviceCreate'
thinking it's the good old virNodeDeviceCreateXML() API and
"fixed" the name of the method to nodeDeviceCreate().
Luckily, virNodeDeviceUndefine() is just fine.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Both APIs work with string lists (the getter returns it, the
setter gets keys to set from it) -> represent that as a python
list. The rest is kept as is in C.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
to be closes to pep8 which makes reading the generated code easier and
reduces the number of issues found by flake8.
Signed-off-by: Philipp Hahn <hahn@univention.de>
for nested dictionaries allows to remove the case distinction for
"first" from "all other" cases.
Signed-off-by: Philipp Hahn <hahn@univention.de>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
tuple() and list() are sequences, while dict() and set() are hash-based,
which is more efficient for contains().
Signed-off-by: Philipp Hahn <hahn@univention.de>
Use attr.get(key, default) instead.
Also use the empty sting "" as the default value instead of "None": Both
are "False" when used as a bool()ean, but "None" would require an
explicit check for "not None" in many places as str() and None have
different types.
Signed-off-by: Philipp Hahn <hahn@univention.de>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
