Devasa Linux / makefile projelerini etkili bir şekilde nasıl çözebilirim?

10 yıldır C ++ 'da Windows uygulamaları geliştiriyorum. Ve son zamanlarda bazı Linux projelerine girmeye başladım ve ne kadar verimsiz olduğuma dayanamıyorum ...

Ben hızlı öğreniyorum ve Linux'u bir süredir birincil platform olarak kullanıyorum. Kabuk, işletim sistemi ilkeleri ve GUI ile çok rahat hissediyorum. Ama bu kalkınma söz konusu olduğunda, okula geri döndüğümü hissettiriyor.

Daha büyük bir projeyi açar açmaz sıkıştım. Çoğu makefile tabanlıdır, bu yüzden temelde QT veya CodeBlocks ile gezinmeye çalıştığımda, en iyi şekilde, intellisense'i dosya başına bazda kullanabilirim. Ve çoğu zaman değişkenler kapsamdan sızar.

Sonra, var olmayan görünen, tanımlayıcı bir şeyler var, sourceforge'dan daha büyük bir projeye katılmaya çalışın ve günlerce sıkışıp kaldınız, çünkü tanımlara gitmek çok zor ... grep -r "this_def" . --include "*.cpp" --include "*.h"çok yavaş ve sakar görünüyor.

Ve sonra, hata ayıklama, gdb işe yarıyor, ama ne yaparsam yapayım, WinDbg veya VisualStudio hata ayıklayıcısının ışık yılları geride kalmış gibi görünüyor.

Ve bu şeyler beni çaresiz yapıyor, kod yazmak istiyorum, ama çok yavaş gidiyor ... Linux geliştiricilerinin işlev tanımlarını ezbere öğrendiklerini ve kodları gözle analiz ettiklerini düşünmeye başlıyorum, ama inanamıyorum yani.

Kimse bundan geçti mi? Eksik olduğum ve beni daha üretken kılacak bir şey var mı?

İlginçtir ki periyodik olarak aynı problemi ters yönde görüyorum. Öncelikle UNIX kodlayıcıyım, ancak düzenli olarak Windows'a bir şeyler taşımak zorundayım. Bir proje için 35 tercih ayar sayfasından birine gömülü bir derleyici seçeneği için uygun onay kutusunu bulamadığım için size saçlarımı kaç kez çekmek istediğimi söyleyemem. Sadece projeyi açıp XML'i kendim eklemeyi tercih ederim.

Her iki yönde de hareket etmenin sırrı, sabra sahip olmak ve çalışmaya çalıştığınız platform için araç setini öğrenmektir. her şey tekrardan. Bundan kaçınmanın bir yolu yok.

Sizin durumunuzda, bilmeniz gereken bazı ek araçlar vardır. Birincisi DDD , gdb için bir GUI ön ucu. Visual Studio kadar kaygan değil, ama elinizi tutacak. Ancak, gerçekten mermiyi ısırmayı ve gdb'nin ins ve out'larını öğrenmeyi öneririm. Gerçekte, normal bir kullanıcıysanız, hangi komutları yazacağınızı ezberlemekle bir ayarı değiştirmek için hangi iletişim kutusunu açmanız gerektiğini ezberlemek arasında çok fazla fark yoktur.

Ayrıca CScope ve CTag'ler gibi araçları da bilmeniz gerekir . Karşı koyabildiğiniz kadarıyla, VIM veya EMACS öğrenmenizi öneririm . Az önce bahsettiğim etiket araçlarıyla iyi entegre oluyorlar. Roma'da romalılar gibi davran. VIM ve EMACS için kod tamamlama yapacak uzantılar bulabilirsiniz. Kod tamamlama sunan araçlarla ilgili kendi deneyimim, evet, bazı yazım tasarrufu sağlıyor, ancak genel olarak yazmanın kolay olması. Zor olan şey düşünmektir. Fikriniz farklı olabilir, özellikle karpal tünel sendromunuz varsa.

Marka gelince. Yapmak kuşkusuz korkunç, ama muhtemelen sadece emmek ve öğrenmek zorunda kalacaksınız.

10 yıldır C ++ 'da Windows uygulamaları geliştiriyorum. Ve son zamanlarda bazı Linux projelerine girmeye başladım ve ne kadar verimsiz olduğuma dayanamıyorum ...

