$ mount --change-cygdrive-prefix /
$ ls /c
AUTOEXEC.BAT            Home            Program Files               hp
BOOT.INI                I386            RECYCLER                    ntldr
CD                      IO.SYS          System Volume Information   pagefile.sys
CONFIG.SYS              MSDOS.SYS       Temp                        tmp
C_DILLA                 NTDETECT.COM    WINDOWS                     usr
Documents and Settings  PERSIST         WUTemp                      work
一旦进行了此更改，我们之前的目录映射将更改为表 7-2 所示的目录映射。
表 7-2 更改的 Cygwin 目录映射
原生 Windows 路径
Cygwin 路径
可选 Cygwin 路径
如果您需要将文件名传递给 Windows 程序，比如 Visual C++ 编译器，您通常可以使用 POSIX 风格的正斜杠传递文件的相对路径。Win32 API 不区分向前斜杠和向后斜杠。不幸的是，一些执行自己的命令行参数解析的实用程序将所有正斜杠视为命令选项。一个这样的工具是 DOS 打印命令;另一个是 net 命令。
如果使用绝对路径，驱动器号语法总是一个问题。尽管 Windows 程序通常可以使用斜杠，但它们完全无法理解 /c 语法。驱动器号必须始终转换回 C:。为了实现这一点和 正/反斜杠 转换，Cygwin 提供了 cygpath 实用程序来在 POSIX 路径和 Windows 路径之间进行转换。
$ cygpath --windows /c/work/src/lib/foo.c
c:\work\src\lib\foo.c
$ cygpath --mixed /c/work/src/lib/foo.c
c:/work/src/lib/foo.c
$ cygpath --mixed --path "/c/work/src:/c/work/include"
c:/work/src;c:/work/include
--windows 选项将命令行上给出的 POSIX 路径转换为 Windows 路径(或者使用适当的参数反过来)。我更喜欢使用 --mixed 选项，它产生一个 Windows 路径，但是使用正斜杠而不是反斜杠(当 Windows 实用程序接受它时)。这在 Cygwin shell 中表现得更好，因为反斜杠是转义字符。cygpath 实用程序有许多选项，其中一些提供了对重要 Windows 路径的可移植访问:
$ cygpath --desktop
/c/Documents and Settings/Owner/Desktop
$ cygpath --homeroot
/c/Documents and Settings
$ cygpath --smprograms
/c/Documents and Settings/Owner/Start Menu/Programs
$ cygpath --sysdir
/c/WINDOWS/SYSTEM32
$ cygpath --windir
/c/WINDOWS
如果你在混合 Windows/Unix 环境中使用 cygpath，你会想要将这些调用包装在一个可移植的函数中:
ifdef COMSPEC
    cygpath-mixed = $(shell cygpath -m "$1")
    cygpath-unix = $(shell cygpath -u "$1")
    drive-letter-to-slash = /$(subst :,,$1)
    cygpath-mixed = $1
    cygpath-unix = $1
    drive-letter-to-slash = $1
endif
如果您需要做的只是将 C: 驱动器号语法映射到 POSIX 形式，那么 drivelletter-to-slash 函数比运行 cygpath 程序更快。
最后，Cygwin 无法隐藏 Windows 的所有怪癖。在 Windows 中无效的文件名在 Cygwin 中也是无效的。因此，诸如 aux.h、com1 和 prn 等名称不能在 POSIX 路径中使用，即使具有扩展名。
有些 Windows 程序的名称与 Unix 程序相同。当然，Windows 程序不接受相同的命令行参数，也不以与 Unix 程序兼容的方式运行。如果您不小心调用了 Windows 版本，通常的结果是非常混乱。最麻烦的似乎是 find、sort、ftp 和 telnet。为了获得最大的可移植性，在 Unix、Windows 和 Cygwin 之间移植时，应该确保提供这些程序的完整路径。
如果您对 Cygwin 非常忠诚，并且不需要使用本机 Windows 支持工具进行构建，那么您可以安全地将 Cygwin /bin 目录放置在 Windows 环境变量路径的前面。这将保证在Windows 版本上访问 Cygwin 工具。
如果您的 makefile 使用的是 Java 工具，请注意 Cygwin 包含的 GNU jar 程序与标准的 Sun jar 文件格式不兼容。因此，Java jdk 的 bin 目录应该放在Path 变量的 Cygwin /bin 目录之前，以避免使用 Cygwin 的 jar 程序。
管理程序和文件
管理程序最常见的方法是为可能更改的程序名或路径使用一个变量。这些变量可以在一个简单的块中定义，如你所见:
MV ?= mv -f
RM ?= rm -f
or in a conditional block:
ifdef COMSPEC
    MV ?= move
    RM ?= del
    MV ?= mv -f
    RM ?= rm -f
