完美的makefile [英] Perfect makefile

问题描述

我想使用 make 获得模块化版本与持续集成，自动单元测试和多-platform builds 。类似的设置在Java和.NET中很常见，但是我很难把这些放在make和C / C ++中。如何实现？

我的要求：

• 非递归make（Stack Overflow question 您对非递归make的体验是什么？ ） li>
  
• 模块化系统（即最小依赖项，makefile在包含组件的子目录中）


• 多平台（通常用于单元测试的PC，用于系统集成/ ）


• 完成相关性检查


• 执行（自动）单元测试成为持续集成系统


• 易于使用

http://code.google.com/p/nonrec-make =nofollow noreferrer> non-rec make 。

到目前为止的限制：

• 未集成单元测试


• 基于Windows的ARM编译器与Cygwin路径不兼容


• makefile与Windows \路径不兼容


• 转发依赖项

我的结构如下：

  project_root 
 / algorithm 
 / src 
 /algo1.c 
 /algo2.c 
 / unit_test 
 /algo1_test.c 
 /algo2_test.c 
 / out 
 algo1_test.exe 
 algo1_test.xml 
 algo2_test.exe 
 algo2_test .xml 
 headers.h 
 / embunit 
 / harnass 
 makefile 
 Rules.top 
  

我想保持简单;这里单元测试（algo1_test.exe）依赖于'algorithm'组件（ok）和单元测试框架（在构建时可能会或可能不知道）。但是，将构建规则移动到顶部make不会吸引我，因为这将在整个系统中分发组件的本地知识。

对于Cygwin路径： m工作在使用相对路径的构建。这解决了 / cygdrive / c 问题（编译器一般可以处理/路径），而不引入C：（使不喜欢）。任何其他想法？

解决方案

CMake 与相关工具CTest和CDash似乎可以满足您的要求。值得一试。

Bill Hoffman（一个领导CMake开发人员）是指递归使用考虑有害文件在 post ：

...因为cmake正在创建makefile为你，避免了许多缺点
的递归make，例如你不应该调试
的makefile，甚至想想它们是如何工作的。

另请参见这个回答递归使 - 朋友或敌人？这里是stackoverflow。

-
递归物品 - 朋友或敌人？

I'd like to use make to get a modular build in combination with continuous integration, automatic unit testing and multi-platform builds. Similar setups are common in Java and .NET, but I'm having a hard time putting this together for make and C/C++. How can it be achieved?

My requirements:

• fast build; non-recursive make (Stack Overflow question What is your experience with non-recursive make?)
• modular system (that is, minimal dependencies, makefile in subdirectory with components)
• multiplatform (typically PC for unit testing, embedded target for system integration/release)
• complete dependency checking
• ability to perform (automatic) unit tests (Agile engineering)
• hook into continuous integration system
• easy to use

I've started with non-rec make. I still find it a great place to start.

Limitations so far:

• no integration of unit tests
• incompatibility of windows based ARM compilers with Cygwin paths
• incompatibility of makefile with Windows \ paths
• forward dependencies

My structure looks like:

    project_root
       /algorithm
                 /src
                     /algo1.c
                     /algo2.c
                 /unit_test
                     /algo1_test.c
                     /algo2_test.c
                 /out
                     algo1_test.exe
                     algo1_test.xml
                     algo2_test.exe
                     algo2_test.xml
             headers.h
       /embunit
       /harnass
   makefile
   Rules.top

I'd like to keep things simple; here the unit tests (algo1_test.exe) depend on both the 'algorithm' component (ok) and the unit test framework (which may or may not be known at the time of building this). However, moving the build rules to the top make does not appeal to me as this would distribute local knowledge of components throughout the system.

As for the Cygwin paths: I'm working on making the build using relative paths. This resolves the /cygdrive/c issue (as compilers can generally handle / paths) without bringing in C: (which make dislikes). Any other ideas?

解决方案

CMake together with the related tools CTest and CDash seem to answer your requirements. Worth giving it a look.

Bill Hoffman (A lead CMake developer) refers to the Recursive Make Considered Harmful paper in a post at the CMake mailing list:

... since cmake is creating the makefiles for you, many of the disadvantages of recursive make are avoided, for example you should not have to debug the makefiles or even think about how they work. There are other examples of things in that paper that cmake fixes for you as well.

See also this answer for "Recursive Make - friend or foe?" here on stackoverflow.

- Recursive Make - friend or foe?

这篇关于完美的makefile的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！