将 Maven 用于 C/C++ 项目
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1541771/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Using Maven for C/C++ projects
提问by Bostone
I'm putting Maven build around cluster of amateur, poorly written and frankly - primitive C/C++ code (meaning some C, some C++). Problem is - there's lots of it in circulation currently and cannot be easily replaced. Building it requires a lot of tribal knowledge (you have to go from cube to cube just to find out how to compile/build various parts) and releasing is total nightmare. (No - I'm not going to rewrite it, plz don't ask)
My question is - should I use maven-native-pluginto replace multitude of short makefiles or use exec-maven-pluginto simply execute these?
I had pretty good experienceso far with the latter doing .NET and don't know if I should invest into nativeplugin or stay with exec? If you had experience with "Mavenizing" C/C++ I would love to get some advice.
我将 Maven 构建在一群业余的、写得很差的、坦率的 - 原始 C/C++ 代码（意味着一些 C，一些 C++）周围。问题是 - 目前有很多流通，不能轻易更换。构建它需要大量的部落知识（你必须从一个立方体到另一个立方体才能找出如何编译/构建各个部分），而发布完全是一场噩梦。（不 - 我不会重写它，请不要问）我的问题是 - 我应该maven-native-plugin用来替换大量的短生成文件还是exec-maven-plugin用来简单地执行这些？到目前为止，我在后者使用 .NET方面有很好的经验，但不知道我是应该投资native插件还是继续使用exec？如果您有“Mavenizing”C/C++ 的经验，我很想得到一些建议。
回答by SingleShot
I highly recommend the maven-nar-plugin. I find it superior in many ways to the alternatives. It doesn't require listing out source files, handles multiple OSes and architectures, handles unit and integration tests, and generally follows "the maven way". It introduces a new kind of packaging - the NAR, or "native archive", that contains the artifact you care about (.dll, .so, .a, .exe, etc.) but also metadata, headers, etc. in a way that makes sense.
我强烈推荐maven-nar-plugin。我发现它在很多方面都优于替代品。它不需要列出源文件，处理多个操作系统和架构，处理单元和集成测试，并且通常遵循“maven 方式”。它引入了一种新的打包方式——NAR 或“本地存档”，其中包含您关心的工件（.dll、.so、.a、.exe 等）以及元数据、标题等。有道理的方式。
It does require a bit of up front work to package third-party software up into NARs, but its pretty straightforward. Once they are NARs, you simply use the normal Maven dependency mechanism to link with them, for example:
将第三方软件打包到 NAR 中确实需要一些前期工作，但它非常简单。一旦它们成为 NAR，您只需使用普通的 Maven 依赖机制来链接它们，例如：
<dependency>
<groupId>cppunit</groupId>
<artifactId>cppunit</artifactId>
<scope>test</scope>
</dependency>
One drawback is that it does not appear to be actively maintained, but it is full-featured and is a rather impressive example of Maven plugin authoring.
一个缺点是它似乎没有得到积极维护，但它功能齐全，是 Maven 插件创作的一个令人印象深刻的例子。