endif
如果使用一个简单的块，则可以通过在命令行上重置它们、编辑 makefile 或通过设置环境变量(在本例中，因为我们使用了条件赋值，即 ?=)来更改值。如前所述，测试Windows 平台的一种方法是检查 COMSPEC 变量，所有 Windows 操作系统都使用 COMSPEC 变量。有时候只需要改变路径:
ifdef COMSPEC
    OUTPUT_ROOT := d:
    GCC_HOME := c:/gnu/usr/bin
    OUTPUT_ROOT := $(HOME)
    GCC_HOME := /usr/bin
endif
OUTPUT_DIR := $(OUTPUT_ROOT)/work/binaries
CC := $(GCC_HOME)/gcc
这种风格会产生一个 makefile，在这个 makefile 中，大多数程序都是通过 make 变量调用的。在您习惯之前，这可能会使 makefile 有点难以阅读。但是，变量通常在 makefile 中使用更方便，因为它们可以比程序字面名称短得多，特别是在使用完整路径时。
同样的技术可以用于管理不同的命令选项。例如，内置编译规则包括一个变量 TARGET_ARCH，可以用来设置特定于平台的标志:
ifeq "$(MACHINE)" "hpux-hppa"
    TARGET_ARCH := -mdisable-fpregs
endif
当定义你自己的程序变量时，你可能需要使用类似的方法:
MV := mv $(MV_FLAGS)
ifeq "$(MACHINE)" "solaris-sparc"
    MV_FLAGS := -f
endif
如果您要移植到许多平台，将 ifdef 部分链接起来可能会变得丑陋和难以维护。与其使用 ifdef，不如将每个特定于平台的变量集放在其名称包含一个平台指示符的文件中。例如，如果你通过 uname 参数指定一个平台，你可以选择适当的 make include 文件，如下所示:
MACHINE := $(shell uname -smo | sed 's/ /-/g')
include $(MACHINE)-defines.mk
带有空格的文件名给 make 带来了一个特别恼人的问题。在解析过程中使用空格分隔标记的假设是基本的。许多内置函数，如 word、filter、wildcard 等，都假定它们的参数是空格分隔的单词。尽管如此，这里有一些小技巧可能会有所帮助。第一个技巧，在第八章“支持多个二叉树”一节中提到，是如何使用 subst 替换空格:
space = $(empty) $(empty)
# $(call space-to-question,file-name)
space-to-question = $(subst $(space),?,$1)
space-to-question 函数用通配符问号替换所有空格。现在，我们可以使用 wildcard 和 file-exists 函数来处理空格:
# $(call wildcard-spaces,file-name)
wildcard-spaces = $(wildcard $(call space-to-question,$1))
# $(call file-exists
file-exists = $(strip                                \
                $(if $1,,$(warning $1 has no value)) \
                $(call wildcard-spaces,$1))
