引用:

原帖由 离神最近的人 于 2010-11-6 00:43 发表
codelite，codeblock还是差很远，用它来管理工程只比makefile好点，事实上很多时候都是自己写makefile然后用自定义编译。用过的IDE里面没有比MSVC更好用的了，再加上现在express已经免费（当然需要感谢GCC它们）

...

真正的大型工程不会只用Makefile，丫就是个半成品，通常我们会加入大量shell脚本辅助，更常见的是直接用cmake来自动化构建Makefile

linux下，没有多少人习惯使用IDE这种东西

引用:

原帖由 xphi 于 2010-11-5 23:31 发表


ubuntu显卡驱动能搞定很大程度上是现在就两家显卡厂，而且主流还在用的显卡就那几个系列。相比几乎已经标准话显卡和声卡，各种杂七杂八的扩展卡，Raid卡，在Linux下面装驱动简直就是要死人。

你把intel搁哪儿去了？

各种冷门外设不是说装驱动要死人，而是厂家根本没发布驱动。能跑的驱动，大多是直接集成在标准内核里的（显卡驱动这种反而是特殊的），要么直接编译进二进制内核要么是作为模块放在文件系统里以udev的规则动态加载

引用:

原帖由 xphi 于 2010-11-6 02:20 发表 开源是我所想到的一个方面，纯粹从安装方式优劣来说的话，Debian包确实不应该是Linux值得骄傲的地方，微软实际上屡次三番的出Install的 SDK试图统一，不过Windows下可选的Install工具太多导致现在也没有统一起来。我还是觉得只有小众而没有历史包袱才敢一刀切的统一安装工具，要是微软哪天也说大家都把软件放到我的更新服务器上吧，多半比TX这次还要被骂得惨，多么严重的“劫持用户”啊，多么严重的“垄断”啊。

历史包袱这个词用得好，我来告诉你为什么微软根本不可能整出rpm和deb这样的包管理系统，因为从一开始windows或者说dos就没有遵循FHS标准，正是这个历史遗留问题造成了今天几乎每个人的windows系统的目录结构都不相同，在这样的环境下，你让包管理器怎么去装软件？所有软件全部扔c盘program files里吗？几兆十几兆的小软件也就算了，百兆至数G数十G的软件也全扔c盘？那用户非跟你拼命不可。windows那操蛋的目录结构也致使了windows本身不能把用户本身的配置信息从系统盘隔离开来，当然这是题外话了

另外，虽然ubuntu的老板财大气粗，但是全球那么多源服务器可并不都是他出钱整的，任何一个人用台pc机装个ubuntu开个apache就能搭建源服务器，所需操作包括安装apache不足5条命令。可以是官方源镜像，也可以是自己维护的ppa，软件公司可以有自己的ppa，比如opera这类非开源的软件，供用户加源条目以实现自动维护更新

注意源是需要key认证的，杜绝了非法源服务器捣乱，如果你想问如何杜绝，说明你已经被windows下一些习以为常的不安全习惯蒙蔽了双眼，呵呵

引用:

Linux死忠当然都用VI和Emacs，但是我仍然宁愿用有可以加速工作的代码完成工具和重构功能的IDE，如果能够支持多显示器更加好，如果我哪天能啃完Emacs的无数手册，记住Emacs无数快捷键，学会了Emacs的无穷强脚本语言，说不定我也会喜欢Emacs，不过现在看来遥遥无期。
make永远都是核心，其他都是辅助，不是make半成品，而是make的基本设计思想就只是制定规则依赖，具体每条规则怎么操作当然要写脚本。

我前面就说了，slickedit可以设置成vim和emacs style，也就是兼容它们所有快捷键
至于Makefile，其实我一般是不和没有将Makefile拼写正确的人讨论关于它的话题的。Makefile为啥是半成品？我问个问题，你如何实现当修改一个头文件后重新编译时，只选择性地编译那些与该头文件有关的源码文件，注意这不仅涉及到单纯地将头文件时间戳与包含该文件的源码文件的比较，还涉及到头文件内部的包含关系。你可以看看官方GNUmake手册给出的方案。如果你不知道我在说什么，那我可以问个基础问题，Makefile是如何处理复杂的源码目录树生成最终的目标文件的？

引用:

Intel我确实搞漏了，因为基本没有听说还要要鼓捣Intel的显卡驱动。不过鼓捣驱动基本不是因为厂家没有发布，要真没有发布驱动我就直接换硬件了，鼓捣驱动干啥。Linux驱动最烦躁的在于编译，无数的Linux发行版，每种发行版的无数版本，各种不同的gcc版本，glibc版本……。乱七八糟的版本依赖之烦躁，之恶心，加上各种冷门驱动本身开发不够好，常常依赖特定编译环境，搞死人。

驱动的问题，你算撞我枪口上了。。。

很多驱动不是官方发布的，而是黑客们根据手册自己写的，只要愿意开源，你就可以提交给kernel.org，进入mainline，这样kernel.org发布的标准内核里就会有这样的驱动。厂商自己发布，不提交，绝大部分原因是不想开源，打闷包，没关系，你完全可以打包发布deb包或rpm包，甚至直接进ubuntu官方源服务器，再被全球的爱好者架设的源服务器镜像。gcc版本，我从来是用最新的稳定版本，所有有活力的发行版都是如此，作为一个程序员，这是起码的要求，这也是为什么程序员不用rhel，centos等发行版的原因

