posts - 116,  comments - 123,  trackbacks - 0
 
似乎真得不能解决了,说是还有一点点的可能,哎,解决办法就是落户到杭州,呵呵,难道真的是天意吗?
posted @ 2006-06-15 16:08 yuhen 阅读(187) | 评论 (0)编辑 收藏
       昨天想了很多,不管怎么样都应该给琦说说吧,可是我该怎么开口呢?最晚打了两个电话,都没有开口说这事,她还安慰我说:这里的房子并不贵,不要有太大压力;我们出去玩可以去便宜点的地方,我我我......
      为什么会这样子,难道真的当她把它的一切都适应了之后,我们又拂袖而去,真的不公平,我真的成了大恶人了,天哪?我该怎么办?
posted @ 2006-06-15 09:20 yuhen 阅读(172) | 评论 (0)编辑 收藏

      下午开了两个多小时的会,还挺兴奋,马上就要融入这个小组了,然而当我回来的时候,发现nigel给我msn上留了一句话:“你的户口怎么样?”当时心就扑通一下......
      是的,我的户口关系到我们两人的未来以及在北京的去留问题,并不是我一人的问题。我立刻去找了同事,然后就拨了电话,其实结果似乎早已确定,一两句寒暄就很是受不了了,直奔主题把,还说下周还有些机会,怎么这么假呢?这样一个大公司,在这个问题上遮遮掩掩,还不到最后不告诉我们,真不知道是为什么?暂且相信下周会有一个好的解决方法吧,可是真地会有吗?后来知道了,所有北京院校的同事已经被告知解决,双外的同事大部分没有解决,只有那几个已经解决,真得很让人郁闷!我们才刚刚看到社会是多么的残酷,我们是多么的无助,或许这仅仅是个开始把,真的没想到,就这样发生了,为什么我们会这么惨?难道这也是我所应该承受的吗?难道这也是奥运会给我带来的吗?我讨厌北京,我讨厌社会中的人和事!

posted @ 2006-06-14 19:38 yuhen 阅读(179) | 评论 (0)编辑 收藏
      昨天晚上3:00爬起来,看了巴西和克罗地亚的比赛,现在困得不得了!巴西真强,完全没有感觉到看了2个小时,就感觉的一会会,当然克罗地亚也不错的,还是挺好看的,虽然只进了一个球,早上4点天就开始蒙蒙亮了,我睡觉的时候太阳已然出来了,呵呵。刚才定了盒饭,打算吃了就睡觉,下午还要开会呢,我们新人开始做presentation了,要好好听了,呵呵!
posted @ 2006-06-14 10:35 yuhen 阅读(132) | 评论 (2)编辑 收藏


      世界杯开始了,现在的体力都不行了,根本不能晚上熬夜看球,老了,呵呵!不过还是在看,毕竟四年一回阿。可是令人很不爽的是我们的房子,不在于它是怎么怎么得不好,坏在什么地方,而在于它什么时候能修好,房东和楼下闹矛盾,把我们加在中间,没有水是多么的痛苦,关键在于他们根本没有找一个解决的办法,哎,刚来北京就遇到这种事情,不爽,今天晚上还是去别的宿舍在打点水吧。上周听说我们的户口很难办,这也是我一直担心的事情,真是流年不利阿,幸好的承受能力是无限的,我觉得任何事情都是有解决的办法的,事情的发生总有其必然性,我们可以改变过程,却不能改变结果,既然过程早已发生,就不用为一种既定的结果而后悔和悲伤,正所谓车到山前必有路,路漫漫其修远兮,我将上下而顺其自然!

posted @ 2006-06-12 18:17 yuhen 阅读(137) | 评论 (0)编辑 收藏

        无论是在Linux还是在Unix环境中,make都是一个非常重要的编译命令。不管是自己进行项目开发还是安装应用软件,我们都经常要用到make或make install。利用make工具,我们可以将大型的开发项目分解成为多个更易于管理的模块,对于一个包括几百个源文件的应用程序,使用make和makefile工具就可以简洁明快地理顺各个源文件之间纷繁复杂的相互关系。而且如此多的源文件,如果每次都要键入gcc命令进行编译的话,那对程序员来说简直就是一场灾难。而make工具则可自动完成编译工作,并且可以只对程序员在上次编译后修改过的部分进行编译。因此,有效的利用make和makefile工具可以大大提高项目开发的效率。同时掌握make和makefile之后,您也不会再面对着Linux下的应用软件手足无措了。
  但令人遗憾的是,在许多讲述Linux应用的书籍上都没有详细介绍这个功能强大但又非常复杂的编译工具。在这里我就向大家详细介绍一下make及其描述文件makefile。

