假设我们有一个名为MyAwesomeLib的C++库的已完成源代码。我们的目标是将其部分功能暴露给Python，因此我们使用SWIG创建了一个包装器，并生成了一个名为PyMyAwesomeLib的Python包。
现在的目录结构如下：
root_dir
|-src/
|-lib/
| |- libMyAwesomeLib.so
| |- _PyMyAwesomeLib.so
|-swig/
| |- PyMyAwesomeLib.py
|-python/
|- Script_using_myawesomelib.py
到目前为止一切都很顺利。理想情况下，我们接下来要做的就是以一种“Pythonic”的方式将lib/*.so、swig/*.py 和 python/*.py 复制到site-packages中相应的目录中。
python setup.py install
然而，当我试图使用setuptools和distutils来实现这个简单目标时，我变得非常困惑。这两个工具都通过一个内部系统处理Python扩展的编译，其中源文件、编译器标志等都是通过setup(ext_module=[Extension(...)])传递的。但这是荒谬的，因为MyAsesomeLib有一个完全功能的构建系统，它基于makefile。移植嵌入在makefile中的逻辑将是冗余和完全不必要的工作。
经过一些研究，似乎还剩下两个选择，我可以覆盖setuptools.command.build和setuptools.command.install，使用现有的makefile并直接复制结果，或者我可以让setuptools知道这些文件，并在安装期间要求它复制它们。第二种方式更具吸引力，但也是最让我头疼的。我尝试了以下选项，但没有成功：
- package_data和include_package_data不起作用，因为*.so文件不在版本控制之下，也不在任何包内。 - data_files似乎不起作用，因为这些文件只有在运行python setup.py sdist时才会被包含，但在运行python setup.py install时被忽略。这与我想要的相反。.so文件不应该包含在源分发中，而应在安装步骤中复制。 - MANIFEST.in由于与data_files相同的原因而失败。 - eager_resources也不起作用，但说实话我不知道eager_resources、data_files或MANIFEST.in之间的区别。
我认为这实际上是一个普遍存在的情况，我希望有一个简单的解决方案。任何帮助将不胜感激。