Remove const char* elements from cdef

[flacjacket]

When building the ffi module, there is a message printed noting that
string literals are ignored when building. I'm not sure if it is
possible to actually get at these value via the generated ffi module,
trying cairocffi.ffi.CAIRO_TAG_DEST or cairocffi.ffi.CAIRO_TAG_LINK
returns an error. These constants don't seem to be used internally, and
are accessible via the exported value as cairocffi.constants.TAG_DEST
or cairocffi.constants.TAG_LINK.

[liZe]

Hello, and thank you for this pull request.

These constants don't seem to be used internally, and
are accessible via the exported value as cairocffi.constants.TAG_DEST
or cairocffi.constants.TAG_LINK.

It's true. But the goal of mkconstants.py is to generate the whole constants.py file. If we remove CAIRO_TAG_DEST and CAIRO_TAG_LINK definitions from the headers, we remove TAG_DEST and TAG_LINK from the constants.py file generated by mkconstants.py.

In other words: if we merge this PR and call mkconstants.py, we remove TAG_DEST and TAG_LINK constants. That's not what we want 😄.

When building the ffi module, there is a message printed noting that
string literals are ignored when building.

I don't get this message. Do you get it when calling ffi_build.py or when installing with pip (or both)?

[flacjacket]

When I run python cairocffi/ffi_build.py, I see:
/usr/lib/python3.7/site-packages/cffi/cparser.py:150: UserWarning: String literal found in cdef() or type source. String literals are ignored here, but you should remove them anyway because some character sequences confuse pre-parsing.
This is why I'm proposing to change these.

I get that is the goal of mkconstants, however I was not able to actually access these values via the generated ffi:

In [1]: import cairocffi

In [2]: cairocffi.cairo.CAIRO_ANTIALIAS_BEST
Out[2]: 6

In [3]: cairocffi.cairo.CAIRO_TAG_DEST
---------------------------------------------------------------------------
error                                     Traceback (most recent call last)
<ipython-input-3-cdc3caa45c13> in <module>
----> 1 cairocffi.cairo.CAIRO_TAG_DEST

error: symbol 'CAIRO_TAG_DEST' not found in library 'libcairo.so.2': /usr/lib64/libcairo.so.2: undefined symbol: CAIRO_TAG_DEST

In [4]: cairocffi.cairo.CAIRO_TAG_LINK
---------------------------------------------------------------------------
error                                     Traceback (most recent call last)
<ipython-input-4-431cc28517d3> in <module>
----> 1 cairocffi.cairo.CAIRO_TAG_LINK

error: symbol 'CAIRO_TAG_LINK' not found in library 'libcairo.so.2': /usr/lib64/libcairo.so.2: undefined symbol: CAIRO_TAG_LINK

The mkconstants script just manually puts these constants here, they are not actually parsed out of the header file, so I did play a bit with what is given in the cdef, and I was not able to come up with something valid to put in its place that would make these symbols accessible. My note about them not being used internally is just to note that there is no clear way to access them through the generated ffi via the current API.

This does not change the fact that these values are still generated up at the top of constants.py, on lines 4-6, should somebody want to make use of these constants:

TAG_DEST = b"cairo.dest"

TAG_LINK = b"Link"

so we are not totally removing these constants, we are just removing the instances of them that are inaccessible from the ffi and are generating cffi warnings.

[liZe]

When I run python cairocffi/ffi_build.py, I see:
/usr/lib/python3.7/site-packages/cffi/cparser.py:150: UserWarning: String literal found in cdef() or type source. String literals are ignored here, but you should remove them anyway because some character sequences confuse pre-parsing.

Oh. It's strange, I didn't get the error before, but I get it now.

The mkconstants script just manually puts these constants here, they are not actually parsed out of the header file

It's not fully true. The current code in master doesn't read them from cairo's headers, but it adds them to the source where other headers are. The constants are then generated from the source variable parsed by pycparser, just as other variables. The work is done by the visit_Decl method in PrintEnumsVisitor.

I get that is the goal of mkconstants, however I was not able to actually access these values via the generated ffi

It's true, it's a problem. As CAIRO_TAG_DEST is defined as a macro, we should should handle them as we handle enums (type used for other constants). Cffi doesn't handle macros and there's probably no way to make them available from cairocffi.cairo.

This does not change the fact that these values are still generated up at the top of constants.py, on lines 4-6

They're not anymore if I use your branch (or did I miss something?).

should somebody want to make use of these constants

Actually, they at least are used in WeasyPrint and work well.

[flacjacket]

Ah, I see, I was thinking the lines that I was deleting was directly creating the constants.py file. I didn't realize that was the source that was being visited by the printing code. I have tweaked it so that we emit the constants into the top of the constants.py file, but that these constants do not wind up in the cdef'd source. I have also regenerated the constants.py off of the latest cairo release.

[liZe]

I have tweaked it so that we emit the constants into the top of the constants.py file, but that these constants do not wind up in the cdef'd source.

Thank you! It's probably the best way to do that. I'll try to see what we can do with CAIRO_PDF_OUTLINE_ROOT too.

I have also regenerated the constants.py off of the latest cairo release.

OK.