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

Fwd: Re: Progress migrating cffi and pycparser to libclang

Forwarding? this thread to the CFFI developers...

Re Paul: Thanks for your feedback.

My intended audience are developers who can use hg to fetch/build source 
code without pip.

Best regards,


-------- Message transf?r? --------
Sujet?: 	Re: Progress migrating cffi and pycparser to libclang
Date?: 	Thu, 4 Jan 2018 21:25:27 +0000
De?: 	Paul Moore <p.f.moore at gmail.com>
Pour?: 	Etienne Robillard <tkadm30 at yandex.com>
Copie ??: 	Python <python-list at python.org>

On 4 January 2018 at 21:02, Etienne Robillard <tkadm30 at yandex.com> wrote:
>> As a fork/extension for cffi, I have no particular opinion (I'm
>> unlikely to ever use it). But the advantage of pycparser is that it's
>> cross-platform and pure Python, so I doubt this will be acceptable for
>> inclusion into CFFI itself.
> CFFI/pycparser definitely need to be patched to support parsing standard C
> directives like #define and #include in the ffi.cdef() function.
> The easiest solution is to migrate the internal parsing code to libclang, a
> state-of-the art C/C++ compiler based on LLVM.

I would strongly object to adding a dependency to cffi that couldn't
be automatically installed by pip as part of standard dependency
resolution (i.e., a PyPI hosted Python project with wheels available
for all common platforms - Linux, Mac OS and Windows). But ultimately
if you're proposing this as a change to cffi, you should be getting
the opinions of the cffi devs, not just asking on this list. (I notice
you have posted to the cffi mailing list, but haven't had any response