Làm thế nào để giải quyết các dự án Linux / makefile lớn một cách hiệu quả?


16

Tôi đã phát triển các ứng dụng Windows trong C ++ được 10 năm rồi. Và gần đây tôi đã bắt đầu đào sâu vào một số dự án Linux và tôi không thể chịu đựng được việc mình ...

Tôi là một người học nhanh và tôi đã sử dụng Linux như một nền tảng chính trong một thời gian. Và tôi cảm thấy rất thoải mái với shell, các nguyên tắc hệ điều hành và GUI. Nhưng khi phát triển, tôi cảm thấy như mình đã trở lại trường học.

Ngay khi tôi mở một số dự án lớn hơn, tôi bị mắc kẹt. Hầu hết trong số chúng đều dựa trên makefile, vì vậy về cơ bản khi tôi cố điều hướng chúng bằng QT hoặc CodeBlocks, tốt nhất, tôi có thể sử dụng intellisense trên cơ sở mỗi tệp. Và hầu hết các biến thời gian rò rỉ từ phạm vi.

Sau đó, có một công cụ định nghĩa, dường như không tồn tại, hãy thử tham gia một số dự án lớn hơn từ sourceforge, và bạn bị mắc kẹt trong nhiều ngày, bởi vì điều hướng đến các định nghĩa rất khó khăn ... grep -r "this_def" . --include "*.cpp" --include "*.h"có vẻ rất chậm chạp và vụng về.

Và sau đó, gdb gỡ lỗi hoạt động, nhưng bất kể tôi làm gì, có vẻ như đó là năm ánh sáng phía sau trình gỡ lỗi WinDbg hoặc VisualStudio.

Và những điều này đang khiến tôi tuyệt vọng, tôi muốn viết mã, nhưng nó diễn ra rất chậm ... Tôi bắt đầu nghĩ rằng các nhà phát triển Linux học các định nghĩa hàm bằng trái tim và phân tích mã bằng mắt, nhưng tôi không thể tin được vì thế.

Có ai từng trải qua việc này chưa? Có điều gì tôi đang thiếu có thể giúp tôi làm việc hiệu quả hơn không?


8
+1, tôi đã đi đến kết luận tương tự về trình gỡ lỗi Visual Studio; không có IDE nào khác trên bất kỳ nền tảng nào gần với khả năng kiểm tra của nó.
Aphex

Câu trả lời:


22

Thật thú vị, tôi định kỳ có cùng một vấn đề theo hướng ngược lại. Tôi chủ yếu là một lập trình viên UNIX, nhưng tôi định kỳ phải chuyển công cụ sang Windows. Tôi không thể cho bạn biết số lần tôi muốn nhổ tóc vì tôi không thể tìm thấy hộp kiểm thích hợp cho tùy chọn trình biên dịch được chôn trong một trong 35 trang cài đặt ưu tiên cho một dự án. Tôi chỉ muốn mở tệp proj và tự thêm XML.

Di chuyển theo một trong hai hướng, bí mật là phải kiên nhẫn và tìm hiểu công cụ được thiết lập cho nền tảng mà bạn đang cố gắng làm việc. Tất nhiên bạn sẽ nản lòng, nó mới và không quen thuộc, và bạn bị giảm trạng thái người mới lại một lần nữa Không có cách nào để tránh điều này.

Trong trường hợp cụ thể của bạn, có một số công cụ bổ sung mà bạn nên biết. Đầu tiên là DDD , giao diện người dùng GUI cho gdb. Nó không bóng bẩy như Visual Studio, nhưng nó sẽ nắm tay bạn. Tuy nhiên, tôi thực sự khuyên bạn nên cắn viên đạn, và bắt đầu tìm hiểu về phần mở rộng của gdb. Trong thực tế, nếu bạn là người dùng thông thường, sẽ không có nhiều sự khác biệt giữa việc ghi nhớ các lệnh cần nhập so với ghi nhớ hộp thoại nào bạn phải đưa ra để thay đổi cài đặt.