另外，驱动不依赖你的编译环境，不使用glibc，它依赖的是你当前kernel的源码树。所以你觉得搞死人，要么是你的驱动太古老没跟着kernel的api维护（不进mainline你就得自己维护），要么是你的kernel太老

引用:

原帖由 xphi 于 2010-11-6 14:04 发表
有DOS的时候还没有FHS，那时的DOS没有理由去借鉴Unix的文件系统，所以不要乱用“一开始……就”这样的句式。我也没有说Windows的安装方式好过rpm或者deb，我只是说源服务器这种做法没什么值得夸耀的。

拼错Makefi ...

嗯，dos所采用的文件系统和分区挂载的方式，已经决定了不可能出现一种标准去统一规范了，因为分区和目录的关系被颠倒了过来。unix和linux之所以能够遵循FHS标准，和分区挂载的方式有很大关系

生成.d文件的原因就是因为Makefile是半成品，没有提供相关机制，只好用这种愚蠢至极的方法曲线救国，要知道在你在磁盘驱动器上频繁创建和删除如此大规模的小文件是一件十分费时费力不讨好的事情

头文件里包含的内容不需要修改吗？真的不需要？我举个例子，你的项目是多平台的，这时你需要编译面向另一个平台的目标文件，于是执行Makefile的某个标签创建了面向该平台的一整套头文件的软链接，你觉得你头文件修改了没？不同平台soc的寄存器完全不同，这些信息都在头文件里，这些头文件会被粘贴到源码文件里，头文件变了自然要重新编译。“仅仅依赖时间戳就可以独立编译修改后的实现部分而不用考虑其他使用了该接口的代码”，这没有什么神奇的地方，编译是以文件为单位的，没有改过内容的源码文件当然不需要重编，只需要重新链接就可以了

“必须在某版本的GCC下编译”，知道我为什么说作为一个程序员，使用最新编译器和库是最起码的要求吗？程序员发布的产品必须保证兼容性，必须在某版本的GCC下编译的东西根本是不合格的，gcc的参数一直在变，但是基本都做到了向下兼容，如果程序员自己都在用老版本的编译环境，自然会在参数选择上出现这种操蛋问题

同样的，如果你拿到的驱动也是只对应老版本的kernel，那么这份驱动同样是缺乏维护的、不合格的，合格的驱动应该打包成deb包或rpm包，双击安装或进入官方源服务器维护。如果你不幸碰上这样的东西，很简单，你下个老版本的kernel，编译运行即可，不要跟我说你分不清什么事kernel什么是rootfs

引用:

原帖由 xphi 于 2010-11-6 14:04 发表
常常要考虑“修改一个头文件后重新编译时，只选择性地编译那些与该头文件有关的源码文件”这样的问题，说明代码组织或者结构设计多半有问题

说实话这个实在是真不能接受了。。。我觉得我被侮辱了，随便找个像样的项目，开关某些宏，这些操作都是改在头文件里的啊

引用:

原帖由 xphi 于 2010-11-6 19:44 发表


开关某些宏恰好应该是放在Makefile里面，在不同的规则下由gcc的开关传进去的，过了调试期后，需要发布版的时候才实际写进头文件里面去，每次调试make的时候都要修改头文件，等待缓慢的编译无数源文件，那还要头文 ...

我明白了，你并不发布源码，只发布二进制文件，用户看不见源码，所以用户不会修改头文件

你把宏作为编译参数传入源码比用头文件传入到底高明在什么地方呢？连编译参数都修改的话，难道还不用重新编译？我实在是困惑。宏是在预处理阶段就处理掉的，远远早于编译流程

不是所有的项目都有所谓的配置文件的，因为不是所有的程序都是跑在操作系统下的

说来说去还是鸡同鸭讲啊，你没有接触过裸板程序

我再举个例子好了，就拿debug开关来说，假设我们现在只调试某一个模块，所以只需要打开这个模块的debug开关就可以了，这当然是代码中该模块设的宏。你说这种情况下，我是改编译参数把整个工程重编一遍好呢还是在该模块的主头文件里打开debug宏好呢？当然，你可以说，我们计划调试一个模块是属于预先的设计和计划，重编一次无所谓

另外，我说的开关宏，当然指的是开关代码中的某些功能，我发现你完全误会了。一个正常人是不会把诸如mac地址啊ip地址啊开机画面存储地址啊写死在代码里的，这代码当然也包括头文件

其实拿linux kernel作为例子就更好说了，比如说spin_lock这个宏，在单核非抢占的情况下，丫就是一个空宏，只有在多核或开抢占的情况下spin_lock才是有意义的。那么这个宏的内容本身就是被宏所选择的，而且这个选择权也是要交到用户手里，由用户的配置来决定的。所以，在用户对内核不同的配置情况下，spin_lock的内容会被修改，并导致所有使用过该宏的源码文件被修改，从而被重编，这只能靠头文件来实现

Makefile处理头文件的时候，先是利用gcc的参数导出各个源文件的依赖关系，其中包括头文件，但不包括.d文件本身，然后用一个sed去修改.d文件，把.d文件本身添加到目标项中，修改后的.d文件再被include到Makefile中。就是这样一个过程，这是GNUmake官方给出的解决方案，我对此嗤之以鼻

你可以看一下是哪个进程吃的内存，直接点掉

linux下显示的内存占用是符合用户习惯的，否则其显示意义就不存在了。2G内存吃满应该是内存泄露的问题