wildcard-spaces 函数使用 space-to-question 来允许 makefile 对包含空格的模式执行通配符操作。我们可以使用 wildcard-spaces 函数来实现文件存在。当然，问号的使用也可能导致 wildcard-spaces 返回与原始通配符模式不正确匹配的文件(例如，”my document.doc” 和 “my-document.doc”)，但这是我们已经尽力了。
space-to-question 函数还可以用于转换目标和依赖中带有空格的文件名，因为这些文件名允许使用模式抓取。
space := $(empty) $(empty)
# $(call space-to-question,file-name)
space-to-question = $(subst $(space),?,$1)
# $(call question-to-space,file-name)
question-to-space = $(subst ?,$(space),$1)
$(call space-to-question,foo bar): $(call space-to-question,bar baz)
    touch "$(call question-to-space,$@)"
假设文件“bar baz”存在，那么第一次执行这个 makefile 时就会找到依赖，因为会计算抓取模式。但是目标通配符模式失败了，因为目标还不存在，所以 $@ 的值是foo?bar。然后，命令脚本使用 question-to-space 将 $@ 转换回具有我们真正需要的空格的文件。下一次运行 makefile 时，会找到目标，因为抓取模式会用空格找到目标。虽然有点难看，但我发现这些技巧在真正的 makefile 中很有用。
源代码树层次
可移植性的另一个方面是允许开发人员自由地管理他们认为必要的开发环境。例如，如果构建系统要求开发人员始终将他们的源代码、二进制文件、库和支持工具放在相同的目录下或相同的 Windows 磁盘驱动器上，那么就会出现问题。最终，一些磁盘空间不足的开发人员将面临必须对这些不同文件进行分区的问题。
相反，使用变量来引用这些文件集合并设置合理的默认值来实现 makefile 是有意义的。此外，每个支持库和工具都可以通过一个变量引用，以允许开发人员根据需要定制文件位置。对于最有可能的自定义变量，使用条件赋值操作符允许开发人员使用环境变量覆盖 makefile 的简单方法。
此外，轻松支持源代码和二叉树的多个副本的能力对开发人员来说是一个福音。即使他们不需要支持不同的平台或编译选项，开发人员也经常发现自己要使用源代码的多个副本，这可能是出于调试目的，也可能是因为他们要并行地处理多个项目。支持这一点的两种方法已经讨论过了: 使用“顶级”环境变量来标识源和二叉树的根，或者使用 makefile 的目录和固定的相对路径来查找二叉树。这两种方法都允许开发人员支持多个树的灵活性。
使用不可移植的工具
如前所述，编写 makefile 的另一种方法是采用一些标准工具。当然，我们的目标是确保标准工具至少与您正在构建的应用程序一样具有可移植性。可移植工具的明显选择是来自 GNU 项目的程序，但是可移植工具来自各种各样的来源。Perl 和 Python 是我想到的另外两个工具。
在缺少可移植工具的情况下，在 make 函数中封装不可移植的工具有时也可以做到同样的效果。例如，为了支持用于 Enterprise JavaBeans 的各种编译器(每个编译器的调用语法略有不同)，我们可以编写一个基本函数来编译 EJB jar 并对其进行参数化，以允许插入不同的编译器。
EJB_TMP_JAR = $(TMPDIR)/temp.jar
# $(call compile-generic-bean, bean-type, jar-name,
# bean-files-wildcard, manifest-name-opt )
define compile-generic-bean
    $(RM) $(dir $(META_INF))
    $(MKDIR) $(META_INF)
    $(if $(filter %.xml %.xmi, $3), \
        cp $(filter %.xml %.xmi, $3) $(META_INF))
    $(call compile-$1-bean-hook,$2)
    cd $(OUTPUT_DIR) &&                     \
    $(JAR) -cf0 $(EJB_TMP_JAR)              \
        $(call jar-file-arg,$(META_INF))    \
        $(call bean-classes,$3)
    $(call $1-compile-command,$2)
    $(call create-manifest,$(if $4,$4,$2),,)