Bạn cũng cần biết về các công cụ như CScopeCTags . Nhiều như bạn có thể cưỡng lại, tôi khuyên bạn nên học VIM hoặc EMACS . Họ tích hợp tốt với các công cụ thẻ tôi vừa đề cập. Nhập gia tùy tục. Bạn có thể tìm thấy các tiện ích mở rộng cho VIM và EMACS sẽ hoàn tất mã cho bạn. Kinh nghiệm của riêng tôi với các công cụ cung cấp hoàn thành mã là có, nó giúp tiết kiệm một số thao tác gõ, nhưng nói chung việc gõ rất dễ dàng. Suy nghĩ là những gì khó khăn. Ý kiến ​​của bạn có thể khác nhau, đặc biệt nếu bạn có hội chứng ống cổ tay.

Đối với thực hiện. Make được thừa nhận là khủng khiếp, nhưng có lẽ bạn sẽ phải mút nó và học nó.


6
+1, ghi nhớ các lệnh không khó hơn ghi nhớ GUI
Javier

5
Chắc chắn học VIM hoặc EMACS. Lý do linux không thực sự có gui như Visual Studio, bởi vì VIM và EMACS có tất cả các tính năng giống nhau và hơn thế nữa. Tôi đã có bản sao VIM của mình được thiết lập để sử dụng một bộ plugin cung cấp cho tôi tự động hoàn thành với tab, đoạn trích, điều hướng dự án, được xây dựng trong thiết bị đầu cuối, thẻ, điều hướng thẻ, chuyển đổi khoảng trắng và toàn bộ mọi thứ sao lưu vào github . Trong công việc tôi sử dụng windows, vì vậy đó là những gì thông tin đường dẫn sử dụng trong tệp vimrc.
Spencer Rathbun

2
@Javier Lần trước tôi đã kiểm tra, GUI hiển thị rất nhiều chức năng trong tầm nhìn rõ ràng, không cần phải ghi nhớ. Màn hình VIM không có bất kỳ gợi ý hoặc lời nhắc nào.
quant_dev

2
@tdammers Tôi đã thấy đủ mã Linux trong thời gian của mình để gọi cho BS về điều đó.
quant_dev

4
@quant_dev, nhanh lên! Nơi nào bạn đặt tùy chọn liên kết để coi các biểu tượng trùng lặp là một lỗi? Chắc chắn, bạn có thể tìm thấy nó bằng cách khám phá tất cả các mục trong phần liên kết của các thuộc tính C / C ++ của dự án, nhưng đó không phải là (hoặc ít hơn) trong tầm nhìn rõ ràng hơn là tìm kiếm nó trong trang man cho trình liên kết.
Charles E. Grant

11

Tôi đã phát triển các ứng dụng Windows trong C ++ được 10 năm rồi. Và gần đây tôi đã bắt đầu đào sâu vào một số dự án Linux và tôi không thể chịu đựng được việc mình ...

Có điều gì tôi đang thiếu có thể giúp tôi làm việc hiệu quả hơn không?

Phát triển trên Windows, triển khai trên Linux.

Điều này bao gồm kiểm tra đơn vị chạy cả trên máy của bạn (Windows) và trên máy chủ xây dựng (Linux).

Là một tác dụng phụ, bạn sẽ học cách viết mã di động.

Một hiệu ứng tích cực khác là việc sử dụng các trình biên dịch khác nhau sẽ tạo ra nhiều cảnh báo hơn và do đó bắt được nhiều lỗi hơn.

CẬP NHẬT : Để tất cả các fanboy Linux hạ thấp câu trả lời này: Tôi không nói rằng mọi người nên phát triển trên Windows! Nhưng sử dụng nền tảng mà bạn biết rất rõ sẽ hiệu quả hơn là dành nhiều thời gian cho việc học một nền tảng mới.


Downvoter có thể vui lòng cho biết tại sao anh ta downvot?
Sjoerd

