企业官网建设流程全解析

• 前端
• 构建工具

本文基于 node-sass 仓库内置文档src/libsass/docs/build-on-windows.md整理与扩充，讲解在 Windows 平台构建 libsass（node-sass 的 C++ 核心引擎）的三条经过验证的路线：MinGW 32 位、MinGW 64 位（mingw-w64）和 Visual Studio 2013。读完本文，你可以独立完成 libsass 静态库或共享库（dll）的编译、用 sass-spec 验证构建产物，并从 Makefile 与 CI 配置层面理解每条构建选项背后的实现机制。

需要说明适用前提：本文对应的是 node-sass 以 git 子模块/源码目录方式内置 libsass 源码的时期（代码位于 src/libsass/ 目录），构建工具链要求为 MinGW（GCC 4.6+）或 Visual Studio 2013 Update 4+，与 src/libsass/Readme.md 中 "Building" 一节的官方表述一致。原文档还指出：两种 Windows 构建方式都应视为实验性支持，其中 MinGW 路线测试得更充分。

一、三种构建路线总览

原文档给出的结论非常直接：

• MinGW（mingw.org 经典 32 位版本）：走 Makefile 构建，测试最充分，推荐首选；
• MinGW 64 位（mingw-w64 社区工具链）：用于在 64 位 Windows 上产出 libsass.dll，需要小幅修改 Makefile；
• Visual Studio Community 2013：走win\libsass.sln解决方案构建，要求 MSVC 2013（v120）编译器，因为 libsass 使用了 C++11 特性。

仓库中的 CI 配置 src/libsass/appveyor.yml 恰好印证了这三条路线都是被持续验证的：测试矩阵包含 MSVC 的Release/Debug × Win32/Win64四种组合，以及 mingw 的static与shared两种构建，构建脚本中对 mingw 使用mingw32-make -j4 sassc，对 msvc 使用msbuild /m:4 /p:Configuration=...;Platform=...。

二、MinGW 32 位构建（Makefile 路线）

这是原文档的主路线，全部步骤如下。

2.1 安装工具链

1. 安装 MinGW for Windows（从 MinGW 官方下载页获取安装包）。安装完成后可点击 continue，或通过bin\mingw-get.exe打开 Installation Manager 补装组件。构建 libsass 至少需要binutils、gcc-g++-core、make、mingw32-gcc-g++-core等核心组件（原文档以截图形式展示了勾选的组件清单）；
2. 安装 Git for Windows，建议勾选加入全局 PATH，无需安装 unix 工具；
3. 如果要跑 spec 测试套件，还需要 Ruby（加入全局 PATH）和 minitest gem：

gem install minitest

2.2 挂载 MinGW 根目录

按照 MinGW Getting Started 指南的做法，编辑C:\MinGW\msys\1.0\etc\fstab，加入一行：

C:\MinGW /mingw

这样 MSYS 的 shell 就能把 Windows 盘符路径与 POSIX 路径互译，git、rm等来自 MSYS 的工具才能正常操作C:\MinGW下的文件。

2.3 创建 "MinGW 控制台"

新建一个批处理文件，内容如下（原文档原样给出的脚本）：

@echo off set PATH=C:\MinGW\bin;%PATH% REM only needed if not already available set PATH=%PROGRAMFILES%\git\bin;%PATH% REM C:\MinGW\msys\1.0\msys.bat cmd

执行后，确认git、mingw32-make、rm、gcc四个命令都能调用。这一步是后续一切构建的前提——缺mingw32-make无法驱动 Makefile，缺rm/gcc说明 PATH 未生效。

2.4 获取源码

在独立仓库中按原文档的做法是分别克隆 libsass 以及（仅当需要 sassc 和/或测试套件时）sassc、sass-spec 到libsass/sassc、libsass/sass-spec。在 node-sass 仓库中，libsass 源码已经位于 src/libsass/，sassc/sass-spec 同样需要克隆到 src/libsass/ 下对应子目录：

git clone <sass/libsass 仓库地址> # only needed for sassc and/or testsuite git clone <sass/sassc 仓库地址> libsass/sassc git clone <sass/sass-spec 仓库地址> libsass/sass-spec

（原文档给出的是 GitHub 上的对应克隆地址，此处按仓库规范不输出外部链接。）

2.5 选择静态库还是共享库

libsass 可以构建为static（默认）或shared库，通过环境变量BUILD切换：

set BUILD="shared"

这一行为在 src/libsass/Makefile 中有明确实现：BUILD非shared时一律归一为static。而 Windows 分支下（Makefile L70-L84）有一套强制策略值得注意：

• 只要不是BUILD=shared，就置STATIC_ALL=1，并叠加STATIC_LIBGCC=1、STATIC_LIBSTDCPP=1；
• 这三个开关分别对应链接参数-static、-static-libgcc、-static-libstdc++（见 Makefile L114-L122），目的是把 GCC 运行时全部静态链入，避免产物依赖libgcc等 DLL——Makefile 中的注释也说明这会让体积增加约 50KB 但可移植性大增；
• Windows 下 C++ 标准被显式设为gnu++0x（C++11 的 GCC 旧写法），而非 Windows 平台用c++0x（见 Makefile L76-L83），这就是 VS 路线要求 2013 版的同一原因：代码用了 C++11 特性；
• 非 shared 时还会额外链-lstdc++（Makefile L107-L109），保证静态库用户链接时带上 C++ 运行时。