Eksik olduğum ve beni daha üretken kılacak bir şey var mı?

Windows üzerinde geliştirin, Linux üzerinde dağıtın.

Bu, hem kendi (Windows) makinenizde hem de yapı sunucusunda (Linux) çalışan birim testleri içerir.

Bir yan etki olarak, taşınabilir kod yazmayı öğreneceksiniz.

Bir başka olumlu etki, farklı derleyiciler kullanmanın daha fazla uyarı üretmesi ve böylece daha fazla hata yakalamasıdır.

GÜNCELLEME : Bu cevabı reddeden tüm Linux hayranlarına: Herkesin Windows üzerinde gelişmesi gerektiğini söylemiyorum! Ancak çok iyi bildiğiniz platformu kullanmak, yeni bir platform öğrenmek için çok fazla zaman harcamaktan daha verimlidir .

Sorununuz Linux dünyasında birçok kez çözüldü, ancak Windows / Microsoft araçlarının aksine, ekstra bir garnitür içeren gümüş bir tabağa teslim edilmeyecek. Bunu elde etmek için biraz iş yapmanız gerekebilir.

Bu tam sorun için ticari bir editör (zamanını benim kadar değer vermeyenler tarafından pahalı kabul edilen Visual Slick Edit) kullanıyorum. CDT eklentisi ile tutulma, haklı olarak geniş bir takibe sahip açık kaynak kodlu bir yoldur. (Sık sık ADA desteğine ihtiyacım olduğu için benim için iyi değil)

Yapmadıklarım, bir çeşit projeye makyaj malzemelerini tersine çevirmeye çalışıyor. IDE'nin sistemlerde derlemesini kullanıyorum ve dosyaları gerektiği gibi elle ekleyip kaldırıyorum. Eminim bunu yazabilirim, ama zaman muhtemelen buna değmez. Bunun için tutulmayı Slickedit'ten biraz daha az kullanışlı buldum (Son baktığımdan beri kolayca (ve muhtemelen değişmiş olabilir)

Linux çok çeşitli araçlara sahiptir, vi'nun beni düzenlemenin tüm yönlerinde iyi performans gösterdiğini bilen adamlar, referanslar vb., Sadece dik bir öğrenme eğrisi vardır. Emacs'ın daha önce hiç kullanmamış olmasına rağmen hepsini de yapabileceğinden eminim.

Değer için, Linux'ta düz eski GNU'nun (genellikle korkunç autoconf ile gider) daha iyi bina sistemlerine sahipsiniz , örneğin omake ve diğerleri ( cmake, scons...).

kodu aramak için grep'i ne kadar sıkıcı kullandığına dair bir öneri: .bashrc dosyanızda bash diğer adları ayarlayın. O zaman bu sadece tek bir komut:

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

komutu yazmanın muhtemelen daha iyi yolları vardır, ancak fikir aynıdır. Arama kodu ister misiniz? searchCode adlı bir diğer ad yazın. Sıkıcı ve karmaşık olmalarına rağmen, unix araçlarının da hayatınızı kolaylaştırmak için kullanılabileceğini unutmayın.

Her iki platformda C ++ geliştiren ve her ikisini de seven biri olarak benim 2c.

1) Makefiles acı vericidir - size verebileceğim en iyi tavsiye, mümkünse başka bir yapı sistemine geçmeyi denemektir.

2) Kod düzenleme ve tarama için oldukça kullanışlı bazı araçlar vardır. Tabii, entegre değiller, ama işlerin ne zaman yapıldığı gerçekten önemli değil. vim + ctags + grep sizi oraya götürecek. Tabii ki, IDE'ler de var, ama açıkçası denediğim hiçbir şeyi beğenmedim: Eclipse + CDT, KDevelop, Code :: Block. Yine de farklı bir sonuca varabilirsiniz.

3) Hata ayıklama için, sadece komut satırı gdb'ye sadık kalın. Tabii ki, özellikler söz konusu olduğunda Windbg'nin oldukça gerisindedir, ancak çoğu amaç için gayet iyi. Grafiksel ön uçlar (ddd, KDbg) en son denediğimde oldukça hata yapıyordu, ama yine de işler değişmiş olabilir :)

Sonuç olarak - evet, biraz öğrenme çabası göstermeniz gerekiyor, ancak bundan sonra Windows'ta olduğu kadar üretken olacaksınız.

