前端构建工具【免费下载链接】node-sass:rainbow: Node.js bindings to libsass项目地址https://gitcode.com/gh_mirrors/no/node-sass点击查看免费下载本文基于 node-sass 仓库内置文档src/libsass/docs/build-on-windows.md整理与扩充讲解在 Windows 平台构建 libsassnode-sass 的 C 核心引擎的三条经过验证的路线MinGW 32 位、MinGW 64 位mingw-w64和 Visual Studio 2013。读完本文你可以独立完成 libsass 静态库或共享库dll的编译、用 sass-spec 验证构建产物并从 Makefile 与 CI 配置层面理解每条构建选项背后的实现机制。需要说明适用前提本文对应的是 node-sass 以 git 子模块/源码目录方式内置 libsass 源码的时期代码位于 src/libsass/ 目录构建工具链要求为 MinGWGCC 4.6或 Visual Studio 2013 Update 4与 src/libsass/Readme.md 中 Building 一节的官方表述一致。原文档还指出两种 Windows 构建方式都应视为实验性支持其中 MinGW 路线测试得更充分。一、三种构建路线总览原文档给出的结论非常直接MinGWmingw.org 经典 32 位版本走 Makefile 构建测试最充分推荐首选MinGW 64 位mingw-w64 社区工具链用于在 64 位 Windows 上产出 libsass.dll需要小幅修改 MakefileVisual Studio Community 2013走win\libsass.sln解决方案构建要求 MSVC 2013v120编译器因为 libsass 使用了 C11 特性。仓库中的 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 安装工具链安装 MinGW for Windows从 MinGW 官方下载页获取安装包。安装完成后可点击 continue或通过bin\mingw-get.exe打开 Installation Manager 补装组件。构建 libsass 至少需要binutils、gcc-g-core、make、mingw32-gcc-g-core等核心组件原文档以截图形式展示了勾选的组件清单安装 Git for Windows建议勾选加入全局 PATH无需安装 unix 工具如果要跑 spec 测试套件还需要 Ruby加入全局 PATH和 minitest gemgem install minitest2.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 PATHC:\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 BUILDshared这一行为在 src/libsass/Makefile 中有明确实现BUILD非shared时一律归一为static。而 Windows 分支下Makefile L70-L84有一套强制策略值得注意只要不是BUILDshared就置STATIC_ALL1并叠加STATIC_LIBGCC1、STATIC_LIBSTDCPP1这三个开关分别对应链接参数-static、-static-libgcc、-static-libstdc见 Makefile L114-L122目的是把 GCC 运行时全部静态链入避免产物依赖libgcc等 DLL——Makefile 中的注释也说明这会让体积增加约 50KB 但可移植性大增Windows 下 C 标准被显式设为gnu0xC11 的 GCC 旧写法而非 Windows 平台用c0x见 Makefile L76-L83这就是 VS 路线要求 2013 版的同一原因代码用了 C11 特性非 shared 时还会额外链-lstdcMakefile 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.dllL239-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-L315test与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 的做法要点如下。下载 mingw-w64 社区工具链文档指定的是 4.9.2 的x86_64-*-release-win32-seh-rt_v3-rev0.7zSEH 异常模型、Win32 线程解压到C:\mingw64。appveyor CI 实际使用的是同系列的 v4-rev3 版本appveyor.yml L32-L37说明该 4.9.2 工具链线是长期验证过的创建批处理文件注意比 32 位版本多了set CCgccecho off set PATHC:\mingw64\bin;%PATH% set CCgcc REM only needed if not already available set PATH%PROGRAMFILES%\Git\bin;%PATH% REM C:\MinGW\msys\1.0\msys.bat cmd修复 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 中该规则的原始形态无-staticL239-L240这行-static就是文档强调的改动点——它让 64 位 dll 不依赖 mingw-w64 的运行时 DLL随 dll 分发即可运行。编译命令与 32 位路线相同mingw32-make -C libsass原文档末尾还附了一句面向 Java JNA 使用者的提示如果需要通过 JNA 调用该 dllJNAerator 是一个不错的生成包装代码的工具此处仅为原文档的延伸建议与 libsass 本身无关。四、Visual Studio 2013 构建路线4.1 打开正确的命令提示符打开VS2013 x86 Native Tools Command Prompt。原文档记录了一个常见坑安装社区版时可能只生成 2012 版的命令提示符快捷方式需要手动从开始菜单复制快捷方式到桌面并把其中路径从Visual Studio 11.0改为Visual Studio 12.0。另一个硬性要求是编译器版本libsass 使用 C11 特性至少需要 MSVC 2013 编译器v120 工具集。这一点可以直接在工程文件里验证——src/libsass/win/libsass.vcxproj 中声明了PlatformToolsetv120/PlatformToolset即锁定 VC12VS2013工具集即使解决方案文件 win/libsass.sln 的格式版本头是 VS2015Visual 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-spec4.3 用 msbuild 编译有时命令提示符中msbuild不可用全局搜索后将其所在目录通常在 .NET 的 Bin 目录里加入 PATH 即可。原文档给出的完整命令序列cd libsass REM set PATH%PATH%;%PROGRAMFILES%\MSBuild\12.0\Bin msbuild /m:4 /p:ConfigurationRelease 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:ConfigurationRelease;Platformx64。工程实际参与编译的源文件清单约 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 --abbrev4 --dirty --always --tags注入版本宏这与 Makefile 路线中 LIBSASS_VERSION 的生成方式L52-L67 是等价的。五、构建机制补充从源码看三条路线的汇合点结合 src/libsass/Makefile 与 src/libsass/appveyor.yml可以归纳出 Windows 构建的几个关键机制平台识别Makefile 通过PATH中是否含/cygdrive/、OS是否为Windows_NT、$(MAKE)是否含mingw32等多重探测确定UNAME : WindowsL30-L46并据此切换到-stdgnu0x、静态链 GCC/STDCPP、启用res/resource.rc这一整套 Windows 行为。Windows 下静态是默认且被强化的不设置BUILDshared时STATIC_ALL默认 1加上STATIC_LIBGCC、STATIC_LIBSTDCPP产物libsass.a是自包含的——这也是为什么 node-sass 这类下游项目用 node-gyp 编译时可以直接静态链接 libsass 而不需要分发额外运行库。CI 即文档appveyor 的配置把本文三条路线全部覆盖MSVC × 4 组配置 mingw static mingw shared且 mingw 分支使用C:\mingw64的 64 位工具链并在测试阶段额外验证了一个中文/西里尔字符当前目录下编译 sassc 的 Unicode 场景L82-L90说明 Windows 路径编码曾是真实踩过的坑。源码清单的单一来源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-staticMakefile L332-L342会分别打印库文件路径与链接选项方便手工集成。清理与重建make clean删除全部目标文件与库CLEANUPS覆盖了对象文件、资源对象和静态库见 L210-L214切换BUILDshared/static后建议先clean再重新编译避免旧对象与新导出宏ADD_EXPORTS不匹配。适用限制所有步骤以 libsass 3.5 时代sass-spec 3.5、GCC 4.6/MSVC v120为前提若你使用新版 mingw-w64 工具链或更高版本 Visual StudioMakefile 的 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。赞分享前端构建工具【免费下载链接】node-sass:rainbow: Node.js bindings to libsass项目地址https://gitcode.com/gh_mirrors/no/node-sass点击查看免费下载相关推荐在 Windows 上从源码构建 RubyMingw/UCRT 与 Visual C 双路径完整指南在 Windows 上从源码构建 RubyMingw/UCRT 与 Visual C 双路径完整指南 本文以 Ruby 官方文档 doc/distribu编程语言语言运行时解释器编译器标准库JIT编译CUTLASS C 构建指南Windows/Visual Studio 与 Clang Host 编译器CUTLASS C 构建指南Windows/Visual Studio 与 Clang Host 编译器 CUTLASS 是 NVIDIA 开源的 CUD算子库高性能计算在 Windows 上使用 Visual Studio 构建 CUTLASS完整实战指南在 Windows 上使用 Visual Studio 构建 CUTLASS完整实战指南 CUTLASSCUDA Templates for Linear算子库高性能计算上一篇IntelliJ IDEA Community Edition性能优化实战内存管理与响应速度提升下一篇Issue模板示例创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考