计算化学公社

标题: 编译型语言构建系统选择 [打印本页]

作者
Author: ShiyuWang781 时间: 2025-4-23 15:47
标题: 编译型语言构建系统选择
大家用不自带构建系统的编译型语言编写程序时一般使用什么构建方式呢？

作者
Author: Graphite 时间: 2025-4-23 15:51
表面CMake，实则全靠cursor说啥我干啥XD

作者
Author: wal 时间: 2025-4-23 15:56

Graphite 发表于 2025-4-23 15:51
表面CMake，实则全靠cursor说啥我干啥XD

+1
不过一般我会要求cursor写cmakelists，不然小修重新编译我就抓瞎，命令太长了

作者
Author: ShiyuWang781 时间: 2025-4-23 16:15

Graphite 发表于 2025-4-23 15:51
表面CMake，实则全靠cursor说啥我干啥XD

cursor好用吗，我听说cuesor被禁止使用vscode插件了，而且cursor有些功能需要付费。

作者
Author: Graphite 时间: 2025-4-23 16:41

ShiyuWang781 发表于 2025-4-23 16:15
cursor好用吗，我听说cuesor被禁止使用vscode插件了，而且cursor有些功能需要付费。

非常好用，正常用插件，没发现有什么不行的。

密集开发可以氪金20刀一个月，包括cursor tab智能补全（一些常用但是难记的逻辑直接tab出来、一些小错误很方便）、composer（同时修改多个文件）、内置gpt和claude的API（不用再付费）

免费版就是能够自己设置第三方API用chat（单文件修改）的VSCode。至少比Github Copilot、Baidu Comate什么的灵活好用。

作者
Author: 万里云 时间: 2025-4-23 18:37
单文件手动编译，简单的多文件工程手写Makefile。

至于复杂的多文件工程，只能捏着鼻子用CMake。CMake的语法是经典的面多了加水，水多了加面，最后加成了一座屎山。它的兼容性策略居然是用数字编号的。看到CMP0048、CMP0057这样的编号，不查手册根本不知道什么意思。而且有的时候是睁眼瞎，明明写在环境变量里的包，就是找不到。有时候都不知道它是来解决问题的还是添乱的。但是很多编程工具只支持CMake，只能说时无英雄使竖子成名。

单独开发一门DSL得不偿失，像Python或Lua这样的通用语言+专用库的方式才是性价比最高的。既能借用该语言现成的工具，用户学习成本也低。

另外这些构建系统可以分为指令式和描述式。指令式有个问题，就是不同指令的执行时间不一样，有的在预处理阶段，有的在编译阶段，有的在安装阶段。都扔在一个文件里，有一部分指令实际上变成了描述式。很多指令式构建系统用起来别扭就是这个原因。像SCons这样的描述式构建系统才是未来的方向，可惜支持的工具太少。别的不说，用Python自己写一个搜库的函数，不比CMake那白痴般的find_package好用？

作者
Author: ShiyuWang781 时间: 2025-4-23 19:26
本帖最后由 ShiyuWang781 于 2025-4-23 19:33 编辑

万里云发表于 2025-4-23 18:37
单文件手动编译，简单的多文件工程手写Makefile。

至于复杂的多文件工程，只能捏着鼻子用CMake。CMake的 ...

我感觉find_package()不太好用，目前我的做法是要用包的时候先用xmake的包管理功能，看看能不能成功安装上，成功的话就可以让xmake自动管理，不行的话就在项目目录里面建一个文件夹单独放第三方库，然后去把源代码拿过来自己编译，之后把目录告诉xmake让它去连接。

作者
Author: ShiyuWang781 时间: 2025-4-23 19:29
本帖最后由 ShiyuWang781 于 2025-4-23 19:33 编辑

第六个应该是xmake，之前打错了

作者
Author: ShiyuWang781 时间: 2025-4-23 23:48
为什么用ninja的人这么少呢，按理说ninja比Makefile要更快更好用呀。

作者
Author: 万里云 时间: 2025-4-24 16:40

ShiyuWang781 发表于 2025-4-23 19:26
我感觉find_package()不太好用，目前我的做法是要用包的时候先用xmake的包管理功能，看看能不能成功安装 ...

xmake的包管理能自动编译安装吗？

作者
Author: ShiyuWang781 时间: 2025-4-24 16:49

万里云发表于 2025-4-24 16:40
xmake的包管理能自动编译安装吗？

能，但是有些包编译会出错

作者
Author: adver 时间: 2025-4-24 17:09
ninja确实快，但个人用的程序用makefile更容易上手，ninja主要还是用于编译一些linux大型适用软件

作者
Author: ShiyuWang781 时间: 2025-4-24 21:14

adver 发表于 2025-4-24 17:09
ninja确实快，但个人用的程序用makefile更容易上手，ninja主要还是用于编译一些linux大型适用软件

但我认为手写Makefile是很不方便的，就算用Makefile也应该用CMake自动生成，而CMake也可以生成Ninja文件，那么Makefile的用武之地就不多了

作者
Author: 万里云 时间: 2025-4-26 12:42

ShiyuWang781 发表于 2025-4-24 21:14
但我认为手写Makefile是很不方便的，就算用Makefile也应该用CMake自动生成，而CMake也可以生成Ninja文件 ...

Makefile中最复杂的部分是依赖关系。Fortran程序可以写个脚本扫描源码生成依赖，C/C++程序的编译器自带这个功能。

作者
Author: ShiyuWang781 时间: 2025-4-26 19:07

万里云发表于 2025-4-26 12:42
Makefile中最复杂的部分是依赖关系。Fortran程序可以写个脚本扫描源码生成依赖，C/C++程序的编译器自带这 ...

那用Cmake不是也能自动生成吗，而且功能还更多

作者
Author: 万里云 时间: 2025-4-27 15:37

ShiyuWang781 发表于 2025-4-26 19:07
那用Cmake不是也能自动生成吗，而且功能还更多

Makefile编译参数和过程是透明的，CMake隐藏了很多细节，有的时候反而会帮倒忙。

例如CMake编译时会加上-rapth参数，把动态库的地址硬编码进二进制文件里。再就是工程内部组件的依赖关系很难处理。虽然提供了add_dependency命令，但这条命令有时候有bug，仅仅是重命名一个文件，就各种链接错误。彻底清除build目录后从头编译也不行。

再就是CMake语法太丑了。list(APPEND xxx xxx)这种有比Frotran77还古老的感觉。

欢迎光临计算化学公社 (http://bbs.keinsci.com/)