A few changes needed to support go-libvirt #164
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
At DigitalOcean, we are using
c-for-go
for ourgo-libvirt
project.Two breaking changes have occurred recently, which are preventing us from using
c-for-go
to generate the necessary constants:(1) In
libvirt
itself, header files were switched from using double-quotes (#include "foo.h"
) to using brackets (#include <foo.h>
). Because these were self-referencing headers (intended for eventual placement on the system include path on the target system), this resulted in the inability ofc-for-go
to findlibvirt
's own headers. We resolved this by adding the ability to configure the system include path, such (in our case) by specifyingSysIncludePaths: [./lv_source/include, ./lv_source/build/include]
in the configuration.(2) In
c-for-go
, an update of thecc
dependency tov4
caused a change in the way enums were handled. For context, althoughc-for-go
correctly treats C enumerations as being of typeint
, thelibvirt
code contains two enum usages where their values are used for bit fields, and explicitly declared as unsigned 32-bit values. This causesc-for-go
to generate incorrect code (because the integer value2147483648
, which comes from1u << 31
, could not fit into a signed 32-bit field). This was resolved by adding the concept ofenum
type tips andunsigned
type tips (TipTypeUnsigned
), such as (in our case) by declaring the following in the configuration:We have been testing these changes successfully in our
digitalocean-labs/c-for-go
fork, and hope you will consider applying them to the official version.