本节的题目很可能让你疑惑:设置?有什么必须要设置的?谁来完成呢?好,假设你已经写 好了一个包含了Makefile 的程序。然后你想要发布它,但这些编译过的二进制代码在 你的系统上或是与你的系统兼容的机子上不能运行。为了支持其他平台,例如另外的Unix 系统或是如Alpha机、RISC机,你就必须重新编译这个程序。最简单的办法就是把源文件 包拷贝到目标机器并再次运行make。但要是目标机器使用的是另一种Compiler 编译命令或者在另外某方面在建立你的二进制时遇到了问题该怎么办呢?更不要说更困难的 情况了,例如你的程序和文档--例如KDE 的安装路径,不能在一台机子上被安装到 opt/kde/,而在另一太机子上被安装到usr/local/kde/下。在这种情况下,你就 必须每次都重写Makefile 文件,以保证你的产品的正确编译和安装。 幸运的是,GNU工具甚至还提供了比make还强大的工具--常用的automake 自动创建和autoconf 自动设置包。带auto的词听来总是很舒服,就好象是关于应用 程序设计的东西可以又快又轻易的完成,实际正是这样。
自动创建的目的一般是从你必须为你的项目书写的文件Makefile.am 创建一 个所谓的Makefile.in 文件。Makefile.am 文件由宏组成,它们 可被翻译并可降低make的复杂度,所以Makefile.am 文件可以比最终的 Makefile 更安全、更快速的编写完成。
那么,是什么最终为我创建了Makefile 文件呢?是autoconf 自动配置。自 动配置要求项目拥有几个宏文件。那是那些由automake 和一个叫做 configure.in的文件创建的Makefile.in 的文件,也包括宏。因此, Makefile.am 和.in's都包含了宏,它决定了创建软件的方式:源文件的编译方 式,哪些文件属于这个软件包,以及最终的二进制或?进制文件在创建后用的名字。在另一 方面,Configure.in则包含的宏则决定最终的配置--外壳在配置被执行的系统上将做 何种检测。那可以是,例如Compiler command命令最终二进制将被连接所需的库,项 目所需的包含文件及其位置。
例如,你想写一个KDE 应用。在你编写完资源代码以后,你想把你的程序发布到 用户社区,而每一个用户都必须在自己的机子上编译这个二进制资源。那么你就需要写一个 包含编译应用所需的宏的Configure.in文件。不论Qt库是否安装,那一个宏最 终在系统上展开成一个check,检测Qt头文件,KDE-libraries 和头部等等。
总结: 为创建一个在不同的Unix-OS和其他机子上都可运行的GNU-编译应用, 你需要这样做:
为你的应用写下代码资源
为每个子目录编写Makefile.am ,包括你的项目的主要项目目录。
编写放于主项目目录的configure.in文件,包含说明系统要求的宏。
运行 automake
运行 autoconf
现在主要的工作都已完成,"自动创建"建立了Makefile.in ,autoconf 启 动了configure.in并生成一个可执行的,称为configure的外壳脚本。你所有接下来 必须完成的事就是用.configure/执行它,脚本会运行你选中的checks。最后会生成 一个Makefile s,允许"创建"的最终执行。它会运行所有的Makefile s文件, 然后你就完成了。
看起来为写一个小程序,花费的人力可不少,该学的也不少,特别是如何编写正确的 宏。但仅仅是你提供在几乎所有的Unix系统上都可运行的应用这一事实本身,迟早也 是值得你的这些努力的。最后,你只为你的应用做一次这样的工作,万一你的项目的文件有 所增加,你只需往宏里加入文件就可以了。
现在,Kdevelop究竟有多支持这种类型的应用程序开发,而对程序员来说这究竟又有 多复杂呢?这里有个好消息是你甚至无须知道关于宏和scripts,的任何东西。所有细 节问题都已隐藏,使用起来轻松自如。因此由GNU工具都以对用户有好的方式创建应用:
只需根据你的应用的需求选择,用KappWizard 创建你的应用--那可以是一个纯 C++最终应用或某种使用Qt或Qt/KDE 的GUI 库的程序。所有工作自动完成,而 且你的项目已经包含由GDU工具和配置脚本的自动执行创建的Makefile s。
就是这样--你准备扩展你的项目资源,可以通过增加classes 类,对话,翻译或 文档,这些都是自动化的。只需集中精力去做开发者的真正工作,那是为最终你想建立的应 用程序编制功能的。在大多数情况下,在使用Kdevelop时,你很可能都不会和 <Makefile s打交道。