Tôi đoán là vì bạn không trả lời câu hỏi. Vấn đề đang làm việc trên một dự án linux hiện có ; chuyển nó sang Windows trước rồi quay lại không phải là giải pháp khả thi.
tdammers

-1: Nếu đó là một lựa chọn, OP sẽ không gặp vấn đề ban đầu. Và phát triển trên Windows sẽ mang lại cho bạn tất cả các chi phí phát triển Windows (như quy trình cài đặt phần mềm khủng khiếp từ thế kỷ 18) và bạn vẫn phải viết Makefile và gỡ lỗi chéo ứng dụng của mình bằng gdb, nếu mọi thứ không hoàn toàn di động.
thiton

@tdammers Kiểm tra các nguồn và tạo một dự án từ * .cpp hoạt động trong nhiều trường hợp. Ngay cả khi phải mất một vài giờ để thiết lập, điều đó sẽ ít hơn nhiều so với việc học một môi trường phát triển hoàn chỉnh khác.
Sjoerd

1
Mặt khác, tìm hiểu thêm về nền tảng mà bạn nên làm việc dường như là điều tự nhiên & đáng giá.
Basile Starynkevitch

4

Vấn đề của bạn đã được giải quyết nhiều lần trong thế giới Linux, tuy nhiên, không giống như các công cụ của Windows / Microsoft, nó sẽ không được trao cho một đĩa bạc với một đĩa phụ. Bạn có thể cần phải làm một số công việc để có được nó.

Tôi sử dụng một trình soạn thảo thương mại (Visual Slick Edit, được coi là đắt tiền bởi những người không coi trọng thời gian của họ nhiều như tôi) cho vấn đề chính xác này. Eclipse với plugin CDT là một cách nguồn mở để đi theo hướng rộng lớn. (Không tốt cho tôi vì tôi thường cần hỗ trợ ADA)

Những gì tôi không làm là cố gắng đảo ngược các makefiles thành một loại dự án nào đó. Tôi sử dụng bản dựng của IDE trong các hệ thống và thêm / xóa các tệp theo cách thủ công khi cần. Tôi chắc chắn rằng tôi có thể viết kịch bản lên, nhưng thời gian có lẽ không đáng. Đối với điều này, tôi thấy nhật thực ít sử dụng hơn một chút so với Slickedit (Điều đó có thể dễ dàng (và có lẽ đã thay đổi) kể từ lần cuối tôi nhìn)

Linux có rất nhiều công cụ, những người hiểu rõ về tôi trong tất cả các khía cạnh chỉnh sửa, nó có các tài liệu tra cứu, v.v., chỉ là một đường cong học tập dốc. Tôi chắc chắn Emacs cũng có thể làm tất cả, mặc dù chưa bao giờ sử dụng nó.


3
"Vấn đề của bạn đã được giải quyết nhiều lần trong thế giới Linux, tuy nhiên, không giống như các công cụ Windows / Microsoft, nó sẽ không được trao cho một đĩa bạc với một món ăn phụ." Vì vậy, nó đã không được giải quyết hoàn toàn, sau đó.
quant_dev

4
@quant_dev. Đúng hay sai, không có gì lạ khi một phần mềm Linux cố gắng trở thành tất cả mọi thứ cho mọi người dùng. Thông thường hơn là có mô hình trong đó mỗi phần làm tốt một việc nhỏ và người dùng cuối sẽ lắp ráp những gì anh ta cần để giải quyết vấn đề của mình. Đối với người dùng windows, vấn đề không được coi là đã được giải quyết, đối với người dùng Linux, đó là, ai đúng, rõ ràng bạn nghĩ bạn là, tôi không biết, và hầu hết người dùng Linux nghĩ rằng họ là như vậy. Đó là một chút khắc nghiệt cho tôi -1 chỉ vì không đồng ý với cách thế giới.
mattnz

3

Đối với những gì đáng giá, trên Linux, bạn có các hệ thống xây dựng tốt hơn so với GNU cũ (thường đi kèm với autoconf khủng khiếp ), ví dụ như omake và nhiều hệ thống khác ( cmake, scons...).


