推 Apache: 都用Bazel 03/14 15:40
Bazel語法沒法理解，我覺得bazel更像bitbake了。
推 pacino: autoconf 很好用啊 03/14 15:50
大哥，貓王死了啊。九十年代過了
推 tennyleaz: 我常常都用動態DllImport比較懶XD 03/14 16:04
Windows派是吧，多來幾個你試看看，還有你多來幾個C++ ABI
推 labbat: docker 萬用解 03/14 16:18
docker只能幫你準備environment，這些不基本上不用來準備environment的
※ 編輯: hizuki (192.147.44.15 美國), 03/14/2023 16:24:58
→ labbat: 題外話，好奇你引用的那些留言串出自那篇文章呀 03/14 16:27
其實就在本版上面一點，我補上了
推 timmerix: 你這些都還好, 有些公司有自己內部的make系統, 完全沒有 03/14 16:48
→ timmerix: 詳細的使用說明, build報錯只能猜或自己做實驗試 03/14 16:49
有些是拿Makfile改的，那已經夠吐血了。
※ 編輯: hizuki (192.147.44.15 美國), 03/14/2023 17:20:35
→ superpandal: 這不就是專案規範的鍋 靜態的是打包所有object沒錯 03/14 17:28
→ superpandal: object沒錯 用shell不是指在makefile裡用 而是如同co 03/14 17:29
→ superpandal: 用 而是如同configure 但不會是如此糟糕的寫法 03/14 17:30
→ superpandal: 的寫法 makefile本身就不適合動態 而shell 03/14 17:31
→ superpandal: shell很動態 本身還是個web仔就是 03/14 17:32
→ superpandal: 不過如果慢可以多job 或不用c++ XD 03/14 17:44
推 loadingN: 確實 有維護過 舊的Makefile... 03/14 17:47
推 superpandal: 上面那串是表示私下研究覺得相關的都太臃腫 03/14 17:48
→ superpandal: 臃腫 cmake meson都是 03/14 17:49
→ superpandal: 反正我都自己寫shell框架了 03/14 17:51
→ superpandal: cmake本身都是生出makefile或在win下可能是vs專案 03/14 17:56
→ superpandal: 能是vs專案 03/14 17:56
→ superpandal: 躺平的web仔 但shell功力越來越出神入化了 03/14 18:02
→ superpandal: 了 03/14 18:02
Web如果是Java的話，老老實實用maven gradle。我們不需要package management。
我們的環境是要用linker的，麥類比。
推 Bencrie: 我寫的東西不夠大，自己刻 Makefile 還蠻好用的 03/14 19:37
推 gino0717: 我都用qmake 03/14 19:40
→ alongalone: 老哥 你內行的誒... 直接丟出去給別人解就好啦 03/14 23:11
→ Lipraxde: 工具本身設計可能確實是會導致最終變得難用...不過也有 03/14 23:43
→ Lipraxde: 蠻多時候是使用者的問題... 03/14 23:43
推 zetexp: 可以用用看xmake 03/15 00:03
meson已經足夠了，xmake反而是中國式的All in One
推 shomingchang: 我只會用python寫建置腳本 03/15 00:05
setuptool沒有什麼問題
推 mmonkeyboyy: 看大小吧.....殺雞不用牛刀 牛刀也要磨很久啊 03/15 00:41
→ superpandal: 給你倚天劍和屠龍刀你要選哪個？ 都是利器 03/15 01:02
→ superpandal: 器 03/15 01:02
→ k798976869: 手槍：py 03/15 08:22
推 chchwy: 這就是C++的問題 一大堆build tool 03/15 09:39
→ chchwy: 每個人不爽就自己再幹一個 03/15 09:39
所有要構建的語言都是這樣的，這個是project的問題，和語言本身無關。
→ Ekmund: go: tidy 03/15 09:44
→ Ekmund: 你看看光make就可以搞成這樣有多勸退 03/15 09:44
→ Ekmund: 加個自己刻的小lib 重寫makefile後跳undefined reference 03/15 10:06
→ Ekmund: 光linker single-pass的特性就容易變成坑 03/15 10:06
Go聽說升級有造成memory炸掉，這種有GC的語言不是一個生態的
※ 編輯: hizuki (192.147.44.15 美國), 03/15/2023 10:59:36
→ superpandal: 不是類比 只是在說不是在公司用 03/15 17:43
→ superpandal: 畢竟前面一堆講公司如何如何 03/15 17:45
→ superpandal: java目前的確用那兩個 但說實話也是偏靜態的 03/15 17:46
自己硬幹沒有什麼問題，但是項目總是會擴展的，比如cross platform，這個其實算靜態
→ superpandal: 態的 也都可以土法煉鋼 或自己整一個工具 03/15 17:47
→ superpandal: 具 03/15 17:48
→ superpandal: py是手槍？ XD 03/15 17:51
→ superpandal: go還是主要在抓遠端依賴 c讀本機lib 03/15 17:58
→ superpandal: 然而每個系統都不同 比不了 03/15 17:59
→ superpandal: 歷史因素了 但純makefile或小工具生成很簡潔 03/15 18:01
→ 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
→ superpandal: 自己的東西不會考慮非類unix 現在也有 03/15 18:43
→ superpandal: wsl 03/15 18:43
看了筆記寫錯了，那次是讀register段正好在3G外
可以理解，但是真的不鼓勵
※ 編輯: hizuki (192.147.44.15 美國), 03/15/2023 18:45:26
→ superpandal: 這應該是編譯器要做的 不是專案管理工具要做的 03/15 18:45
Linux有很多32bits->64bits擴展帶來的問題，編譯器在制定的時候根本POSIX還沒定這些
據說solaris有很多這種類，要接受業界有很多設備不能更換。
※ 編輯: hizuki (192.147.44.15 美國), 03/15/2023 18:47:55
→ superpandal: 要做的 03/15 18:45
→ superpandal: 還是要改編譯器 本來就很多選項不是標準 03/15 18:54
→ superpandal: 給編譯器分析就很好 連專案管理都這樣搞就魔怔了 03/15 18:57
→ superpandal: 就入魔了 03/15 18:57
→ MTKer5566: 幸好我不再寫code了 03/15 19:15
→ projectb: Qmake: 03/15 19:34
推 e12518166339: 雖然我這麼覺得，但是gnu相關的lib都還是用makefile 03/15 20:27
→ e12518166339: 為大宗，工作上根本躲不掉 03/15 20:27
推 mmonkeyboyy: 推樓上 = =" 根本躲不掉.... 03/16 04:06
一般只有toolchains需要，這個只有bootstrap做一次。當然你要改什麼utils當我沒講
→ mmonkeyboyy: 一堆HPC應用....下面也是make 手刻在那裡搞 03/16 04:07
我正好是做graphics的
推 Bencrie: GNU 是老牌 autotools 系列吧 03/16 08:56
→ superpandal: makefile是makefile gnu autotool和cmake是一類東 03/16 09:32
→ superpandal: cmake是一類東西 03/16 09:33
→ superpandal: 然後都是再自創一個dsl把簡單複雜化 03/16 09:33
→ superpandal: 最終目標也都是生成makefile 03/16 09:35
→ superpandal: 基本上你寫個腳本也叫cmake 針對專案文件 03/16 09:39
→ superpandal: 件也做差不多的事情結果也差不多 03/16 09:40
→ superpandal: 不用額外裝一堆東西是好處 03/16 09:41
→ superpandal: 然後腳本也佔不了幾k容量 03/16 09:44
→ superpandal: 至於純寫makefile也不是不可以 只是架構要精美 03/16 10:00
→ superpandal: 要精美 03/16 10:00
推 peterbrucele: 推e大 後人總是跟據前面問題開發新工具 但更多時候 03/16 15:08
→ peterbrucele: 舊系統無法遷移 03/16 15:08
推 ztdxqa: 驚 原來現在還有沒用Bazel的嗎？2017年入職轉到現在三個 03/16 16:39
→ ztdxqa: 公司都是用Bazel 03/16 16:39
→ superpandal: bazel更扯 連java都裝上了 那跑起來很恐佈 03/16 17:48
→ superpandal: 佈 大機率是某個java派主導的 看了一下優點... 03/16 17:50
tensorflow是逃不掉的，語法真的很可怕。所幸lite改cmake了
→ superpandal: 優點 這就... makefile都可以include 雖然動態性 03/16 17:53
→ superpandal: 然動態性不是太好 但節省設定是可以的 03/16 17:54
Google就是愛推。但是Google這個渣男，Android又推go plugin(soong)來生成構建規則，
而Android app卻又是gradle那一套。
→ superpandal: 再搭其它小工具如ccache就可以了 03/16 17:55
→ superpandal: 即便沒有cache也是編譯有改的 03/16 17:55
→ superpandal: 拿來管理java專案或許不錯 03/16 17:57
推 richer6605: 推推 只知道makefile 看了文章覺得長知識 03/16 19:26
→ superpandal: 這是長常識 千言萬語抵不過體驗 03/16 20:55
→ superpandal: 現在看來很多工具真的意義不大 03/16 20:57
→ superpandal: 繼續遵守unix原教旨 03/16 20:58
我很想把這個KISS趕走
推 OnlyRD: cmake有很難用？我覺得modern cmake其實還可以。 03/17 02:11
推 mmonkeyboyy: 樓上你老了 (上次我說跟你一樣的話時別人也這樣講我) 03/17 05:53
modern cmake的問題是沒有阻止舊語法，和C++一樣我弄不清究竟要怎麼寫。
而且cmake真心的慢
※ 編輯: hizuki (192.147.44.15 美國), 03/17/2023 15:00:13
→ shooter555: mason最煩的是舊環境要支援很麻煩 03/17 16:07
→ shooter555: 不過現在還是很多專案還在用automake 03/17 16:07
→ superpandal: kiss非常好 其實並不傻 03/17 17:08
→ superpandal: 主要都是cmake又更複雜了 動態性也沒高太多 03/17 17:13
→ superpandal: 太多 shell更動態 makefile用include也不錯 03/17 17:15
→ superpandal: 不錯 很多人講不要拿shell搞大工程 03/17 17:16
→ superpandal: 但其實很熟了也未嘗不可 也有好處 03/17 17:17
→ superpandal: 當然不是指oneliner 03/17 17:20
推 CLANNAD: project沒很大的話scons用起來最爽 03/18 18:07
推 Raymond0710: 看了就累 幸好不怎麼寫cpp了... 03/20 17:20
推 shibin: 我目前寫小專案還是用Makefile，遇到的問題都還沒你說的多 03/21 14:12
→ shibin: 真的嚇人 03/21 14:13