(Presumably the following question is not iPhone specific, aside from the fact that we would likely use a Framework or dynamic library otherwise.)
(可能以下问题不是iPhone特有的,除了我们可能会使用框架或动态库的事实。)
I am building a proprietary iPhone SDK for a client, to integrate with their web back-end. Since we don't want to distribute the source code to customers, we need to distribute the SDK as a static library. This all works fine, and I have verified that I can link new iPhone apps against the library and install them on the device.
我正在为客户构建一个专有的iPhone SDK,以便与他们的网络后端集成。由于我们不希望将源代码分发给客户,因此我们需要将SDK作为静态库进行分发。这一切都运行正常,我已经验证我可以将新的iPhone应用程序链接到库并将其安装在设备上。
My concern is around third party libraries that our SDK depends on. For example we are currently using HTTPRiot and Three20 (the exact libraries may change, but that's not the point). I am worried that this may result in conflicts if customers are also using any of these libraries (and perhaps even different versions) in their app.
我关心的是SDK所依赖的第三方库。例如,我们目前正在使用HTTPRiot和Three20(确切的库可能会改变,但这不是重点)。我担心如果客户也在他们的应用程序中使用任何这些库(甚至可能是不同的版本),这可能会导致冲突。
What are the best practices around this? Is there some way to exclude the dependent libraries' symbols from our own static library (in which case customers would have to manually link to both our SDK as well as HTTPRiot and Three20)? Or is there some other established mechanism?
这有什么最好的做法?有没有办法从我们自己的静态库中排除依赖库的符号(在这种情况下,客户必须手动链接到我们的SDK以及HTTPRiot和Three20)?还是有其他一些既定的机制?
I'm trying to strike a balance between ease of use and flexibility / compatibility. Ideally customers would only have to drop our own SDK into their project and make a minimal number of build settings changes, but if it makes things more robust, it might make more sense to have customers link against multiple libraries individually. Or I suppose we could distribute multiple versions of the SDK, with and without third party dependencies, to cover both cases.
我试图在易用性和灵活性/兼容性之间取得平衡。理想情况下,客户只需将自己的SDK放入他们的项目并进行最少数量的构建设置更改,但如果它使事情更加健壮,那么让客户单独链接多个库可能更有意义。或者我想我们可以分发多个版本的SDK,包括和不包含第三方依赖,以涵盖这两种情况。
I hope my questions make sense... Coming mainly from a Ruby and Java background, I haven't had to deal with compiled libraries (in the traditional sense) for a long time... ;)
我希望我的问题有意义......主要来自Ruby和Java背景,我不需要长时间处理编译库(传统意义上的)......;)
1 个解决方案
#1
1
If it were me I would specify exactly which versions of those 3rd party libraries my library interoperates with. I would then test against them, document them, and probably deliver with those particular versions included in the release.
如果是我,我会准确指定我的库与之互操作的第三方库的哪些版本。然后我会对它们进行测试,记录它们,并且可能会提供发行版中包含的那些特定版本。
Two things I would worry about:
-I would want to be sure it 'just works' when my customers install it.
-I wouldn't want to guarantee support for arbitrary future versions of those 3rd party libraries.
我担心的两件事: - 当我的客户安装它时,我想确定它“正常”。 - 我不想保证支持这些第三方库的任意未来版本。
It is fine to include a process for the customer to move to newer versions, but if anything doesn't work then I would expect the customer to pay for that development work as an enhancement, rather than it being a free bug fix (unless you include that in the original license/support arrangement).
可以包含一个让客户转移到更新版本的流程,但如果有什么不起作用,那么我希望客户支付该开发工作作为增强功能,而不是免费的错误修复(除非你包括原始许可/支持安排中的内容)。
At that point it becomes an issue of ensuring your specific versions of the 3rd party libraries can work happily alongside anything else the customer needs (in your case a web back-end). In my experience that is usually a function of the library, e.g. some aren't designed so multiple versions can run side-by-side.
此时,确保您的特定版本的第三方库可以与客户需要的任何其他内容(在您的情况下是Web后端)一起快乐地工作成为一个问题。根据我的经验,这通常是图书馆的一个功能,例如有些设计不是因为多个版本可以并排运行。
#1
1
If it were me I would specify exactly which versions of those 3rd party libraries my library interoperates with. I would then test against them, document them, and probably deliver with those particular versions included in the release.
如果是我,我会准确指定我的库与之互操作的第三方库的哪些版本。然后我会对它们进行测试,记录它们,并且可能会提供发行版中包含的那些特定版本。
Two things I would worry about:
-I would want to be sure it 'just works' when my customers install it.
-I wouldn't want to guarantee support for arbitrary future versions of those 3rd party libraries.
我担心的两件事: - 当我的客户安装它时,我想确定它“正常”。 - 我不想保证支持这些第三方库的任意未来版本。
It is fine to include a process for the customer to move to newer versions, but if anything doesn't work then I would expect the customer to pay for that development work as an enhancement, rather than it being a free bug fix (unless you include that in the original license/support arrangement).
可以包含一个让客户转移到更新版本的流程,但如果有什么不起作用,那么我希望客户支付该开发工作作为增强功能,而不是免费的错误修复(除非你包括原始许可/支持安排中的内容)。
At that point it becomes an issue of ensuring your specific versions of the 3rd party libraries can work happily alongside anything else the customer needs (in your case a web back-end). In my experience that is usually a function of the library, e.g. some aren't designed so multiple versions can run side-by-side.
此时,确保您的特定版本的第三方库可以与客户需要的任何其他内容(在您的情况下是Web后端)一起快乐地工作成为一个问题。根据我的经验,这通常是图书馆的一个功能,例如有些设计不是因为多个版本可以并排运行。