3

một đề xuất liên quan đến mức độ tẻ nhạt của nó khi sử dụng grep để tìm kiếm mã: thiết lập bí danh bash trong tệp .bashrc của bạn. Vì vậy, nó chỉ là một lệnh duy nhất:

alias searchCode='find -iname \*.cpp | xargs grep $1'
alias searchCodeHeaders='find -iname \*.h | xargs grep $1'

có lẽ cách tốt hơn để viết lệnh, nhưng ý tưởng là như nhau. Muốn tìm kiếm mã? viết một bí danh gọi là searchCode. Hãy nhớ rằng mặc dù chúng tẻ nhạt và phức tạp, các công cụ unix cũng có thể được sử dụng để làm cho cuộc sống của bạn dễ dàng hơn.


3

2c của tôi là một người đã phát triển C ++ trên cả hai nền tảng và thích cả hai.

1) Makefiles rất đau - lời khuyên tốt nhất tôi có thể cung cấp cho bạn là hãy thử chuyển sang hệ thống xây dựng khác, nếu có thể.

2) Để chỉnh sửa và duyệt mã, có một số công cụ khá hữu ích. Chắc chắn, chúng không được tích hợp, nhưng nó không thực sự quan trọng khi hoàn thành công việc. vim + ctags + grep sẽ giúp bạn đến đó. Tất nhiên, cũng có các IDE, nhưng thật lòng tôi không thích bất cứ thứ gì tôi đã thử: Eclipse + CDT, KDevelop, Code :: Block. Bạn có thể đi đến kết luận khác nhau, mặc dù.

3) Để gỡ lỗi, chỉ cần sử dụng gdb dòng lệnh. Chắc chắn, nó khá đứng sau Windbg khi nói đến các tính năng, nhưng đối với hầu hết các mục đích, nó chỉ tốt. Mặt trước đồ họa (ddd, KDbg) khá lỗi khi lần trước tôi thử chúng, nhưng một lần nữa mọi thứ có thể đã thay đổi :)

Điểm mấu chốt là - vâng, bạn cần nỗ lực học tập, nhưng sau đó bạn sẽ làm việc hiệu quả như trên Windows.


Tôi thường chạy gdbtừ bên trong emacs(trên Linux) và nó giúp ích rất nhiều.
Basile Starynkevitch

1

Đối với tất cả phần còn lại của những lời khuyên tốt mà bạn đã nhận được, tôi muốn thêm một vài liên kết, tương ứng với ackpss .

Chúng nhằm vào các lập trình viên, những người phải đặc biệt quan tâm đến mã nguồn, cố gắng cải thiện grep.


0

Câu trả lời tuyệt vời. Thêm vào chúng,

Khi tôi thực hiện động thái này, lỗi tôi đã làm là cố gắng nhảy vào mã mà không dành sự cẩn trọng cho hệ thống xây dựng GNU, nó quay lại cắn tôi khi tôi muốn thay đổi mã. Hãy dành vài ngày để hiểu cách bộ công cụ AutoMake / AutoConf / Make hoạt động, bạn sẽ rất nhanh chóng sau đó.

Về các công cụ - Eclipse + CDT / GDB + DDD thực sự là một chặng đường dài.


-1