Zaten aldığınız tüm iyi tavsiyelere, sırasıyla ack ve pss için birkaç bağlantı eklemek istiyorum .

Kaynak kodunu özel olarak önemsemeleri ve grep üzerinde geliştirmeye çalışan programcılara yöneliktir.

Harika cevaplar. Onlara ekleyerek,

Bu hareketi yaptığımda yaptığım hata, kod değişiklikleri yapmak istediğimde beni ısırmaya gelen GNU derleme sistemine gereken özeni göstermeden koda atlamaya çalışmaktı. AutoMake / AutoConf / Tools paketinin nasıl çalıştığını anlamak için birkaç gün geçirin, bundan sonra çok hızlı olacaksınız.

Araçlar ile ilgili olarak - Eclipse + CDT / GDB + DDD gerçekten uzun bir yol kat ediyor.

Daha kolay çalışmasını sağlamak için bazı öneriler:

1. Başlangıçtan başla. Bu, bash betiğini önce bir makefile değiştirme olarak ve daha sonra bağımlılıklara ihtiyacınız olduğunda basit makefiles kullanacağınız anlamına gelir. Başlangıçta basit olsun. Dosyanızın 15 farklı unix platformunu işlemesi gerekmez - sadece bağımlılıklarla derlemesini sağlayın. (ilk dosya dosyanız aşağıdaki gibi görünecektir: all: g ++ -o main main.cpp) (daha karmaşık bir örnek, sıfırdan başlayarak http://sivut.koti.soon.fi/~terop/Makefile adresinde bulunabilir) , dosyayı projeye kopyalayın, dosya adlarını değiştirin, mkdir objs dizini, istediğiniz kütüphaneleri değiştirin)
2. IDE'yi unutun. Sadece seni yavaşlatacak. Kodu okumayı ve projenizin dosya hiyerarşisini hatırlamayı öğrenin. 'Cd dir' ve 'emacs foo.cpp' gibi normal komut satırı araçlarının o kadar otomatik olması gerekir ki iki kez yazmayı düşünmezsiniz.
3. Sözdizimi vurgulamayı ve anlaşılmayı unutun. Asla görsel stüdyo üzerinde çalıştığı gibi çalışmayacak ve verdiği şey sadece sizi şaşırtacak çünkü eskiden olduğundan farklı. Onlara güvenmemeyi öğrenin.
4. GDB iyi bir hata ayıklayıcıdır. Bir çağrı yığını alacaksınız. Kodun etrafında adım atmaya bile çalışmayın, çok iyi çalışmayacak. Valgrind de kullanın. Kesme noktaları da iyidir, ancak onlara çok fazla güvenmeyin; gdb ile nadiren kullanılır.
5. Derlemeniz kabukta basit 'yapmaktan' başka bir şeyse, edit-compile-debug-edit -cycle'ınızı yeniden düşünmeniz gerekir.
6. Visual studio'nun yapamayacağı bir püf noktası: Hem üstbilgi dosyasını hem de .cpp dosyasını aynı anda ekranda göster - böylece her ikisi de sekmelerle aralarında gezinmeden görünür. Emacs bunu yapabilir. Böylece not defteri. Visual studio veya IDE yapamaz.
7. Emacs tuş bağlamalarını öğrenin. Seni hızlandıracak. Güzel bir ipucu, tüm tuşların klavyede çok yakın olması. Komut dizileri daha uzundur, ancak bunları yazmak hala daha hızlıdır.
8. Git tanımına geçmek için kolay bir hile vardır: kodu aynı dosyaya yazın ve istediğiniz işlevi bulmak için emacs içindeki esc- <ve Cs :: myfunction kullanın. Çok sayıda kısa dosya kullandıysanız işlem farklıdır - kodunuz farklı görünecektir. (not defterinde ctrl-f'yi öğrenin ve fikir edinirsiniz). Ama kesinlikle kabukta yapmanıza gerek yok.
9. Metin düzenleyicinin başlangıç ​​zamanı çok önemlidir. Açmak 1 saniyeden uzun sürerse, iyi değil. Bu gereksinim nedeniyle her IDE bozulur. Not defteri ve emacs tamam.
10. emacs içindeki goto-line programlama için önemli bir özelliktir. Bir tuşa bağlayın. Cx g kullanıyorum