방대한 Linux / makefile 프로젝트를 효과적으로 다루는 방법?

저는 10 년 동안 C ++로 Windows 응용 프로그램을 개발해 왔습니다. 그리고 최근에 일부 Linux 프로젝트를 파헤 치기 시작했는데 비생산적인 모습을 견딜 수 없습니다 ...

저는 빠른 학습자이며 Linux를 기본 플랫폼으로 사용하고 있습니다. 그리고 저는 쉘, OS 원칙 및 GUI에 대해 매우 편안하다고 생각합니다. 그러나 개발에 관해서는 학교에 돌아온 느낌입니다.

더 큰 프로젝트를 열 자마자 멈췄습니다. 대부분은 makefile 기반이므로 기본적으로 QT 또는 CodeBlocks로 탐색하려고 할 때 기껏해야 파일별로 인텔리전스를 사용할 수 있습니다. 그리고 대부분의 시간 변수는 범위에서 누출됩니다.

그런 다음 존재하지 않는 것처럼 보이는 정의로 이동하는 것이 있습니다. 소스 포지에서 더 큰 프로젝트에 참여하려고하면 정의로 이동하는 것이 너무 어렵 기 때문에 며칠 동안 붙어 grep -r "this_def" . --include "*.cpp" --include "*.h"있습니다. 너무 느리고 서투른 것처럼 보입니다.

그런 다음 디버깅, gdb가 작동하지만 내가 무엇을하든 WinDbg 또는 VisualStudio 디버거보다 수년이 뒤 떨어진 것처럼 보입니다.

그리고 이런 것들이 필사적으로 만들고 싶습니다. 코드를 작성하고 싶지만 너무 느립니다 ... Linux 개발자들이 마음으로 함수 정의를 배우고 눈으로 코드를 분석한다고 생각하기 시작했지만, 믿을 수는 없습니다. 그래서.

누구든지 이것을 겪었습니까? 누락 된 부분이있어 생산성을 높일 수 있습니까?

흥미롭게도 나는 주기적으로 반대 방향으로 같은 문제가 있습니다. 저는 주로 UNIX 코더이지만 정기적으로 물건을 Windows로 이식해야합니다. 프로젝트의 환경 설정 페이지 35 개 중 하나에 묻힌 컴파일러 옵션에 대한 적절한 확인란을 찾을 수 없기 때문에 머리카락을 꺼내고 싶었던 횟수를 알 수 없습니다. 오히려 proj 파일을 열고 XML을 직접 추가하고 싶습니다.

어느 방향 으로든, 비밀은 인내심을 갖고 작업하려는 플랫폼에 맞는 도구 세트를 배우는 것입니다. 물론 좌절하고, 새롭고 익숙하지 않으며, 초보자 상태로 줄어 듭니다. 전부 다시. 이것을 피할 방법이 없습니다.

특별한 경우 알아야 할 몇 가지 추가 도구가 있습니다. 첫 번째는 DDD입니다 gdb의 GUI 프론트 엔드 인 입니다. Visual Studio만큼 매끄럽지는 않지만 손을 잡을 수 있습니다. 그러나 실제로 총알을 물고 gdb의 내용을 배우는 것에 대해 설정하는 것이 좋습니다. 사실, 일반 사용자 인 경우 입력 할 명령을 암기하는 것과 설정을 변경하기 위해 가져와야하는 대화 상자를 암기하는 것에는 큰 차이가 없습니다.

또한 CScope 및 CTag 와 같은 도구에 대해 알아야 합니다. 여러분이 저항 할 수있는 한, VIM 또는 EMACS를 배우는 것이 좋습니다 . 방금 언급 한 태그 도구와 잘 통합됩니다. 로마에있을 때 로마인들이하는 것처럼하십시오. 코드 완성을위한 VIM 및 EMACS 용 확장을 찾을 수 있습니다. 코드 완성을 제공하는 도구에 대한 내 자신의 경험은 예, 일부 타이핑을 저장하지만 일반적으로 타이핑이 쉽다는 것입니다. 생각하기가 어렵습니다. 손목 관절 증후군이있는 경우 특히 의견이 다를 수 있습니다.

확인하십시오. Make는 끔찍한 일이지만, 아마도 그것을 빨아 들여서 배워야 할 것입니다.