Đây là một số lời khuyên để làm cho nó hoạt động dễ dàng hơn:

  1. Bắt đầu từ đầu. Điều này có nghĩa là trước tiên bạn sẽ sử dụng tập lệnh bash để thay thế tệp tạo tệp, và sau đó tạo tệp đơn giản một khi bạn cần phụ thuộc. Giữ nó đơn giản ngay từ đầu. Makefile của bạn không cần xử lý 15 nền tảng unix khác nhau - chỉ cần làm cho nó biên dịch với các phụ thuộc. (tệp tạo tệp ban đầu của bạn sẽ trông giống như: tất cả: g ++ -o main main.cpp) (ví dụ phức tạp hơn có thể được tìm thấy từ http: //sivut.koti.reeze.fi/~terop/Makefile - khi bắt đầu từ đầu , chỉ cần sao chép tệp vào dự án, thay đổi tên tệp, thư mục mkdir objs, thay đổi libs bạn muốn)
  2. Quên IDE. Nó sẽ chỉ làm cho bạn chậm hơn. Tìm hiểu để đọc mã và ghi nhớ phân cấp tệp của dự án của bạn. Các công cụ dòng lệnh thông thường như 'cd dir' và 'emacs foo.cpp' cần phải tự động đến mức bạn không nghĩ phải gõ hai lần.
  3. Quên đánh dấu cú pháp và intellisense. Nó sẽ không bao giờ hoạt động giống như cách nó hoạt động trên studio hình ảnh, và những gợi ý mà nó đưa ra sẽ chỉ khiến bạn bối rối vì nó khác với những gì bạn đã từng làm. Học cách không dựa vào họ.
  4. Gbb là một trình sửa lỗi tốt. Bạn sẽ nhận được một ngăn xếp cuộc gọi. Thậm chí đừng cố gắng đi vòng quanh mã, nó sẽ không hoạt động tốt. Sử dụng valgrind quá. Điểm dừng cũng tốt, nhưng đừng dựa vào chúng quá nhiều; chỉ hiếm khi được sử dụng với gdb.
  5. Nếu trình biên dịch của bạn là bất cứ điều gì khác ngoài 'tạo' đơn giản trong trình bao, bạn cần suy nghĩ lại về chỉnh sửa-biên dịch-gỡ lỗi-chỉnh sửa-mô-đun.
  6. Đây là một mẹo mà studio trực quan không thể thực hiện: Hiển thị cả tệp tiêu đề và tệp .cpp trên màn hình cùng một lúc - để cả hai có thể nhìn thấy mà không lật giữa chúng bằng các tab. Emacs có thể làm điều đó. Vì vậy, notepad. Visual studio hoặc IDE không thể.
  7. Tìm hiểu keybindings emacs. Nó sẽ làm cho bạn nhanh hơn. Một gợi ý hay là tất cả các phím được đặt rất gần trong bàn phím. Các chuỗi lệnh dài hơn, nhưng vẫn nhanh hơn để nhập chúng.
  8. Có một mẹo dễ dàng để thay thế định nghĩa: viết mã vào cùng một tệp và sử dụng esc- <và Cs :: myfactor trong emacs để tìm hàm bạn muốn. Quá trình sẽ khác nếu bạn đã sử dụng nhiều tệp ngắn - mã của bạn sẽ trông khác. (tìm hiểu ctrl-f trong notepad và bạn sẽ có ý tưởng). Nhưng bạn chắc chắn không cần phải làm điều đó trong vỏ.
  9. Thời gian khởi động trình soạn thảo văn bản là rất quan trọng. Nếu phải mất hơn 1 giây để mở nó, nó không tốt. Mọi IDE đều bị hỏng vì yêu cầu này. Notepad và emacs là ok.
  10. goto-line trong emacs là tính năng quan trọng để lập trình. Ràng buộc nó với một số chìa khóa. Tôi sử dụng Cx g

1
-1 cho "ghi mã vào cùng một tệp": Bạn phải đùa! Và làm thế nào bạn có thể thừa nhận "Thậm chí đừng cố gắng đi vòng quanh mã" và vẫn khăng khăng rằng "Gdb là một trình gỡ lỗi tốt"!
Sjoerd

@sjoerd: Đây chỉ là những kỹ thuật mà chúng tôi thấy hoạt động tốt. Nó có thể không phải là những gì người khác đang sử dụng, nhưng chúng hoạt động tốt trong môi trường linux - các chương trình lớn hơn nhất thiết phải sử dụng các tệp lớn hơn. Với 10 năm kinh nghiệm lập trình, anh ta không còn cần phải đi lại trong mã - anh ta đã biết cách thực hiện chương trình hoạt động và không cần sự trợ giúp mà bước qua mã cung cấp.
tp1
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.