Simple mechanism to disable Python binding using bundled Capstone sources

[koobs]

Downstream packagers and porters expect the default build of a software package to use system provided libraries in almost all cases (except for example where forked+patched code is involved).

For those software packages where there is a compelling case to be made to bundle dependent library code, a trivial mechanism is almost always provided for downstream consumers (particularly OS packagers) to disable/revert the default functionality back to what is, the normal expectation, and the a common (principle of least astonishment) default.

Currently the capstone Python package bundles the capstone core code in the package, but provides no mechanism to disable it or change that behaviour.

The FreeBSD port for example needs to workaround this in the following manner:

+# Do not bundle libcapstone.so
+
+--- setup.py.orig  2015-07-15 07:43:18 UTC
++++ setup.py
+@@ -175,17 +175,4 @@ setup(
+         'Programming Language :: Python :: 3',
+     ],
+     requires=['ctypes'],
+-    cmdclass=dict(
+-        build_clib=custom_build_clib,
+-        sdist=custom_sdist,
+-    ),
+-
+-    libraries=[(
+-        'capstone', dict(
+-            package='capstone',
+-            sources=dummy_src()
+-        ),
+-    )],
+-
+-    data_files=[(SITE_PACKAGES, SETUP_DATA_FILES)],
+ )

If the default cannot be changed to the preferred "install capstone, pip install capstone" (that is, not use bundled sources by default, even if they remain distributed with the sdist), then the following or similar mechanism would be better than the current method:

• An environment variable SYSTEM_LIBRARY (or similarly named) that precludes using the bundled source code

[aquynh]

there are two things:

• the Capstone package (and Python Capstone package) of FreeBSD is quite outdated last time I checked: it is still 2.x version, while we released version 3.0.4 long time ago with a lot of changes and bugfixes. please could you update Capstone packages in FreeBSD to 3.0.4?
• for the proposed change, please consider sending a pull request for our master branch.

thanks

[koobs]

@aquynh Thanks for the quick response mate. I'd already approved an update to 3.0.4 here, which includes the change mentioned above to retain the default behaviour in 2.x. The ugliness of the workaround is why I spent 15 minutes articulating the case for change in an issue ;)

In terms of a PR, I have no idea how you want to proceed, nor what mechanisms you might want include/exclude as candidates. If it were me, I'd be pulling the bundled stuff out (even if the sources remained), as 99% of Python packages do for very good reasons.

[aquynh]

perhaps a pull request for adding "An environment variable SYSTEM_LIBRARY (or similarly named) that precludes using the bundled source code" will be best for us.

thanks.