저는 10 년 동안 C ++로 Windows 응용 프로그램을 개발해 왔습니다. 그리고 최근에 일부 Linux 프로젝트를 파헤 치기 시작했는데 비생산적인 모습을 견딜 수 없습니다 ...

누락 된 부분이있어 생산성을 높일 수 있습니까?

Windows에서 개발하고 Linux에서 배포하십시오.

여기에는 자신의 컴퓨터 (Windows)와 빌드 서버 (Linux)에서 유닛 테스트를 실행하는 것이 포함됩니다.

부작용으로 이식 가능한 코드를 작성하는 방법을 배우게됩니다.

또 다른 긍정적 인 효과는 다른 컴파일러를 사용하면 더 많은 경고를 생성하여 더 많은 버그를 포착한다는 것입니다.

업데이트 :이 답변을 내리는 모든 Linux 팬들에게 : 나는 모든 사람들이 Windows에서 개발해야한다고 말하지 않습니다! 그러나 새로운 플랫폼을 배우는 데 많은 시간을 소비하는 것보다 잘 알고있는 플랫폼을 사용하는 것이 더 생산적 입니다.

Linux 환경에서는 문제가 여러 번 해결되었지만 Windows / Microsoft 도구와 달리 추가 기능이 추가 된 은판에는 제공되지 않습니다. 그것을 얻기 위해 약간의 작업을해야 할 수도 있습니다.

나는이 정확한 문제에 대해 상용 편집기 (Visual Slick Edit, 시간을 중요시하지 않는 사람들은 비싸다고 생각합니다)를 사용합니다. CDT 플러그인을 사용하는 Eclipse는 공개적으로 사용할 수있는 오픈 소스 방법입니다. (나는 종종 ADA 지원이 필요하기 때문에 나에게 좋지 않습니다)

내가하지 않는 것은 makefile을 일종의 프로젝트로 리버스 엔지니어링하려고합니다. 시스템에서 IDE의 빌드를 사용하고 필요에 따라 파일을 수동으로 추가 / 제거합니다. 나는 그것을 스크립트 할 수 있다고 확신하지만 시간은 그만한 가치가 없을 것입니다. 이를 위해 나는 Slickedit보다 식을 조금 덜 사용할 수 있음을 알았습니다 (마지막으로 본 이후로 쉽게 변경되었을 수 있습니다)

리눅스는 방대한 툴을 가지고 있으며, 편집의 모든 측면에서 vi를 능숙하게 알고있는 사람들은 참조 조회 등이 있으며 가파른 학습 곡선입니다. 나는 Emacs가 그것을 사용하지는 않았지만 모든 것을 할 수 있다고 확신합니다.

그것은 가치가 무엇인지, 리눅스에 당신이 더 평범한 구식보다 시스템을 구축 한 내용은 GNU 메이크업 (종종 끔찍한로 이동하는 autoconf를 예를 들어) omake 및 많은 다른 사람 ( cmake, scons...).

grep을 사용하여 코드를 검색하는 것이 지루한 일에 대한 한 가지 제안 : .bashrc 파일에서 bash 별칭을 설정하십시오. 따라서 단일 명령입니다.

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

명령을 작성하는 더 좋은 방법이 있을지 모르지만 아이디어는 동일합니다. 검색 코드를 원하십니까? searchCode라는 별명을 작성하십시오. 지루하고 복잡하지만 유닉스 도구를 사용하면 인생을 더 편하게 할 수 있습니다.

두 플랫폼 모두에서 C ++을 개발하고 둘 다 좋아하는 사람으로서의 2c.

1) Makefile은 고통 스럽습니다. 가능한 한 다른 빌드 시스템으로 전환 해 보는 것이 좋습니다.

2) 코드 편집 및 찾아보기에는 매우 유용한 도구가 있습니다. 물론, 그것들은 통합되어 있지 않지만 일을 끝내는 데는 중요하지 않습니다. vim + ctags + grep는 당신을 거기에 데려다 줄 것입니다. 물론 IDE도 있지만 솔직히 시도한 것은 Eclipse + CDT, KDevelop, Code :: Block입니다. 그러나 다른 결론을 내릴 수도 있습니다.

3) 디버깅을 위해서는 명령 줄 gdb를 고수하십시오. 물론 기능에 관해서는 Windbg보다 상당히 낫지 만 대부분의 경우에는 괜찮습니다. 그래픽 프론트 엔드 (ddd, KDbg)는 내가 마지막으로 시도했을 때 꽤 버그가 있었지만 다시 변경되었을 수 있습니다 :)