而 Windows 下 shared 构建会做两件事：产物名改为lib/libsass.dll，并给所有编译单元加-DADD_EXPORTS预定义宏（Makefile L166-L178），该宏用于 libsass 头文件中的__declspec(dllexport)导出控制。

2.6 编译与产物验证

mingw32-make -C libsass

编译成功后，产物在libsass/lib目录（原文档给出的示例输出）：

$ ls libsass/lib libsass.a libsass.dll libsass.so

在 node-sass 仓库中对应的实际路径是src/libsass/lib/。从源码结构看，三个文件分别来自 Makefile 中三条规则：lib/libsass.a（$(AR) rcvs归档，L233-L234）、lib/libsass.so（通用共享库规则）、lib/libsass.dll（L239-L240，链接时加-s -Wl,--subsystem,windows,--out-implib,lib/libsass.a，即生成 Windows 子系统 DLL 并导出一个libsass.a导入库）。

Windows 下 dll 规则还依赖$(RCOBJECTS)，即资源脚本编译产物。Makefile L189-L202 显示 Windows 分支会把res/resource.rc加入RESOURCES，并由windres工具编译（L245-L246：$(WINDRES) -i $< -o $@）。该资源脚本 src/libsass/res/resource.rc 为 DLL 写入版本信息（FILEVERSION 1,0,0,0、产品名 "LibSass Library"、原文件名libsass.dll），所以你在文件属性里看到的版本信息就来自它。

2.7 运行 spec 测试套件

mingw32-make -C libsass test_build

对照 Makefile L311-L315，test与test_build目标都会先构建 sassc（$(SASSC_BIN)在 Windows 下解析为sassc/bin/sassc.exe，见 L180-L182），然后执行：

ruby sass-spec/sass-spec.rb -V 3.5 -c sassc/bin/sassc.exe --impl libsass sass-spec/spec

即通过 sassc 命令行包装器对 libsass 跑完整的 sass-spec 3.5 语言规范。仓库还提供test_full（加--run-todo）与test_probe（加--probe-todo）两个扩展目标（L317-L321）。

三、MinGW 64 位构建（mingw-w64 路线）

原文档的第二节记录了在 64 位 Windows 上用 mingw-w64 工具链产出 libsass.dll 的做法，要点如下。

1. 下载 mingw-w64 社区工具链（文档指定的是 4.9.2 的x86_64-*-release-win32-seh-rt_v3-rev0.7z，SEH 异常模型、Win32 线程），解压到C:\mingw64。appveyor CI 实际使用的是同系列的 v4-rev3 版本（appveyor.yml L32-L37），说明该 4.9.2 工具链线是长期验证过的；
2. 创建批处理文件（注意比 32 位版本多了set CC=gcc）：

@echo off set PATH=C:\mingw64\bin;%PATH% set CC=gcc REM only needed if not already available set PATH=%PROGRAMFILES%\Git\bin;%PATH% REM C:\MinGW\msys\1.0\msys.bat cmd

3. 修复 DLL 依赖问题：默认 mingw64 编译出的 dll 会依赖mingwm10.dll、libgcc_s_dw2-1.dll等运行时 DLL。原文档给出的修复方式是在 Makefile 的 dll 规则中追加-static链接参数：

lib/libsass.dll: $(COBJECTS) $(OBJECTS) $(RCOBJECTS) $(MKDIR) lib $(CXX) -shared $(LDFLAGS) -o $@ $(COBJECTS) $(OBJECTS) $(RCOBJECTS) $(LDLIBS) -s -static -Wl,--subsystem,windows,--out-implib,lib/libsass.a

对比 当前仓库 Makefile 中该规则的原始形态（无-static，L239-L240），这行-static就是文档强调的改动点——它让 64 位 dll 不依赖 mingw-w64 的运行时 DLL，随 dll 分发即可运行。

4. 编译命令与 32 位路线相同：

mingw32-make -C libsass

原文档末尾还附了一句面向 Java JNA 使用者的提示：如果需要通过 JNA 调用该 dll，JNAerator 是一个不错的生成包装代码的工具（此处仅为原文档的延伸建议，与 libsass 本身无关）。

四、Visual Studio 2013 构建路线

4.1 打开正确的命令提示符

打开VS2013 x86 Native Tools Command Prompt。原文档记录了一个常见坑：安装社区版时可能只生成 2012 版的命令提示符快捷方式，需要手动从开始菜单复制快捷方式到桌面，并把其中路径从Visual Studio 11.0改为Visual Studio 12.0。

