On Wed, Feb 27, 2013 at 2:39 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > On Wed, Feb 27, 2013 at 7:06 PM, Maciej Fijalkowski <fij...@gmail.com> wrote: >>> 3. Cffi basicly contains a (limited) C parser, and those are notoriously >>> hard to get exactly right. Luckily cffi only needs to interpret >>> declarations and not the full language, but even so this can be a risk of >>> subtle bugs. >> >> It seems to work. > > C itself shouldn't be *too* bad - it's trying to parse C++ that is > truly insane (which is why Dave Beazley explicitly warned Maciej and > Armin away from that based on his experience with SWIG). > > Looking at pycparsing more closely though, there may be a problem with > the C preprocessing step on Windows. While on Linux it uses the system > "cpp", for Windows it currently bundles a copy of the LCC > preprocessor, which may pose licensing challenges > (https://github.com/drh/lcc/blob/master/CPYRIGHT). However, this > concern may not be applicable to cffi: given cffi's requirement for a > full external C compiler to actually *create* the C extension modules > during development, and the ability to retrieve everything necessary > directly from the created C extension when no C compiler is available, > it seems there would be no reason to ever need the bundled C > preprocessor. So we simply don't ship it, and the LCC license becomes > irrelevant. > > Cheers, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
cffi does not use preprocessor _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
