PTT推薦

[討論] 可以不要再手刻Makefile 改用cmake, meson不好嗎

看板Soft_Job標題[討論] 可以不要再手刻Makefile 改用cmake, meson不好嗎作者
hizuki
(真女主角愛與正義的天使)
時間推噓21 推:21 噓:0 →:76

#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 留言評論
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 192.147.44.15 (美國)
PTT 網址

Apache03/14 15:40都用Bazel

Bazel語法沒法理解,我覺得bazel更像bitbake了。

pacino03/14 15:50autoconf 很好用啊

大哥,貓王死了啊。九十年代過了

tennyleaz03/14 16:04我常常都用動態DllImport比較懶XD

Windows派是吧,多來幾個你試看看,還有你多來幾個C++ ABI

labbat03/14 16:18docker 萬用解

docker只能幫你準備environment,這些不基本上不用來準備environment的

※ 編輯: hizuki (192.147.44.15 美國), 03/14/2023 16:24:58

labbat03/14 16:27題外話,好奇你引用的那些留言串出自那篇文章呀

其實就在本版上面一點,我補上了

timmerix03/14 16:48你這些都還好, 有些公司有自己內部的make系統, 完全沒有

timmerix03/14 16:49詳細的使用說明, build報錯只能猜或自己做實驗試

有些是拿Makfile改的,那已經夠吐血了。

※ 編輯: hizuki (192.147.44.15 美國), 03/14/2023 17:20:35

superpandal03/14 17:28這不就是專案規範的鍋 靜態的是打包所有object沒錯

superpandal03/14 17:29object沒錯 用shell不是指在makefile裡用 而是如同co

superpandal03/14 17:30用 而是如同configure 但不會是如此糟糕的寫法

superpandal03/14 17:31的寫法 makefile本身就不適合動態 而shell

superpandal03/14 17:32shell很動態 本身還是個web仔就是

superpandal03/14 17:44不過如果慢可以多job 或不用c++ XD

loadingN03/14 17:47確實 有維護過 舊的Makefile...

superpandal03/14 17:48上面那串是表示私下研究覺得相關的都太臃腫

superpandal03/14 17:49臃腫 cmake meson都是

superpandal03/14 17:51反正我都自己寫shell框架了

superpandal03/14 17:56cmake本身都是生出makefile或在win下可能是vs專案

superpandal03/14 17:56能是vs專案

superpandal03/14 18:02躺平的web仔 但shell功力越來越出神入化了

superpandal03/14 18:02

Web如果是Java的話,老老實實用maven gradle。我們不需要package management。 我們的環境是要用linker的,麥類比。

Bencrie03/14 19:37我寫的東西不夠大,自己刻 Makefile 還蠻好用的

gino071703/14 19:40我都用qmake

alongalone03/14 23:11老哥 你內行的誒... 直接丟出去給別人解就好啦

Lipraxde03/14 23:43工具本身設計可能確實是會導致最終變得難用...不過也有

Lipraxde03/14 23:43蠻多時候是使用者的問題...

zetexp03/15 00:03可以用用看xmake

meson已經足夠了,xmake反而是中國式的All in One

shomingchang03/15 00:05我只會用python寫建置腳本

setuptool沒有什麼問題

mmonkeyboyy03/15 00:41看大小吧.....殺雞不用牛刀 牛刀也要磨很久啊

superpandal03/15 01:02給你倚天劍和屠龍刀你要選哪個? 都是利器

superpandal03/15 01:02

k79897686903/15 08:22手槍:py

chchwy03/15 09:39這就是C++的問題 一大堆build tool

chchwy03/15 09:39每個人不爽就自己再幹一個

所有要構建的語言都是這樣的,這個是project的問題,和語言本身無關。

Ekmund03/15 09:44go: tidy

Ekmund03/15 09:44你看看光make就可以搞成這樣有多勸退

Ekmund03/15 10:06加個自己刻的小lib 重寫makefile後跳undefined reference

Ekmund03/15 10:06光linker single-pass的特性就容易變成坑

Go聽說升級有造成memory炸掉,這種有GC的語言不是一個生態的

※ 編輯: hizuki (192.147.44.15 美國), 03/15/2023 10:59:36

superpandal03/15 17:43不是類比 只是在說不是在公司用

superpandal03/15 17:45畢竟前面一堆講公司如何如何

superpandal03/15 17:46java目前的確用那兩個 但說實話也是偏靜態的

自己硬幹沒有什麼問題,但是項目總是會擴展的,比如cross platform,這個其實算靜態

superpandal03/15 17:47態的 也都可以土法煉鋼 或自己整一個工具

superpandal03/15 17:48

superpandal03/15 17:51py是手槍? XD

superpandal03/15 17:58go還是主要在抓遠端依賴 c讀本機lib

superpandal03/15 17:59然而每個系統都不同 比不了