Makefile文件

  Make工具最主要也是最基本的功能就是通过makefile文件来描述源程序之间的相互关系并自动维护编译工作。而makefile 文件需要按照某种语法进行编写,文件中需要说明如何编译各个源文件并连接生成可执行文件,并要求定义源文件之间的依赖关系。makefile 文件是许多编译器--包括 Windows NT 下的编译器--维护编译信息的常用方法,只是在集成开发环境中,用户通过友好的界面修改 makefile 文件而已。
  在 UNIX 系统中,习惯使用 Makefile 作为 makefile 文件。如果要使用其他文件作为 makefile,则可利用类似下面的 make 命令选项指定 makefile 文件:
  $ make -f Makefile.debug
  例如,一个名为prog的程序由三个C源文件filea.c、fileb.c和filec.c以及库文件LS编译生成,这三个文件还分别包含自己的头文件a.h 、b.h和c.h。通常情况下,C编译器将会输出三个目标文件filea.o、fileb.o和filec.o。假设filea.c和fileb.c都要声明用到一个名为defs的文件,但filec.c不用。即在filea.c和fileb.c里都有这样的声明:
  #include "defs"
  那么下面的文档就描述了这些文件之间的相互联系:
  ---------------------------------------------------------
   #It is a example for describing makefile
   prog : filea.o fileb.o filec.o
   cc filea.o fileb.o filec.o -LS -o prog
   filea.o : filea.c a.h defs
   cc -c filea.c
   fileb.o : fileb.c b.h defs
   cc -c fileb.c
   filec.o : filec.c c.h
   cc -c filec.c
  ----------------------------------------------------------
  这个描述文档就是一个简单的makefile文件。
  从上面的例子注意到,第一个字符为 # 的行为注释行。第一个非注释行指定prog由三个目标文件filea.o、fileb.o和filec.o链接生成。第三行描述了如何从prog所依赖的文件建立可执行文件。接下来的4、6、8行分别指定三个目标文件,以及它们所依赖的.c和.h文件以及defs文件。而5、7、9行则指定了如何从目标所依赖的文件建立目标。
  当filea.c或a.h文件在编译之后又被修改,则 make 工具可自动重新编译filea.o,如果在前后两次编译之间,filea.C 和a.h 均没有被修改,而且 test.o 还存在的话,就没有必要重新编译。这种依赖关系在多源文件的程序编译中尤其重要。通过这种依赖关系的定义,make 工具可避免许多不必要的编译工作。当然,利用 Shell 脚本也可以达到自动编译的效果,但是,Shell 脚本将全部编译任何源文件,包括哪些不必要重新编译的源文件,而 make 工具则可根据目标上一次编译的时间和目标所依赖的源文件的更新时间而自动判断应当编译哪个源文件。
Makefile文件作为一种描述文档一般需要包含以下内容:
  ◆ 宏定义
  ◆ 源文件之间的相互依赖关系
  ◆ 可执行的命令
  Makefile中允许使用简单的宏指代源文件及其相关编译信息,在Linux中也称宏为变量。在引用宏时只需在变量前加$符号,但值得注意的是,如果变量名的长度超过一个字符,在引用时就必须加圆括号()。
  下面都是有效的宏引用:
  $(CFLAGS)
  $2
  $Z
  $(Z)
  其中最后两个引用是完全一致的。
  需要注意的是一些宏的预定义变量,在Unix系统中,$*、$@、$?和$<四个特殊宏的值在执行命令的过程中会发生相应的变化,而在GNU make中则定义了更多的预定义变量。关于预定义变量的详细内容,
  宏定义的使用可以使我们脱离那些冗长乏味的编译选项,为编写makefile文件带来很大的方便。
  ---------------------------------------------------------
   # Define a macro for the object files
   OBJECTS= filea.o fileb.o filec.o

   # Define a macro for the library file
   LIBES= -LS

   # use macros rewrite makefile
   prog: $(OBJECTS)
   cc $(OBJECTS) $(LIBES) -o prog
   ……
  ---------------------------------------------------------
  此时如果执行不带参数的make命令,将连接三个目标文件和库文件LS;但是如果在make命令后带有新的宏定义:
  make "LIBES= -LL -LS"
