CMake vẫn chưa hiểu rõ nhiệm vụ của mình.
(dorinlazar.ro)CMake ngày càng có cảm giác là một giải pháp tệ cho C++. Nó không chỉ không đáp ứng được nhu cầu của các nhà phát triển C++, mà còn khiến họ mắc kẹt trong thời kỳ đen tối của việc tạo makefile theo một cách rất mơ hồ và thiếu cấu trúc bằng một ngôn ngữ thiếu nhất quán.
Vấn đề
Trong thế giới build C++, có hai loại vấn đề.
- Những vấn đề do các dự án hiện có tự tạo ra (ghi chú biên tập: vấn đề khi build các dự án lớn đã tồn tại)
- Những vấn đề gặp phải khi chọn một dự án mới trong C++
CMake cố gắng giải quyết vấn đề thứ nhất, và hoàn toàn không giải quyết được vấn đề thứ hai. Nhưng chính vì không cố giải quyết những vấn đề này nên nó trở thành một công cụ kém hữu ích hơn.
CMake muốn trở thành một trình phiên dịch chuyển định nghĩa dự án thành hệ thống build, và nó đã thất bại nặng nề ở điểm này. Đây là một ngôn ngữ định nghĩa dự án tệ, thiếu nhất quán và không trực quan.
Giờ đây cả cộng đồng C++ đều nói về các công cụ của Rust. Cargo thực sự làm được những gì mà đa số nhà phát triển cho là cần thiết. Cargo tải các phụ thuộc từ Internet để tạo ra một bộ công cụ cô lập (một ý tưởng tệ), và cung cấp các thư viện liên kết tĩnh (cũng là một ý tưởng tệ). Mọi người không cần một công cụ liên tục bổ sung lỗ hổng bảo mật với tốc độ chóng mặt (ghi chú biên tập: tác giả cho rằng cách Cargo tự động lấy mã từ Internet và liên kết có thể trở thành điểm yếu bảo mật như tấn công chuỗi cung ứng. Xem I Hate Rust). Nhưng thứ Cargo thực sự cung cấp là điều người ta cần:
- Cấu trúc dự án cực kỳ chặt chẽ
- Một hệ thống cấu hình rất đơn giản, dựa vào máy chủ bên ngoài để giải quyết vấn đề thư viện nằm ở đâu
- Chỉ một bộ công cụ duy nhất.
Mọi người thực sự cần ít quyền tự do hơn để có thể tập trung vào công việc, và họ không giỏi trong việc gọi compiler theo cách hoàn hảo nhất.
Giải pháp
Hiện vẫn chưa có giải pháp. Tôi đang viết klb vào thời gian rảnh, nhưng lúc này nó chưa phải là giải pháp. (Cần thời gian và tiền bạc.)
Nhưng điều mà mọi người cần thì đã rõ. Không phải nhiều lựa chọn hơn mà là ít lựa chọn hơn. Ít lựa chọn hơn nghĩa là có ít cách hơn để làm hỏng quá trình biên dịch của một dự án.
CMake hiện vẫn là lựa chọn tốt nhất trong thế giới C++, nhưng cũng là điều tệ hại nhất đã xảy ra với C++ trong 20 năm qua. Mọi thứ khác đều đang cải thiện, chỉ có hệ thống build là ngày càng tệ đi.
10 bình luận
Cú pháp hơi bẩn một chút, nhưng rốt cuộc vẫn chưa thấy gì hơn CMake.
Nếu muốn chạy thứ như M4 trong môi trường không phải POSIX thì đau đầu lắm.
Ngay từ đầu tôi đã không thích kiểu môi trường build phải kéo theo lỉnh kỉnh đủ thứ, nên cũng chẳng mặn mà với meson hay scone; còn premake thì lại có cảm giác hơi thiếu chắc chắn, thành ra cuối cùng tôi cứ dùng CMake, không hơn không kém, chỉ cố định nghĩa mã theo cách đơn giản nhất có thể rồi dùng thôi.
Tôi đã vừa chửi vừa dùng CMake suốt một thời gian dài, nhưng đến lúc nhìn lại thì đúng là vẫn không có gì thay thế được CMake. bazel thì đúng là địa ngục... Nếu bắt đầu một dự án mới, có lẽ tôi sẽ cân nhắc meson.
Meson hoặc Bazel thì sao?
Tôi chưa từng dùng cả hai nên cũng không rõ lắm...
Cá nhân tôi thì thích
gprbuildcho các dự án nhỏ nên đang dùng nó.Ngoài CMake thì các cách khác cũng phức tạp như nhau
Ít ra thì còn được cái đa nền tảng.....
Có lẽ vì vậy mà Visual Studio vẫn được ưa chuộng. Vì bạn có thể bắt đầu viết mã ngay lập tức.
Dù vậy, nếu đi sâu vào từng chi tiết thì cũng là chuyện không có hồi kết.
Chỉ cần nhìn thấy CMake thôi là tôi đã muốn nôn rồi...
Tôi nghĩ nên xem CMake không phải là thứ thay thế cho
make, mà là thứ thay thế cho autotools (automake).Dù vậy thì có lẽ nó vẫn tốt hơn chỉ dùng Makefile.
Tháng trước tôi phải phân tích một môi trường build gồm script shell, Perl, biến môi trường của OS và nhiều Makefile rối rắm chằng chịt với nhau, đúng là phát điên.
Nếu cố làm điều gì đó quá chi tiết, bạn sẽ rơi vào một hang thỏ...