superpandal03/15 18:01歷史因素了 但純makefile或小工具生成很簡潔

superpandal03/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

superpandal03/15 18:43自己的東西不會考慮非類unix 現在也有

superpandal03/15 18:43wsl

看了筆記寫錯了,那次是讀register段正好在3G外 可以理解,但是真的不鼓勵

※ 編輯: hizuki (192.147.44.15 美國), 03/15/2023 18:45:26

superpandal03/15 18:45這應該是編譯器要做的 不是專案管理工具要做的

Linux有很多32bits->64bits擴展帶來的問題,編譯器在制定的時候根本POSIX還沒定這些 據說solaris有很多這種類,要接受業界有很多設備不能更換。

※ 編輯: hizuki (192.147.44.15 美國), 03/15/2023 18:47:55

superpandal03/15 18:45要做的

superpandal03/15 18:54還是要改編譯器 本來就很多選項不是標準

superpandal03/15 18:57給編譯器分析就很好 連專案管理都這樣搞就魔怔了

superpandal03/15 18:57就入魔了

MTKer556603/15 19:15幸好我不再寫code了

projectb03/15 19:34Qmake:

e1251816633903/15 20:27雖然我這麼覺得,但是gnu相關的lib都還是用makefile

e1251816633903/15 20:27為大宗,工作上根本躲不掉

mmonkeyboyy03/16 04:06推樓上 = =" 根本躲不掉....

一般只有toolchains需要,這個只有bootstrap做一次。當然你要改什麼utils當我沒講

mmonkeyboyy03/16 04:07一堆HPC應用....下面也是make 手刻在那裡搞

我正好是做graphics的

Bencrie03/16 08:56GNU 是老牌 autotools 系列吧

superpandal03/16 09:32makefile是makefile gnu autotool和cmake是一類東

superpandal03/16 09:33cmake是一類東西

superpandal03/16 09:33然後都是再自創一個dsl把簡單複雜化

superpandal03/16 09:35最終目標也都是生成makefile

superpandal03/16 09:39基本上你寫個腳本也叫cmake 針對專案文件

superpandal03/16 09:40件也做差不多的事情結果也差不多

superpandal03/16 09:41不用額外裝一堆東西是好處

superpandal03/16 09:44然後腳本也佔不了幾k容量

superpandal03/16 10:00至於純寫makefile也不是不可以 只是架構要精美

superpandal03/16 10:00要精美

peterbrucele03/16 15:08推e大 後人總是跟據前面問題開發新工具 但更多時候

peterbrucele03/16 15:08舊系統無法遷移

ztdxqa03/16 16:39驚 原來現在還有沒用Bazel的嗎?2017年入職轉到現在三個

ztdxqa03/16 16:39公司都是用Bazel

superpandal03/16 17:48bazel更扯 連java都裝上了 那跑起來很恐佈

superpandal03/16 17:50佈 大機率是某個java派主導的 看了一下優點...

tensorflow是逃不掉的,語法真的很可怕。所幸lite改cmake了

superpandal03/16 17:53優點 這就... makefile都可以include 雖然動態性

superpandal03/16 17:54然動態性不是太好 但節省設定是可以的

Google就是愛推。但是Google這個渣男,Android又推go plugin(soong)來生成構建規則, 而Android app卻又是gradle那一套。

superpandal03/16 17:55再搭其它小工具如ccache就可以了

superpandal03/16 17:55即便沒有cache也是編譯有改的

superpandal03/16 17:57拿來管理java專案或許不錯

richer660503/16 19:26推推 只知道makefile 看了文章覺得長知識

superpandal03/16 20:55這是長常識 千言萬語抵不過體驗

superpandal03/16 20:57現在看來很多工具真的意義不大

superpandal03/16 20:58繼續遵守unix原教旨

我很想把這個KISS趕走

OnlyRD03/17 02:11cmake有很難用?我覺得modern cmake其實還可以。

mmonkeyboyy03/17 05:53樓上你老了 (上次我說跟你一樣的話時別人也這樣講我)

modern cmake的問題是沒有阻止舊語法,和C++一樣我弄不清究竟要怎麼寫。 而且cmake真心的慢

※ 編輯: hizuki (192.147.44.15 美國), 03/17/2023 15:00:13

shooter55503/17 16:07mason最煩的是舊環境要支援很麻煩

shooter55503/17 16:07不過現在還是很多專案還在用automake

superpandal03/17 17:08kiss非常好 其實並不傻

superpandal03/17 17:13主要都是cmake又更複雜了 動態性也沒高太多

superpandal03/17 17:15太多 shell更動態 makefile用include也不錯

superpandal03/17 17:16不錯 很多人講不要拿shell搞大工程

superpandal03/17 17:17但其實很熟了也未嘗不可 也有好處

superpandal03/17 17:20當然不是指oneliner