则命令行后面的宏定义将覆盖makefile文件中的宏定义。若LL也是库文件,此时make命令将连接三个目标文件以及两个库文件LS和LL。
  在Unix系统中没有对常量NULL作出明确的定义,因此我们要定义NULL字符串时要使用下述宏定义:
  STRINGNAME=

Make命令

  在make命令后不仅可以出现宏定义,还可以跟其他命令行参数,这些参数指定了需要编译的目标文件。其标准形式为:
  target1 [target2 …]:[:][dependent1 …][;commands][#…]
  [(tab) commands][#…]
  方括号中间的部分表示可选项。Targets和dependents当中可以包含字符、数字、句点和"/"符号。除了引用,commands中不能含有"#",也不允许换行。
  在通常的情况下命令行参数中只含有一个":",此时command序列通常和makefile文件中某些定义文件间依赖关系的描述行有关。如果与目标相关连的那些描述行指定了相关的command序列,那么就执行这些相关的command命令,即使在分号和(tab)后面的aommand字段甚至有可能是NULL。如果那些与目标相关连的行没有指定command,那么将调用系统默认的目标文件生成规则。
  如果命令行参数中含有两个冒号"::",则此时的command序列也许会和makefile中所有描述文件依赖关系的行有关。此时将执行那些与目标相关连的描述行所指向的相关命令。同时还将执行build-in规则。
  如果在执行command命令时返回了一个非"0"的出错信号,例如makefile文件中出现了错误的目标文件名或者出现了以连字符打头的命令字符串,make操作一般会就此终止,但如果make后带有"-i"参数,则make将忽略此类出错信号。
  Make命本身可带有四种参数:标志、宏定义、描述文件名和目标文件名。其标准形式为:
  Make [flags] [macro definitions] [targets]
  Unix系统下标志位flags选项及其含义为:
  -f file  指定file文件为描述文件,如果file参数为"-"符,那么描述文件指向标准输入。如果没有"-f"参数,则系统将默认当前目录下名为makefile或者名为Makefile的文件为描述文件。在Linux中, GNU make 工具在当前工作目录中按照GNUmakefile、makefile、Makefile的顺序搜索 makefile文件。
  -i   忽略命令执行返回的出错信息。
  -s   沉默模式,在执行之前不输出相应的命令行信息。
  -r   禁止使用build-in规则。
  -n   非执行模式,输出所有执行命令,但并不执行。
  -t   更新目标文件。
  -q   make操作将根据目标文件是否已经更新返回"0"或非"0"的状态信息。
  -p   输出所有宏定义和目标文件描述。
  -d   Debug模式,输出有关文件和检测时间的详细信息。
  Linux下make标志位的常用选项与Unix系统中稍有不同,下面我们只列出了不同部分:
  -c dir   在读取 makefile 之前改变到指定的目录dir。
  -I dir   当包含其他 makefile文件时,利用该选项指定搜索目录。
  -h   help文挡,显示所有的make选项。
  -w   在处理 makefile 之前和之后,都显示工作目录。
  通过命令行参数中的target ,可指定make要编译的目标,并且允许同时定义编译多个目标,操作时按照从左向右的顺序依次编译target选项中指定的目标文件。如果命令行中没有指定目标,则系统默认target指向描述文件中第一个目标文件。
  通常,makefile 中还定义有 clean 目标,可用来清除编译过程中的中间文件,例如:
  clean:
  rm -f *.o
  运行 make clean 时,将执行 rm -f *.o 命令,最终删除所有编译过程中产生的所有中间文件。

隐含规则

  在make 工具中包含有一些内置的或隐含的规则,这些规则定义了如何从不同的依赖文件建立特定类型的目标。Unix系统通常支持一种基于文件扩展名即文件名后缀的隐含规则。这种后缀规则定义了如何将一个具有特定文件名后缀的文件(例如.c文件),转换成为具有另一种文件名后缀的文件(例如.o文件):
  .c:.o
  $(CC) $(CFLAGS) $(CPPFLAGS) -c -o $@ $<
  系统中默认的常用文件扩展名及其含义为:
  .o  目标文件
  .c  C源文件
  .f  FORTRAN源文件
  .s  汇编源文件
  .y  Yacc-C源语法
  .l  Lex源语法
  在早期的Unix系统系统中还支持Yacc-C源语法和Lex源语法。在编译过程中,系统会首先在makefile文件中寻找与目标文件相关的.C文件,如果还有与之相依赖的.y和.l文件,则首先将其转换为.c文件后再编译生成相应的.o文件;如果没有与目标相关的.c文件而只有相关的.y文件,则系统将直接编译.y文件。
  而GNU make 除了支持后缀规则外还支持另一种类型的隐含规则--模式规则。这种规则更加通用,因为可以利用模式规则定义更加复杂的依赖. 

posted @ 2006-06-08 15:16 yuhen 阅读(2970) | 评论 (1)编辑 收藏
在New Post的时候,当我是用中文输入法,屏幕就闪个不停,该怎么处理,我是用html格式会好一些,但是还是有闪动,搞得人眼睛受不了,大家都是怎么做的啊?
我用的是微软输入法,没有试过其它的,如果直接输入英文就没有问题!望大家赐教!
posted @ 2006-06-07 17:42 yuhen 阅读(1674) | 评论 (4)编辑 收藏
昨天想了很多,又冒出几个想法,今天觉得好多了,只是国图传来的不是好消息,刚才又弄了一个!
老大回来了,照例我们去老地方享用了一番,大家都是非常开心的。还是能够感觉到这个新环境的人文色彩的,不太像网上评价的那样,并不是所有的台资都抠门的,反之,有些国内的一些企业却做得很不好,就像最近网上谈得很多的纪念胡新宇君,过劳死都成了现在很敏感的话题,cctv2也看到报道了,说了一下10个过劳死的表现方面。公司在追求自己利益最大化的同时,忽略了为公司创造利益的生力军,不能说不是一个悲哀,在这种情况下,仍然的将晚上加班时间定格于9:45,真的值得社会来报道一下了,我在其公司的网页没有看到丝毫这一方面的新闻和报道,仅仅是又一个什么大单,又一个什么项目,难道国人的生活质量就一点都不重要吗?难道就是因为我们人多,我们扩招了,有的是人来做这份工作,这的确是被一种文化所制约,一种带有军事色彩的文化,不知道什么时候才是个头?我为她而担心!
GW就要被收购了,不知道会不会有些变化,会不会进行整合和出售,但愿会产生一些积极的影响,至少是一点变化吧,那也是一点希望,一丝安慰吧。
posted @ 2006-06-07 17:35 yuhen 阅读(110) | 评论 (0)编辑 收藏
今天是2006.06.06,有些人说是百年不遇的好日子,前两天我也觉得是,而且还很是期盼;网上又有人说西方人认为这个日子很不好,还听同事说的确不是很好,我也分辨不了,反正借着昨天的余辉,有些郁闷!
posted @ 2006-06-06 19:24 yuhen 阅读(284) | 评论 (2)编辑 收藏

呵呵,于昨天看完了要求的前几章,本来以为都看不懂呢,发现还可以了,呵呵!今天又看了dwg的一部分,更加明白了其中的一些东西,好像理清思路了也挺不错的,不过还是有一些东西不太明白,好像概念特别的confused,不过今天还是比较有成果的,搞得我下午tea break 都去晚了点,但是却扫清了战场了,哈哈!忽闻女友须臾前来,心中大喜,甚于work之悦,亏于h3之智,实乃大幸。良久,茫然,欣然,跃然,恍然,取公司之利,顾鲁能之meal,然也。

posted @ 2006-06-02 17:54 yuhen 阅读(281) | 评论 (0)编辑 收藏
仅列出标题
共12页: First 4 5 6 7 8 9 10 11 12 
<2024年4月>
31123456
78910111213
14151617181920
21222324252627
2829301234
567891011

Believe in who you are,
you are a shinning star!

常用链接

留言簿(16)

随笔分类(122)

随笔档案(116)

文章分类(2)

文章档案(2)

相册

BLOG

Study

Testing

最新随笔

搜索

  •  

积分与排名

  • 积分 - 120030
  • 排名 - 54

最新随笔

最新评论

阅读排行榜

评论排行榜