결론은-예, 약간의 학습 노력을 기울여야하지만 그 후에는 Windows에서와 마찬가지로 생산성이 높아집니다.

이미받은 나머지 좋은 조언에 각각 ack 및 pss에 몇 개의 링크를 추가하고 싶습니다 .

그들은 grep을 개선하기 위해 소스 코드를 특별히 신경 써야하는 프로그래머를 대상으로합니다.

좋은 답변입니다. 그들에게 추가,

내가이 일을했을 때, 실수는 GNU 빌드 시스템에 대한 실사를주지 않고 코드를 뛰어 넘 으려고했던 것이었다. AutoMake / AutoConf / Make 도구 모음이 작동하는 방식을 이해하는 데 며칠이 걸리면 그 후 매우 빠릅니다.

도구에 관해서-Eclipse + CDT / GDB + DDD는 실제로 먼 길을 갔다.

보다 쉽게 ​​작업 할 수있는 몇 가지 조언이 있습니다.

1. 처음부터 시작하십시오. 즉, bash 스크립트를 먼저 makefile 대체로 사용하고 종속성이 필요하면 간단한 makefile을 사용해야합니다. 처음에는 간단하게 유지하십시오. makefile은 15 가지 유닉스 플랫폼을 다룰 필요가 없습니다. 단지 의존성으로 컴파일하십시오. (초기 makefile은 다음과 같습니다 : all : g ++ -o main main.cpp) (더 복잡한 예제는 처음부터 시작할 때 http://sivut.koti.soon.fi/~terop/Makefile 에서 찾을 수 있습니다. , 파일을 프로젝트에 복사하고 파일 이름 변경, mkdir objs 디렉토리, 원하는 libs 변경)
2. IDE를 잊어 버리십시오. 속도를 늦출뿐입니다. 코드를 읽고 프로젝트의 파일 계층 구조를 기억하십시오. 'cd dir'및 'emacs foo.cpp'와 같은 일반적인 명령 줄 도구는 자동으로 입력해야 두 번 입력하지 않아도됩니다.
3. 구문 강조 및 인텔리전스를 잊어 버리십시오. Visual Studio에서 작동하는 것과 같은 방식으로 작동하지 않으며 제공하는 힌트는 예전과 다르기 때문에 혼란을 줄 것입니다. 그들에게 의존하지 않는 법을 배우십시오.
4. Gdb는 좋은 디버거입니다. 당신은 호출 스택을 얻을 것이다. 코드를 밟아 보지 않아도 잘 작동하지 않습니다. 발 그린 드도 사용하십시오. 중단 점도 좋지만 너무 의존하지 마십시오. gdb에는 거의 사용되지 않습니다.
5. 컴파일이 쉘에서 단순한 'make'이외의 것이라면, edit-compile-debug-edit -cycle을 다시 생각해야합니다.
6. Visual Studio가 할 수없는 요령은 다음과 같습니다. 헤더 파일과 .cpp 파일을 동시에 화면에 표시하여 탭으로 전환하지 않고도 볼 수 있습니다. 이맥스가 할 수 있습니다. 메모장도 가능합니다. Visual Studio 또는 IDE로는 불가능합니다.
7. emacs 키 바인딩을 배우십시오. 더 빨라질 것입니다. 좋은 힌트는 모든 키가 키보드 근처에 있다는 것입니다. 명령 순서는 더 길지만 입력하는 것이 더 빠릅니다.
8. Go-to-definition을 대체하는 쉬운 방법이 있습니다. 코드를 동일한 파일에 작성하고 emacs에서 esc- <및 Cs :: myfunction을 사용하여 원하는 기능을 찾으십시오. 짧은 파일을 많이 사용했다면 프로세스가 달라집니다. 코드가 다르게 보일 것입니다. 메모장에서 ctrl-f를 배우면 아이디어를 얻을 수 있습니다. 그러나 쉘에서 반드시 할 필요는 없습니다.
9. 텍스트 편집기 시작 시간이 매우 중요합니다. 열 때 1 초 이상 걸리면 좋지 않습니다. 이 요구 사항으로 인해 모든 IDE가 손상되었습니다. 메모장과 이맥스가 정상입니다.
10. emacs의 goto-line은 프로그래밍에 중요한 기능입니다. 키에 묶습니다. 나는 Cx g를 사용한다