另一个硬性要求是编译器版本：libsass 使用 C++11 特性，至少需要 MSVC 2013 编译器（v120 工具集）。这一点可以直接在工程文件里验证——src/libsass/win/libsass.vcxproj 中声明了<PlatformToolset>v120</PlatformToolset>，即锁定 VC12（VS2013）工具集，即使解决方案文件 win/libsass.sln 的格式版本头是 VS2015（Visual Studio 14）。

4.2 获取源码

# using git is preferred git clone <sass/libsass 仓库地址> git clone <sass/sassc 仓库地址> libsass/sassc # only needed if you want to run the testsuite git clone <sass/sass-spec 仓库地址> libsass/sass-spec

4.3 用 msbuild 编译

有时命令提示符中msbuild不可用，全局搜索后将其所在目录（通常在 .NET 的 Bin 目录里）加入 PATH 即可。原文档给出的完整命令序列：

cd libsass REM set PATH=%PATH%;%PROGRAMFILES%\MSBuild\12.0\Bin msbuild /m:4 /p:Configuration=Release win\libsass.sln REM running the spec test-suite manually (needs ruby and minitest gem) ruby sass-spec\sass-spec.rb -V 3.5 -c win\bin\sassc.exe -s --impl libsass sass-spec/spec cd ..

/m:4表示 4 路并行。从解决方案结构看，win\libsass.sln定义了Debug|Win32、Debug|Win64、Release|Win32、Release|Win64四组配置，因此需要 64 位产物时可以改成/p:Configuration=Release;Platform=x64。工程实际参与编译的源文件清单（约 40 个.cpp/.c文件）在 src/libsass/win/libsass.targets 中集中维护，公共 API 头文件（sass.h、sass/context.h、sass/functions.h、sass/values.h等）也在同文件里以ClInclude列出；vcxproj 中还有一个GitVersion目标，通过git describe --abbrev=4 --dirty --always --tags注入版本宏，这与 Makefile 路线中 LIBSASS_VERSION 的生成方式（L52-L67） 是等价的。

五、构建机制补充：从源码看三条路线的汇合点

结合 src/libsass/Makefile 与 src/libsass/appveyor.yml，可以归纳出 Windows 构建的几个关键机制：

1. 平台识别：Makefile 通过PATH中是否含/cygdrive/、OS是否为Windows_NT、$(MAKE)是否含mingw32等多重探测确定UNAME := Windows（L30-L46），并据此切换到-std=gnu++0x、静态链 GCC/STDCPP、启用res/resource.rc这一整套 Windows 行为。
2. Windows 下静态是默认且被强化的：不设置BUILD=shared时STATIC_ALL默认 1，加上STATIC_LIBGCC、STATIC_LIBSTDCPP，产物（libsass.a）是自包含的——这也是为什么 node-sass 这类下游项目用 node-gyp 编译时可以直接静态链接 libsass 而不需要分发额外运行库。
3. CI 即文档：appveyor 的配置把本文三条路线全部覆盖（MSVC × 4 组配置 + mingw static + mingw shared，且 mingw 分支使用C:\mingw64的 64 位工具链），并在测试阶段额外验证了一个中文/西里尔字符当前目录下编译 sassc 的 Unicode 场景（L82-L90），说明 Windows 路径编码曾是真实踩过的坑。
4. 源码清单的单一来源：Makefile 路线的编译单元来自 src/libsass/Makefile.conf 中的SOURCES/CSOURCES（大文件排前的注释解释了并行编译时避免 RAM 峰值的考量），而 VS 路线的清单在win/libsass.targets中手工维护——两套清单内容高度对应，修改源码文件时需要同时留意两处。

六、与 node-sass 的关系及常见问题

• node-sass 自身并不直接链接lib/libsass.a，而是由 binding.gyp 通过 node-gyp 编译 src/libsass.gyp 子工程来构建 libsass，再编译 src/binding.cpp 等 Node 绑定层。因此本文的手动构建流程主要用于开发调试与 CI 场景，理解它对排查npm install时 libsass 编译失败（缺 MinGW、C++ 标准不达标等）非常有用。
• 构建后产物验证：mingw32-make -C libsass lib-file-shared/lib-file-static、lib-opts-shared/lib-opts-static（Makefile L332-L342）会分别打印库文件路径与链接选项，方便手工集成。
• 清理与重建：make clean删除全部目标文件与库（CLEANUPS覆盖了对象文件、资源对象和静态库，见 L210-L214），切换BUILD=shared/static后建议先clean再重新编译，避免旧对象与新导出宏（ADD_EXPORTS）不匹配。
• 适用限制：所有步骤以 libsass 3.5 时代（sass-spec 3.5、GCC 4.6+/MSVC v120）为前提；若你使用新版 mingw-w64 工具链或更高版本 Visual Studio，Makefile 的 Windows 探测与静态链接策略不变，但需自行验证工具集兼容性。

参考资料（仓库内路径）：src/libsass/docs/build-on-windows.md（本文主体来源）、src/libsass/Makefile、src/libsass/Makefile.conf、src/libsass/appveyor.yml、src/libsass/win/libsass.sln、src/libsass/win/libsass.targets、src/libsass/res/resource.rc、binding.gyp。

• 前端
• 构建工具