【开发环境】我自己的MinGW-w64开发环境配置（带一键生成工程文件夹和vcxproj的脚本）
我写了一个脚本。它能根据提供的名字和项目类型全自动生成一个空的工程，有个makefile，有个vcxproj，有个entry.c，有build.bat。它既可以被MSVC编译，又能被Linux编译，还能被MinGW编译。你只需要往里面填充代码，你就可以用各种方式测试运行，并且只需要修改一处，就能附加新的依赖项。非常方便。然而我用它创建了一万个想写的项目以后，面对这一大堆自己挖开的新坑，我选择睡觉。没事给自己挖那么多坑干什么……
不过这个工具感觉还是挺有意思的（我甚至自己觉得自己写的东西有意思）因为我用BAT脚本对vcxproj和源码中的所有的“”等字符串进行了查找替换。
虽然据说有个很方便的工具，名叫“FART”（Find And Replace Text）但它的缺点是主页logo十分不雅观。脱裤子放屁。说的是批命令文本替换的需求是个脱裤子放屁的需求么？
官网：http://fart-it.sourceforge.net/
而且没有https加密，小心Man in the middle。
我的查找替换的方式我是这样写的：::前略
:replace_install
if exist %TARGETDIR%\%3 del %TARGETDIR%\%3
for /f "tokens=1* delims=]" %%h in ('echo "%TARGETDIR%\%3" ^| find /v /n ""') do (
if not exist %%~dpi (
echo Creating directory %%~dpi
mkdir %%~dpi
)
)
set "PROJ_UPPER=%1"
for %%b in (A B C D E F G H I J K L M N O P Q R S T U V W X Y Z) do (
setlocal enabledelayedexpansion
set "PROJ_UPPER=!PROJ_UPPER:%%b=%%b!"
endlocal
)
if exist %TARGETDIR%\%2 del /q %TARGETDIR%\%2
echo Copying %3
setlocal disabledelayedexpansion
for /f "tokens=1* delims=]" %%h in ('type %2 ^| find /v /n ""') do (
if "%%i"=="" (
echo.>>%TARGETDIR%\%3
) else (
set "curline=%%i"
setlocal enabledelayedexpansion
set "curline=!curline:=%1!"
set "curline=!curline:=%PROJ_UPPER%!"
echo.!curline!>>%TARGETDIR%\%3
endlocal
)
)
endlocal
goto :eof这里面的一个关键的技术性要点是SetLocal EnableDelayedExpansion这句的使用过程。
这句让CMD脚本在执行时被展开环境变量，此时双感叹号括起来的环境变量名所在命令会被延迟到被执行前被展开，而不是脚本文件被加载的时候展开。而set命令允许对环境变量的内容进行匹配和替换。
但是在脚本被执行的时候，for命令使用的迭代变量%i会被展开为文件的内容行，这在set命令被执行的时候，会直接变成 set xxx=明文内容 的展开方式。此时如果明文内容包含感叹号，它就会被当成“延迟展开的环境变量”的含义，然后被错误处理。为此，我的解决办法是只在最小范围使用SetLocal EnableDelayedExpansion和EndLocal的配对。
我配置好的开发环境涉及到一系列的批命令处理，但我懒得把它弄成能自动配置路径的了。所以如果要使用我的这套工具的话，需要按照说明一步步安装处理。
首先请下载我这包东西：
解压后是这个样子的：
其中MinGW_Proj用于存放你的工程，以及公共库和头文件等。而mingw-w64则是你的MinGW-w64工具链。
你需要先下载MinGW-w64工具链，才能使用MinGW-w64的gcc和makefile等一系列编译所需工具。
在mingw-w64文件夹里，我准备了一个安装器，它能联网下载MinGW-w64工具链。你使用它来把MinGW-w64工具链下载到你的mingw-w64文件夹里。
在如图所示的这一步里，你会遇到它问你下载哪个版本的工具链，弹出的界面如下图所示：
这里的选择，我觉得每一种都下载一下也不是不可以——硬盘够大。
我反正下载了四个版本。我觉得对于多线程这方面，Win32的和pthread都考虑有对应的。
gcc 8.1.0也不是非常地bleeding edge，目前没发现什么问题。我倒是不喜欢6以前的旧版，尤其是gcc 4.8它有个缺头文件却告诉你“我符合标准”的BUG……
在MinGW_Proj目录下有env.bat这个脚本。它们是用来设置以PATH为主的环境变量的。注意它会从common文件夹读取mingw_root.txt，你需要修改mingw_root.txt来让这个脚本能够正确设置环境变量，从而在命令行里运行gcc等命令。修改的方式就是把它里面一行的路径改成你自己的就行。截图是我的例子：
msys2env.bat这个脚本则是设置MSYS2相关的环境变量参数的，我是用它来进行autoconf、configure等一系列编译过程的，用于编译第三方库。它依赖common文件夹的msys_root.txt所以如果你有msys2，你需要修改msys_root.txt来使用它。
但其实这个msys2env.bat只是为了方便让msys2用cd命令切到当前位置文件夹而写的。它使用CMD的set命令查找替换功能把路径换成反斜杠。
你用不到msys2的话，这个bat对你无用。
env.bat的逻辑是这样的：
（通过各个位置找MinGW而已。之前考虑发布这个东西的时候是想自动配置MinGW的，但最终还是觉得无法做到完美的自动化。）
此外MinGW_Proj文件夹的common文件夹，不是项目，而是每个项目都可能需要的公共工具，包括公共头文件和动态、静态库等。
我预先弄了几个共享库在这里面，可以直接使用。但需要改makefile或者vcxproj来追加依赖项。
顺带一提这个vcxproj是VS2019的。旧的我不打算提供支持。
所有的libxxxxx.a风格的库都是给gcc用的，使用方法是编译或者链接的时候直接用-l命令行开关，然后写库的名字。比如libglew32s.a这个库，要使用的话去头去尾即可食用——使用命令行参数 -lglew32s 就可以了。我在env.bat里面设置了链接器路径环境变量，所以gcc能找到这些库。
大多数的这些gcc使用的库我都是使用lto方式编译的，并且设置了-ffat-lto-object来保证你不开-flto优化的时候也能进行非lto优化的链接过程。
但msvc则需要实际的lib文件的名字，而我在msvc的库文件夹里都是直接按库名来命名的。
MSVC的库我按照四个典型的不同配置来分类。注意有的库比如glfw等，我使用的是它官网给的bin，有的编译发布的bin只给了release，而我则把这些release的库也复制到了debug里。我自己写的库是按照debug和release分开编译的，所以是对应的。
然后为了能比较舒服地开始一个新的工程，我写了个自动按照工程模板来生成工程的脚本，以及几个示例工程。
要使用工程模板，你需要打开common文件夹下的newproj.bat批处理，然后根据提示一步一步输入东西。
它会对特定文件包括makefile、vcxproj等进行查找替换，然后设置工程名。这样名字的部分变了以后，剩下的设定都用我预先设置好的就行了。
并且可以编译运行，两种方式（MinGW-w64，VS2019）上而言。
都能跑。VS2019也能调试运行。
如果想要自定义工程模板，你需要参考每个工程模板自己的内容，然后修改installproj.bat这个批处理文件。
虽然十分复杂，但其实按照规律去修改就行了。
最后使用的情况就是你自己的事儿了。总之我不太喜欢cmake，它不接地气，生成的vcxproj也不好用，还有一堆没用的东西，而且还区分位数。 本帖最后由 大能猫 于 2019-5-9 03:07 编辑
我觉得海星，除了如果工程要挪位置得把脚本一起挪过去有点麻烦
配个vscode对应的launch.json和build.json应该基本可以当个vs用了
另：如果我写这玩意肯定用py，bat有点蛋疼（手动捂脸） 大能猫 发表于 2019-5-9 03:06
我觉得海星，除了如果工程要挪位置得把脚本一起挪过去有点麻烦
配个vscode对应的launch.json和build.json应 ...
那还不如用炮儿壳
页:
[1]