[python-cffi] Fwd: Re: Progress migrating cffi and pycparser to libclang

[Eli Bendersky]

On Fri, Jan 5, 2018 at 1:15 AM, Etienne Robillard <tkadm30 at yandex.com>
wrote:

> 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,
>
> Etienne
>

I'd like to understand the requirements here better, from the point of view
of pycparser. What are you trying to accomplish?

One of the issues with parsing "original" headers (with #defines and
#includes and all that jazz) is that you have to match the compilation
environment very precisely. When a compiler compiles a large project it
could set dozens of -Ds, as well as -Is pointing to directories with
additional headers. This is usually specified in Makefiles or something
similar. Clang and libclang deal with this by having the concept of a
compilation database which remembers for each file what the exact flags to
compile it are (https://clang.llvm.org/docs/JSONCompilationDatabase.html)

To make this *really* work for CFFI you'd have to take all of this into
account -- do you really want to deal with this on the CFFI level?

Eli








>
> -------- 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> <p.f.moore at gmail.com>
> Pour : Etienne Robillard <tkadm30 at yandex.com> <tkadm30 at yandex.com>
> Copie à : Python <python-list at python.org> <python-list at python.org>
>
> On 4 January 2018 at 21:02, Etienne Robillard <tkadm30 at yandex.com> <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
> yet).
>
> Paul
>
>
> --
> -- python-cffi: To unsubscribe from this group, send email to
> python-cffi+unsubscribe at googlegroups.com. For more options, visit this
> group at https://groups.google.com/d/forum/python-cffi?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "python-cffi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to python-cffi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>