作者hizuki (真女主角爱与正义的天使)
看板Soft_Job
标题[讨论] 可以不要再手刻Makefile 改用cmake, meson不好吗
时间Tue Mar 14 15:07:46 2023
#1a1f6YB1 (Soft_Job) [ptt.cc] Fw: [问卦] C++到底难学在哪?
: 推 wizmelo: 我觉得C++一开始CMake建置环境就会劝退很多人 然後报错 03/09 09:22
: → wizmelo: 的异常很难看懂 导入别的包使用function 也写的很难让人 03/09 09:22
: → wizmelo: 看懂 如果以一个没使用过的人来说 03/09 09:22
: 推 ko27tye: 没跨平台需求老实说make够用了 03/09 13:19
: 推 wulouise: cmake比make简单，但是要是不懂make有时候出问题，难查 03/10 22:57
: → superpandal: go的很不统一 import个包要全网址 03/13 17:36
: → superpandal: 原生makefile比cmake好多了 简洁有力 03/13 17:38
: → superpandal: 而且现在一堆这样的都很肥大cmake meson都是 03/13 17:39
: → superpandal: 装一装一堆没用到的语言都装上去 03/13 17:40
: → superpandal: 当然都可以用shell来产makefile就像 03/13 17:49
: → superpandal: cmake configure那种乱写的除外 03/13 17:50
我非常同意CMake的报错信息难看懂，所以我都改用meson了。
先不战CMake和meson
Makefile不是不可以跨平台，如FFmpeg。我也不是完全反对Makefile，
kernel, buildroot(openwrt)，最上层用用Makefile还行。不过後者我改
OpenEmbedded了。
我们先不讲跨平台，C++一个header编译到怀疑人生的久，不用PCH处理早晚吐血。
你试看看Makefile写个recipe来处理。
很多人Makeilfe的link规范写不对盘，bsd linker, gold linker, lld，最老的bsd随便你
写顺序都能link上。後面要速度换了一个。
结果一个shared library A依赖shared library B。你构建target的时候，B写在A的前面了，
马上gold linker报错。
static library不是当作object输入的，当作一个library，结果死活有一个symbol unresolve。
还有很多肚烂的的先把objects全部都archive，然後再制造出executable或者shared library。
突然提示symbol unresolve，几百个objects我要在长长的log中找出来哪个symbol。
为什麽compiling的时候不提示？因为header file中有这个declaration，结果symbol的
definition完全不同。
又为什麽会这样呢？因为Makefile的cflags, cxx flags和ld flags这些传递都是没有保障的，
可能莫名奇妙的被另外一个file给override了。後面的target全部死光光。
meson虽然没有明显区分local variable和global的，但是这些flags是可以一个target一个
设定的。CMake有个非常复杂的naming scope机制，我基本上理解到放弃。
另外就是所谓的options功能了，每次都重新编译大项目没几个人受得了。而Makefile的
string解析真是烂，要call shell来又可能会造成env和本地变数冲突，语法可能有不正确的
解析。
以上都是工作中的碎碎念。实际的场景比这个更复杂
--
你比较喜欢哪一个?
当年不是党国大老但是被江浙财团捧红的中国帅哥
跟同样拥兵一方的诸侯约会裁军结果半途诸侯们爽约，平常有在写日记的庄严男人开始发飙
在旁边读着荒漠甘泉冷眼旁观看着蔷薇战争的人，为了中国的事情争吵
别国调侃是不是中国总统，义正词严的说着我是民族的灯塔的威严老先生
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 192.147.44.15 (美国)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1678777673.A.15D.html
1F：推 Apache: 都用Bazel 03/14 15:40
Bazel语法没法理解，我觉得bazel更像bitbake了。
2F：推 pacino: autoconf 很好用啊 03/14 15:50
大哥，猫王死了啊。九十年代过了
3F：推 tennyleaz: 我常常都用动态DllImport比较懒XD 03/14 16:04
Windows派是吧，多来几个你试看看，还有你多来几个C++ ABI
4F：推 labbat: docker 万用解 03/14 16:18
docker只能帮你准备environment，这些不基本上不用来准备environment的
※ 编辑: hizuki (192.147.44.15 美国), 03/14/2023 16:24:58
5F：→ labbat: 题外话，好奇你引用的那些留言串出自那篇文章呀 03/14 16:27
其实就在本版上面一点，我补上了
6F：推 timmerix: 你这些都还好, 有些公司有自己内部的make系统, 完全没有 03/14 16:48
7F：→ timmerix: 详细的使用说明, build报错只能猜或自己做实验试 03/14 16:49
有些是拿Makfile改的，那已经够吐血了。
※ 编辑: hizuki (192.147.44.15 美国), 03/14/2023 17:20:35
8F：→ superpandal: 这不就是专案规范的锅 静态的是打包所有object没错 03/14 17:28
9F：→ superpandal: object没错 用shell不是指在makefile里用 而是如同co 03/14 17:29
10F：→ superpandal: 用 而是如同configure 但不会是如此糟糕的写法 03/14 17:30
11F：→ superpandal: 的写法 makefile本身就不适合动态 而shell 03/14 17:31
12F：→ superpandal: shell很动态 本身还是个web仔就是 03/14 17:32
13F：→ superpandal: 不过如果慢可以多job 或不用c++ XD 03/14 17:44
14F：推 loadingN: 确实 有维护过 旧的Makefile... 03/14 17:47
15F：推 superpandal: 上面那串是表示私下研究觉得相关的都太臃肿 03/14 17:48
16F：→ superpandal: 臃肿 cmake meson都是 03/14 17:49
17F：→ superpandal: 反正我都自己写shell框架了 03/14 17:51
18F：→ superpandal: cmake本身都是生出makefile或在win下可能是vs专案 03/14 17:56
19F：→ superpandal: 能是vs专案 03/14 17:56
20F：→ superpandal: 躺平的web仔 但shell功力越来越出神入化了 03/14 18:02
21F：→ superpandal: 了 03/14 18:02
Web如果是Java的话，老老实实用maven gradle。我们不需要package management。
我们的环境是要用linker的，麦类比。
22F：推 Bencrie: 我写的东西不够大，自己刻 Makefile 还蛮好用的 03/14 19:37
23F：推 gino0717: 我都用qmake 03/14 19:40
24F：→ alongalone: 老哥 你内行的诶... 直接丢出去给别人解就好啦 03/14 23:11
25F：→ Lipraxde: 工具本身设计可能确实是会导致最终变得难用...不过也有 03/14 23:43
26F：→ Lipraxde: 蛮多时候是使用者的问题... 03/14 23:43
27F：推 zetexp: 可以用用看xmake 03/15 00:03
meson已经足够了，xmake反而是中国式的All in One
28F：推 shomingchang: 我只会用python写建置脚本 03/15 00:05
setuptool没有什麽问题
29F：推 mmonkeyboyy: 看大小吧.....杀鸡不用牛刀 牛刀也要磨很久啊 03/15 00:41
30F：→ superpandal: 给你倚天剑和屠龙刀你要选哪个？ 都是利器 03/15 01:02
31F：→ superpandal: 器 03/15 01:02
32F：→ k798976869: 手枪：py 03/15 08:22
33F：推 chchwy: 这就是C++的问题 一大堆build tool 03/15 09:39
34F：→ chchwy: 每个人不爽就自己再干一个 03/15 09:39
所有要构建的语言都是这样的，这个是project的问题，和语言本身无关。
35F：→ Ekmund: go: tidy 03/15 09:44
36F：→ Ekmund: 你看看光make就可以搞成这样有多劝退 03/15 09:44
37F：→ Ekmund: 加个自己刻的小lib 重写makefile後跳undefined reference 03/15 10:06
38F：→ Ekmund: 光linker single-pass的特性就容易变成坑 03/15 10:06
Go听说升级有造成memory炸掉，这种有GC的语言不是一个生态的
※ 编辑: hizuki (192.147.44.15 美国), 03/15/2023 10:59:36
39F：→ superpandal: 不是类比 只是在说不是在公司用 03/15 17:43
40F：→ superpandal: 毕竟前面一堆讲公司如何如何 03/15 17:45
41F：→ superpandal: java目前的确用那两个 但说实话也是偏静态的 03/15 17:46
自己硬干没有什麽问题，但是项目总是会扩展的，比如cross platform，这个其实算静态
42F：→ superpandal: 态的 也都可以土法炼钢 或自己整一个工具 03/15 17:47
43F：→ superpandal: 具 03/15 17:48
44F：→ superpandal: py是手枪？ XD 03/15 17:51
45F：→ superpandal: go还是主要在抓远端依赖 c读本机lib 03/15 17:58
46F：→ superpandal: 然而每个系统都不同 比不了 03/15 17:59
47F：→ superpandal: 历史因素了 但纯makefile或小工具生成很简洁 03/15 18:01
48F：→ superpandal: 不错 03/15 18:02
举个例子，Makefile生小工具的惨剧。某个七老八老的BSD的，好死不死
memory超过2GiB(3GiB)了，结果不知道要用mmap64()，结果死活读不到一部分的memory了。
如果有GNU autotools的话，就会自动探测我可以用mmap64()而不是mmap()
世界总是有地雷的。
※ 编辑: hizuki (192.147.44.15 美国), 03/15/2023 18:22:46
49F：→ superpandal: 自己的东西不会考虑非类unix 现在也有 03/15 18:43
50F：→ superpandal: wsl 03/15 18:43
看了笔记写错了，那次是读register段正好在3G外
可以理解，但是真的不鼓励
※ 编辑: hizuki (192.147.44.15 美国), 03/15/2023 18:45:26
51F：→ superpandal: 这应该是编译器要做的 不是专案管理工具要做的 03/15 18:45
Linux有很多32bits->64bits扩展带来的问题，编译器在制定的时候根本POSIX还没定这些
据说solaris有很多这种类，要接受业界有很多设备不能更换。
※ 编辑: hizuki (192.147.44.15 美国), 03/15/2023 18:47:55
52F：→ superpandal: 要做的 03/15 18:45
53F：→ superpandal: 还是要改编译器 本来就很多选项不是标准 03/15 18:54
54F：→ superpandal: 给编译器分析就很好 连专案管理都这样搞就魔怔了 03/15 18:57
55F：→ superpandal: 就入魔了 03/15 18:57
56F：→ MTKer5566: 幸好我不再写code了 03/15 19:15
57F：→ projectb: Qmake: 03/15 19:34
58F：推 e12518166339: 虽然我这麽觉得，但是gnu相关的lib都还是用makefile 03/15 20:27
59F：→ e12518166339: 为大宗，工作上根本躲不掉 03/15 20:27
60F：推 mmonkeyboyy: 推楼上 = =" 根本躲不掉.... 03/16 04:06
一般只有toolchains需要，这个只有bootstrap做一次。当然你要改什麽utils当我没讲
61F：→ mmonkeyboyy: 一堆HPC应用....下面也是make 手刻在那里搞 03/16 04:07
我正好是做graphics的
62F：推 Bencrie: GNU 是老牌 autotools 系列吧 03/16 08:56
63F：→ superpandal: makefile是makefile gnu autotool和cmake是一类东 03/16 09:32
64F：→ superpandal: cmake是一类东西 03/16 09:33
65F：→ superpandal: 然後都是再自创一个dsl把简单复杂化 03/16 09:33
66F：→ superpandal: 最终目标也都是生成makefile 03/16 09:35
67F：→ superpandal: 基本上你写个脚本也叫cmake 针对专案文件 03/16 09:39
68F：→ superpandal: 件也做差不多的事情结果也差不多 03/16 09:40
69F：→ superpandal: 不用额外装一堆东西是好处 03/16 09:41
70F：→ superpandal: 然後脚本也占不了几k容量 03/16 09:44
71F：→ superpandal: 至於纯写makefile也不是不可以 只是架构要精美 03/16 10:00
72F：→ superpandal: 要精美 03/16 10:00
73F：推 peterbrucele: 推e大 後人总是跟据前面问题开发新工具 但更多时候 03/16 15:08
74F：→ peterbrucele: 旧系统无法迁移 03/16 15:08
75F：推 ztdxqa: 惊 原来现在还有没用Bazel的吗？2017年入职转到现在三个 03/16 16:39
76F：→ ztdxqa: 公司都是用Bazel 03/16 16:39
77F：→ superpandal: bazel更扯 连java都装上了 那跑起来很恐布 03/16 17:48
78F：→ superpandal: 布 大机率是某个java派主导的 看了一下优点... 03/16 17:50
tensorflow是逃不掉的，语法真的很可怕。所幸lite改cmake了
79F：→ superpandal: 优点 这就... makefile都可以include 虽然动态性 03/16 17:53
80F：→ superpandal: 然动态性不是太好 但节省设定是可以的 03/16 17:54
Google就是爱推。但是Google这个渣男，Android又推go plugin(soong)来生成构建规则，
而Android app却又是gradle那一套。
81F：→ superpandal: 再搭其它小工具如ccache就可以了 03/16 17:55
82F：→ superpandal: 即便没有cache也是编译有改的 03/16 17:55
83F：→ superpandal: 拿来管理java专案或许不错 03/16 17:57
84F：推 richer6605: 推推 只知道makefile 看了文章觉得长知识 03/16 19:26
85F：→ superpandal: 这是长常识 千言万语抵不过体验 03/16 20:55
86F：→ superpandal: 现在看来很多工具真的意义不大 03/16 20:57
87F：→ superpandal: 继续遵守unix原教旨 03/16 20:58
我很想把这个KISS赶走
88F：推 OnlyRD: cmake有很难用？我觉得modern cmake其实还可以。 03/17 02:11
89F：推 mmonkeyboyy: 楼上你老了 (上次我说跟你一样的话时别人也这样讲我) 03/17 05:53
modern cmake的问题是没有阻止旧语法，和C++一样我弄不清究竟要怎麽写。
而且cmake真心的慢
※ 编辑: hizuki (192.147.44.15 美国), 03/17/2023 15:00:13
90F：→ shooter555: mason最烦的是旧环境要支援很麻烦 03/17 16:07
91F：→ shooter555: 不过现在还是很多专案还在用automake 03/17 16:07
92F：→ superpandal: kiss非常好 其实并不傻 03/17 17:08
93F：→ superpandal: 主要都是cmake又更复杂了 动态性也没高太多 03/17 17:13
94F：→ superpandal: 太多 shell更动态 makefile用include也不错 03/17 17:15
95F：→ superpandal: 不错 很多人讲不要拿shell搞大工程 03/17 17:16
96F：→ superpandal: 但其实很熟了也未尝不可 也有好处 03/17 17:17
97F：→ superpandal: 当然不是指oneliner 03/17 17:20
98F：推 CLANNAD: project没很大的话scons用起来最爽 03/18 18:07
99F：推 Raymond0710: 看了就累 幸好不怎麽写cpp了... 03/20 17:20
100F：推 shibin: 我目前写小专案还是用Makefile，遇到的问题都还没你说的多 03/21 14:12
101F：→ shibin: 真的吓人 03/21 14:13