Scr*_*ter 2 c++ version-control mercurial makefile build
我一直在制作一个makefile.它通过使用includes支持轻松创建exe,lib和dll类型的项目.
现在我又开始使用mercurial,我注意到在构建之前一切都很好.您看到我的目标文件进入每个子项目的源目录下的子目录.我将lib,exe和dll文件构建到主工作目录下的目录中.这意味着每当我这样做时hg status,它会用'?'列出这些临时二进制文件,这是我不想要的视觉混乱.(这不是mercurial的错,当然我也不会那么天真地检查它们到repo或类似的东西.)我只想要hg状态来发现我可能忘记正确添加的文件,而不是这些临时构建的文件.
目前的目录结构是这样的:
projroot
-- subproj1 (for source files)
-- subproj1/intr (for object files, release build)
-- subproj2 (for source files)
-- subproj2/intr (for object files, release build)
-- bin (for exes and dlls)
-- lib (for libraries that I build)
Run Code Online (Sandbox Code Playgroud)
所以我正在考虑重构makefile以保持在工作目录之外构建的文件(objs libs dlls和exes).大多数人都将所有二进制文件保存在一个比projroot高一级的目录中,以避免SCM看到它们吗?必须有一些最好的做法.我使用的东西似乎很好,但我认为它有点过时了,当然我已经看到了ant为Java src和类创建一个完全独立的树的方式.
这个结构怎么样?
projroot (contains common makefile includes and repo in here)
-- subproj1 (for source files)
-- subproj2 (for source files)
build
-- subproj1/intr (.o / .obj files in release build)
-- subproj1/intd
-- subproj2/intr
-- subproj2/intd
-- lib (all built libs)
-- bin (all built exes and DLLs)
Run Code Online (Sandbox Code Playgroud)
构建目录位于工作目录之外,因此我们将使用的任何SCM都会忽略它.
你的答案必须考虑到projroot中常见的makefile源代码,以及有多个项目的事实,每个项目都有自己的内置二进制文件集合,你可能需要单独分发.
我个人更喜欢这样的目录结构,因为我不喜欢任何源子文件夹被编译的中间文件污染.干净只是删除输出文件夹的问题
projroot
-- subproj1 (for source files)
-- subproj2 (for source files)
-- output/bin (for exes and dlls)
-- output/lib (for libraries that I build)
-- output/subproj1/ ( for *.o files )
-- output/subproj2/ ( for *.o files )
Run Code Online (Sandbox Code Playgroud)
这有一个额外的好处,我可以设置整个输出文件夹被源控件管理忽略,我不必检查SCM软件,看看生成了什么文件和什么是版本控制.
| 归档时间: |
|
| 查看次数: |
223 次 |
| 最近记录: |