摘要: 最近一直在做一个build system的依赖管理,感觉其中某些内容可以抽取出来,作为一道很不错的面试题:假设你在同时编译n个项目,他们相互之间有依赖关系,比如:现在,让你写一个算法,把每个项目的依赖拍平:即把其所有间接依赖+直接依赖的项目都输出。比如上面这个图的输出就为:a: b c d e f gb: c dc: dd:e: f gf: gg:然后,还可以有后续的问题:如果有环,如何判断并输出环?如果这些项目有可能有一些外部的依赖,请改变你的算法以适合这种情况。好,面试到此结束。下面是个扩展题,没在工作中做到,但后来想了下,觉得挺有意思:为了提高编译速度,现在需要找出那些可以并行编译的项目 阅读全文
posted @ 2012-12-07 20:45 lzprgmr 阅读(685) 评论(0) 推荐(0) 编辑
摘要: 这里说的Bundle,是software library范畴的,我把它定义为: 一系列版本兼容的软件库。对于比较小的项目,用的library不多,升级不勤快,这不是个问题,但是对于大型项目,bundle是非常有用的 - 当然,这需要build system的支持。(但加一个这样的功能蛮简单的)bundle的格式大概为一个library=version的列表:boost = 1.50qt = 4.8.3opencv = 2.4.2意思是我把这几个lirary打成一个包,经测试(例子是假设的)发现这几个版本的library是可以在一起工作的 - 也就是说兼容的。bundle的使用就是用户不需要去烦 阅读全文
posted @ 2012-12-07 20:23 lzprgmr 阅读(523) 评论(1) 推荐(0) 编辑
摘要: 觉得有必要记录一下这类问题,都打个[design decision]的标签吧。目前项目中遇到这么个问题:我们build system的用户,需要为他的每个项目提供一个文件,用来描述该项目产生的libary,以及依赖的其他项目。 这个文件很重要,需要在install的时候与最终产生的库文件放在一起,以便被其他项目使用时访问,从而把整个依赖链串起来。 已知该文件总是放在一个固定的位置,之后gmake install时会被安装到一个固定的位置。好,问题来了,既然文件在哪里,要被安装到哪里都是已知的,是不是build system可以自动把这步包含进来,无须用户做任何事,从而提供了方便?我一开始的想法 阅读全文
posted @ 2012-12-07 20:21 lzprgmr 阅读(337) 评论(0) 推荐(0) 编辑
摘要: 当然,这个在这里谈的很多了, 但这里只是说说我们这边用的几种模式, 主要针对发布比较频繁发布的情况,比如两周一次,一个月一次之类的。【一、major.minor】比如1.0, 1.2, 2.5, 3.0等等。 major是主要版本号,major相同,minor不同的版本,是后相兼容的 - 也就是说不会有schema change(如果读文件的话),也不会有breaking api(如果暴露api的话)。当然,你觉得一个major不够用,完全可以扩展为major.major.minor, 如果你在乎后向兼容,这个的确蛮好用的。major.minor的问题在于如何比较两个版本哪个更新:比如:5.8 阅读全文
posted @ 2012-12-07 20:17 lzprgmr 阅读(427) 评论(0) 推荐(0) 编辑

黄将军