perl构建模块，使用来自其他模块的c源代码

我正在开发一个我希望有两个后端的模块，一个

模块（：：PerlArray）

和

模块：：PDL

（这取决于

模块

）。两者都需要访问

functions.c/.h

文件才能进行构建。该文件具有模块所需的相当复杂的逻辑。是否有办法将其与系统上的

module:：PP

一起保存，然后将其添加到

EU:：MM

或

M:：B

中的相应构建标志中，而不是与每个模块单独分发

更直观地说

--Module--
Module.pm
Module/PerlArray.pm
Module/PerlArray.xs (#include functions.h
              #include perlarray_backend.h)
Module/src/functions.c
Module/src/perlarray_backend.c
Module/inc/functions.h
Module/inc/perlarray_backend.h

--Module::PDL--
Module/PDL.pm
Module/PDL.xs (#include functions.h /*from Module*/
               #include pdl_backend.h)
Module/src/pdl_backend.c
Module/inc/pdl_backend.h

---

编译生成functions.o和links。我确信我可以找到如何正确设置标志，但如何使模块在安装时保留

functions.c

文件，以及如何在安装

模块：：PDL

时找到它？是否有一些位置可以放置

函数.c/.h

？

模块应该可以独立安装。也就是说，如果我安装了必备的Perl模块（但不一定仍然以源代码的形式存在），那么应该可以在一个分布式tar文件中安装所有模块，而无需参考任何其他模块的源代码

你有选择。一种是让一个源目录创建几个分布式tar球，每个tar球可以在分布式源目录中有一个共享

函数的副本。[ch]

---

另一个主要选项是将两个模块捆绑到一个分布式tar ball中。

模块应该可以独立安装。也就是说，如果我安装了必备的Perl模块（但不一定仍然以源代码的形式存在），那么应该可以在一个分布式tar文件中安装所有模块，而无需参考任何其他模块的源代码

你有选择。一种是让一个源目录创建几个分布式tar球，每个tar球可以在分布式源目录中有一个共享

函数的副本。[ch]

---

另一个主要选项是将两个模块捆绑到一个分布式tar球中。

您看过DBI吗？它实现了您的建议：它安装了一些DBD驱动程序可以包含在XS代码中的.h文件，以及DBD驱动程序可以调用的库。

您看过DBI吗？它实现了您的建议：它安装了一些DBD驱动程序可以包含在XS代码中的.h文件，以及DBD驱动程序可以调用的库。

PP模块应该为纯Perl保留（这是约定），因此它不应该依赖于[ch]文件。是的，我将处理命名问题。我的pp（正如我所说）使用Perl本机数组而不是使用PDL，但是你是对的，如果它使用XS，我不应该称它为pp。pp模块应该为纯Perl保留（这是约定），因此它不应该依赖于[ch]文件。是的，我将处理命名问题。我的pp（正如我所说的）使用Perl本机数组而不是使用PDL，但你是对的，如果它使用XS，我不应该称它为pp。虽然我大体上同意你所说的，但我想这样做的原因是PDL是一个庞大而烦人的安装链，它为我的模块提供的只是一个更干净的数据存储单元。我不认为我的

模块

的所有（潜在）用户都希望也不需要PDL这个令人头痛的东西。有一个较小的社区将从中受益，对于他们来说，为什么要构建一个巨大的

SV*

数组，这样他们就可以在最后转换为PDL对象。因此，由于

Module:：PDL

将依赖于

Module

，并且无论如何都无法独立安装，我认为这种情况是可行的。虽然我大体上同意你所说的，但我想这样做的原因是，PDL是一个庞大而烦人的安装链，它为我的模块提供的只是一个更干净的数据存储单元。我不认为我的

模块

的所有（潜在）用户都希望也不需要PDL这个令人头痛的东西。有一个较小的社区将从中受益，对于他们来说，为什么要构建一个巨大的

SV*

数组，这样他们就可以在最后转换为PDL对象。因此，由于

Module:：PDL

将依赖于

Module

，并且无论如何都不能独立安装，因此我认为这种情况是可行的。