endef
这个通用 EJB 编译函数的第一个参数是我们正在使用的 bean 编译器的类型，例如 Weblogic、Websphere 等。剩下的参数是 jar 名称、构成 jar 内容的文件(包括配置文件)和一个可选的清单文件。模板函数首先删除旧的临时目录，然后重新创建一个干净的临时区域。接下来，函数将依赖中出现的 xml 或 xmi 文件复制到 $(META_INF) 目录中。此时，我们可能需要执行自定义操作来清理 META-INF 文件或准备 .class 文件。为了支持这些操作，我们包含了一个钩子函数 compile-$1-bean-hook，如果需要，用户可以定义它。例如，如果 Websphere 编译器需要一个额外的控制文件，比如一个 xsl 文件，我们可以写这个钩子:
# $(call compile-websphere-bean-hook, file-list)
define compile-websphere-bean-hook
    cp $(filter %.xsl, $1) $(META_INF)
endef
通过简单地定义这个函数，我们可以确保 compile-generic-bean 中的调用将被适当地展开。如果不选择编写钩子函数，则 compile-generic-bean 中的调用将扩展为空。
接下来，泛型函数创建 jar。帮助函数 jar-file-arg 将一个普通的文件路径分解为一个 -C 选项和一个相对路径:
# $(call jar-file-arg, file-name)
define jar-file-arg
    -C "$(patsubst %/,%,$(dir $1))" $(notdir $1)
endef
帮助函数 bean-classes 从源文件列表中提取相应的类文件(jar文件只需要接口和主类):
# $(call bean-classes, bean-files-list)
define bean-classes
  $(subst $(SOURCE_DIR)/,,                  \
    $(filter %Interface.class %Home.class,  \
      $(subst .java,.class,$1)))
endef
然后泛型函数用 $(call $1-compilecommand，$2) 调用所选的编译器:
define weblogic-compile-command
    cd $(TMPDIR) && \
    $(JVM) weblogic.ejbc -compiler $(EJB_JAVAC) $(EJB_TMP_JAR) $1
endef
最后，泛型函数添加了清单。
定义了 compile-generic-bean 之后，我们将它包装在一个特定于编译器的函数中，用于我们想要支持的每个环境。
# $(call compile-weblogic-bean, jar-name,
#                               bean-files-wildcard, manifest-name-opt )
define compile-weblogic-bean
    $(call compile-generic-bean,weblogic,$1,$2,$3)
endef
标准 shell
值得在此重申的是，在从一个系统转移到另一个系统时发现的一个令人讨厌的不兼容性是 /bin/sh 的功能，这是 make 使用的默认 shell。如果您发现自己正在调整makefile 中的命令脚本，那么应该考虑标准化您的 shell。当然，对于典型的开放源码项目来说，这是不合理的，因为 makefile 是在不受控制的环境中执行的。然而，在受控的设置中，使用一组固定的特殊配置的机器，这是相当合理的。
除了避免 shell 不兼容之外，许多 shell 还提供了可以避免使用大量小实用程序的特性。例如，bash shell 包括增强的 shell 变量扩展，例如 %% 和 ##，这有助于避免使用 sed 和 expr 等 shell 工具。
Automake
本章的重点是如何有效地使用GNU make和支持工具来实现一个可移植的构建系统。然而，有些时候，即使是这些适度的要求也是遥不可及的。如果您不能使用 GNU make 的增强特性，而不得不依赖于一组最小公分母的特性，那么您应该考虑使用 automake 工具 http://www.gnu.org/software/automake/automake.html。
automake 工具接受一个程式化的 makefile 作为输入，并生成一个可移植的老式 makefile 作为输出。Automake 是围绕一组 m4 宏构建的，这些宏允许在输入文件(称为 makefile.am)中使用非常简洁的符号。通常，automake 与 autoconf 一起使用，autoconf 是 C/C++ 程序的可移植性支持包，但 autoconf 不是必需的。
虽然 automake 对于需要最大可移植性的构建系统来说是一个很好的解决方案，但是它生成的 makefile 不能使用 GNU make 的任何高级特性，除了附加赋值，+=，它对这个特性有特殊的支持。此外，automake 的输入与普通的 makefile 输入几乎没有相似之处。因此，使用 automake (不使用 autoconf )与使用最小公分母方法并没有太大的区别。
Managing Projects with GNU Make