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

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

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

> 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?


> -------- 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.