Release tarballs ship the include/libvirt/libvirt-common.h.
when srcdir != builddir we end up including libvirt-common.h twice: from
$top_srcdir/include/libvirt-common.h and from
$builddir/include/libvirt-common.h leading to
function virTypedParamsGetUInt from /tmp/buildd/libvirt-2.4.0/debian/build/docs/../include/libvirt/libvirt-common.h redeclared in /tmp/buildd/libvirt-2.4.0/docs/../include/libvirt/libvirt-common.h
function virTypedParamsAddBoolean from /tmp/buildd/libvirt-2.4.0/debian/build/docs/../include/libvirt/libvirt-common.h redeclared in /tmp/buildd/libvirt-2.4.0/docs/../include/libvirt/libvirt-common.h
…
Only add the builddir to the search list if there is no pregenerated
libvirt-common.h.
Reuse the existing check that predates the libvirt.h → libvirt-common.h
split and that probably was meant for exactly that.
References: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842452
When generating the hvsupport.html.in file, we parse the -api.xml
files generated by apibuild.py to know in which HTML file the API
function is.
Doing an XPath query for every single 'function' element in the
file is inefficient.
Since the XML file is generated by another of our build scripts
(apibuild.py, using Python's standard 'output.write' XML library),
just find the function name->file mapping by a regex upfront.
Also add a note about this next to the line that generates it
in apibuild.py and do not check if XML::XPath is installed in
bootstrap since we no longer use it.
In 38df47c9af I've tried to prepare our apibuild.py script for
change made in 0628f3498c (1U << 31). What I've done in the
former commit was to replace \d+U in parsed tokens with \d.
Problem was, my regular expression there was not quite right as
it also translated VIR_123U_VAL into VIR_123_VAL.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The apibuild script is a terrifying beast that parses some source
files of ours and produces an XML representation of them. When it
comes to parsing enums we have in some header files, it tries to
be clever and detect a value that an enum member has (or if it is
an alias for a different member). Whilst doing that it has to
deal with values we give to the members in many formats. At some
places we just pass the value in decimal:
VIR_DOMAIN_BLOCK_JOB_TYPE_PULL = 1,
in other places, we use the aliasing:
VIR_CONNECT_GET_ALL_DOMAINS_STATS_ACTIVE = VIR_CONNECT_LIST_DOMAINS_ACTIVE,
and in other places bitwise shifts are used:
VIR_CONNECT_GET_ALL_DOMAINS_STATS_ENFORCE_STATS = 1 << 31, /* enforce requested stats */
The script tries to parse all of these resulting in the following
tokens: "1", "VIR_CONNECT_LIST_DOMAINS_ACTIVE", "1<<31"; Then, the
script tries to turn these into integers using python's eval()
function. This function succeeds on the first and the last
tokens. But, if we were to modify the last example so that it's
of the following form:
VIR_CONNECT_GET_ALL_DOMAINS_STATS_ENFORCE_STATS = 1U << 31, /* enforce requested stats */
the token representing enum's member value will then be "1U<<31".
So our parsing is good. Unfortunately, python is not aware of the
difference between signed and unsigned C types, therefore eval()
fails over this token and the parser falls back thinking it's an
alias to another enum member. Well it's not.
The solution is to transform [0-9]U into [0-9] as for our
purposes here it's the same thing.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
All top-level functions have been moved to this class.
On top of that, the app.warning() method has been defined,
so that calls to it - already present in rebuild() - can
actually succeed.
libvirt-common.h is generated into builddir/include/libvirt. apibuild.py
only operated on srcdir/inlcude/libvirt. With VPATH build
srcdir/docs/libvirt-libvirt-common.html would not get generated and make
RPM failed.
Since commit f5d9c5d00c moved the virTypedParam stuff into
libvirt-common we did not generate any docs for them and neither did we
populate them into libvirt-api.xml. This broke the sanity check in
libvirt python. Fix it by generating docs for libvirt-common.h too.
Some macros don't make sense to be documented at all. Add infrastructure
to the web/api generator and add VIR_DEPRECATED and VIR_EXPORT_VAR as
macros we should not document.
No online docs are build from it since it doesn't really fit into our
document structure and new page will need to be created for it, but this
is at least a heads-up commit for easier parsing in order to build some
documentation (or python bindings) later on.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
If a macro has a string value, the @string attribute will contain the
value. Otherwise @string attribute will be missing.
For example, the following macro definition from libvirt-domain.h:
/**
* VIR_MIGRATE_PARAM_URI:
* ...
*/
# define VIR_MIGRATE_PARAM_URI "migrate_uri"
will result in
<macro name='VIR_MIGRATE_PARAM_URI' file='libvirt-domain' string='migrate_uri'>
<info><![CDATA[...]]></info>
</macro>
https://bugzilla.redhat.com/show_bug.cgi?id=1229199
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
The apibuild.py script did not handle whitespace in preprocessor
macros, so it failed to detect constants declared with '# define'
instead of '#define'. Since we now correctly indent our public
header files, we have silently lost all constants from
libvirt-api.xml. This also caused us to not detect formatting
errors in constant docs
The API docs generators were broken by the header file
re-organization. Specifically
* html/libvirt-libvirt.html was empty (and should be deleted)
* Makefile.am didn't install html/libvirt-libvirt-*.html
* hvsupport.html was mostly empty
* sitemap.html.in didn't list the new html/*.html files
Create a new libvirt-host.h file to hold the public
API definitions for the virConnect type. This header
file is not self-contained, so applications will not directly
include it. They will continue to #include <libvirt/libvirt.h>
Create a new libvirt-domain.h file to hold the public
API definitions for the virDomain type. This header
file is not self-contained, so applications will not directly
include it. They will continue to #include <libvirt/libvirt.h>
Create a new libvirt-event.h file to hold the public
API definitions for the virEvent type. This header
file is not self-contained, so applications will not directly
include it. They will continue to #include <libvirt/libvirt.h>
Create a new libvirt-storage.h file to hold the public
API definitions for the virStorage/Vol type. This header
file is not self-contained, so applications will not directly
include it. They will continue to #include <libvirt/libvirt.h>
Create a new libvirt-stream.h file to hold the public
API definitions for the virStream type. This header
file is not self-contained, so applications will not directly
include it. They will continue to #include <libvirt/libvirt.h>
Note the definition of virStreamPtr is not moved, since that
must be declared early for all other libvirt APIs to be able
to reference it.
Create a new libvirt-secret.h file to hold the public
API definitions for the virSecret type. This header
file is not self-contained, so applications will not directly
include it. They will continue to #include <libvirt/libvirt.h>
Create a new libvirt-nodedev.h file to hold the public
API definitions for the virNodeDevice type. This header
file is not self-contained, so applications will not directly
include it. They will continue to #include <libvirt/libvirt.h>
Create a new libvirt-nwfilter.h file to hold the public
API definitions for the virNWFilter type. This header
file is not self-contained, so applications will not directly
include it. They will continue to #include <libvirt/libvirt.h>
Create a new libvirt-interface.h file to hold the public
API definitions for the virInterface type. This header
file is not self-contained, so applications will not directly
include it. They will continue to #include <libvirt/libvirt.h>
Create a new libvirt-network.h file to hold the public
API definitions for the virNetwork type. This header
file is not self-contained, so applications will not directly
include it. They will continue to #include <libvirt/libvirt.h>
Create a new libvirt-domain-snapshot.h file to hold the public
API definitions for the virDomainSnapshot type. This header
file is not self-contained, so applications will not directly
include it. They will continue to #include <libvirt/libvirt.h>
The virTypedParameterValidateSet method will need to be used
from several libvirt-*.c files so must be non-static
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
We publish libvirt-api.xml for others to use, and in fact, the
libvirt-python bindings use it to generate python constants that
correspond to our enum values. However, we had an off-by-one bug
that any enum that relied on C's rules for implicit initialization
of the first enum member to 0 got listed in the xml as having a
value of 1 (and all later members of the enum were equally
botched).
The fix is simple - since we add one to the previous value when
encountering an enum without an initializer, the previous value
must start at -1 so that the first enum member is assigned 0.
The python generator code has had the off-by-one ever since DV
first wrote it years ago, but most of our public enums were immune
because they had an explicit = 0 initializer. The only affected
enums are:
- virDomainEventGraphicsAddressType (such as
VIR_DOMAIN_EVENT_GRAPHICS_ADDRESS_IPV4), since commit 987e31e
(libvirt v0.8.0)
- virDomainCoreDumpFormat (such as VIR_DOMAIN_CORE_DUMP_FORMAT_RAW),
since commit 9fbaff0 (libvirt v1.2.3)
- virIPAddrType (such as VIR_IP_ADDR_TYPE_IPV4), since commit
03e0e79 (not yet released)
Thanks to Nehal J Wani for reporting the problem on IRC, and
for helping me zero in on the culprit function.
* docs/apibuild.py (CParser.parseEnumBlock): Fix implicit enum
values.
Signed-off-by: Eric Blake <eblake@redhat.com>
Our documentation generator is a bit messy, to say the least. For
instance, the description to return values of a function is
searched within C comment. Currently, all lines that start with
'returns' or 'Returns' are viewed as return value description.
However, there are some valid uses where the 'returns' word is in
the middle of a sentence describing function behavior not the
return value. And there are no places where 'returns' is used to
describe return values. For instance:
virDomainDetachDeviceFlags, virConnectNetworkEventRegisterAny and
virDomainGetDiskErrors. This leads to HTML documemtation being
generated incorrectly.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Any source file which calls the logging APIs now needs
to have a VIR_LOG_INIT("source.name") declaration at
the start of the file. This provides a static variable
of the virLogSource type.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Consistently use "is" or "is not" to compare variables to None,
because doing so is preferrable, as per PEP 8
(http://www.python.org/dev/peps/pep-0008/#programming-recommendations):
> Comparisons to singletons like None should always be done with is or
> is not, never the equality operators.
All APIs that take typed parameters are only using params address in
their entry point debug messages. With the new VIR_TYPED_PARAMS_DEBUG
macro, all functions can easily log all individual typed parameters
passed to them.
Ensure that the driver struct field names match the public
API names. For an API virXXXX we must have a driver struct
field xXXXX. ie strip the leading 'vir' and lowercase any
leading uppercase letters.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
