背景情况: 想要用某open source package (let's say A) 写一个实验程序。A的作者应要求作了部分修改，但我看了代码之后还想修改界面，发email询问作者有些得到回复，有些关于安装的没有。看了想把相关的代码独立出来做成一个package, 然后慢慢修改和添加。可是在自己的cygwin上连安装都有问题。当时有最dirty的solution就是，把它装到系服务器里面，修改-重装-修改...因为不知为什么这个软件能在lab服务器上安装 (在我自己的cygwin上却有问题)。我不想用dirty solution, 因为觉得会减慢以后的工作速度，所以就想在自己的机器上学习怎么编译这些软件，为以后自己做package 做准备了。

面临第一个问题是，怎么不用A package 提供的 configure-make 系统自己编译可执行文件。想不到从头到尾用了超过十天，如果细心点其实是用不着这么长的。记录下回想起来的过程，算是教训(今天是2007年1月1日，可以大致往回倒推事情发生的日期):

1. 一个个看A package 里面的文件，看看哪些是重要文件之类的。发现它要用到另外两个package C, D. 又看了D的说明书，知道这是一个什么样的软件和为什么要用它。这个kick around 的过程用了大概两天。
2. 想看package A 的 Makefile，就可以知道package是怎么编译的。当时还不会用写Makefile, 就从网上找beginner tutorial 看了。一天。
3. 发现还是看不懂package A提供的Makefile, 可是还是找不到头绪，就去问小虎了。小虎告诉我那些Makefile 是用./configure程序生成的，几百上千行的当然难看了，然后尝试帮我解决这个问题，发现 package A还用了一个package B 来跟D 连接。然后在我的cygwin上用现成的静态库编译成功，还告诉我静态库的构成和制作。我把解决问题的方法记录下来。因为觉得已经知道足够的原理了，所以记录得比较抽象，后来为此尝了苦头。
4. 第二天拿着记录从源代码开始制作静态库，然后尝试把他们连接，可是不成功。觉得可能是静态库没做的跟Makefile生成的静态库一样，所以失败。就问小虎借了Automake-autoconf-libtool 的书开始看，心想不能直接看Makefile, 好歹看生成 Makefile的文件也能知道怎么回事。这一开始看就看了五天。期间发生的事大概是这类: 发现一教材读不懂，换一更基础的看了然后再回过头来；发现一教材太老，重找新的 ... 用了五天后知道了Automake, M4, Bash script 的基础知识和一些用法。但重新回去看package A 的 Makefile.am 和 ./configure.ac 文件，却没发现以前的做法有什么问题。心想再读下去没个头，就停止了。期间XieFeng同学告诉我在服务器上编译成功，我觉得服务器上跟cygwin可能有差别，就没在意。五天。
5. 决心用最笨的方法了。就是系统地测试各package，找出问题在哪里，慢慢把测试好的各部分连接。这个过程进展缓慢，有一个小问题stuck了我一天，最后用strace (网友教的) 发现这是cygwin 的bug ... 最后发现是package C 不对。C生成了两个静态库，一个包含另一个 (我不知道C为什么要生成两个静态库)，我用了被包含的那个，结果可想而知。三天。

总结: 前后用了十二天，但如果第四天的纪录不那么抽象，问题就解决了。在第九天如果仔细核对XieFeng给我发来的g++ 命令，也能提早一些发现问题。客观上后面八天的读书和测试令我获益良多，但对解决当初的问题却并非必要。出现这种情况跟我近两年读书看论文甚至看yy小说养成的习惯有关系:
i) 拿到东西就从头往下读, 有时会读到偏离本来的目标，虽然读到一定时候都会回过头来审视一下确定是不是还跟目标逼近，但还是不怎么有效率。
ii) 有一些好奇心，对某些内容知道偏离了目标还是继续读，心想已经读到这里了不如多读一些。
    这种习惯也会带来好处，只是这件事它让我吃足了苦头，所以记录下来警惕一下。