Як ефективно вирішувати масивні проекти Linux / makefile?


16

Я розробляю програми для Windows на C ++ вже 10 років. І останнім часом я почав розкопуватися в деяких проектах Linux, і не можу витримати, наскільки я непродуктивний ...

Я швидко навчаюся, і вже деякий час використовую Linux як основну платформу. І мені дуже комфортно з оболонкою, принципами ОС та графічним інтерфейсом. Але коли мова йде про розвиток, то відчувається, що я знову в школі.

Як тільки я відкриваю якийсь більший проект, я застряг. Більшість з них заснована на makefile, тому в основному, коли я намагаюся орієнтуватися в них за допомогою QT або CodeBlocks, в кращому випадку я можу використовувати intellisense на основі файлу. І більшість змінних часу витікають із сфери застосування.

Потім з’являється матеріал для переходу до визначення, який, здається, не існує, спробуйте приєднатись до якогось більшого проекту від sourceforge, і ви затримаєтесь цілими днями, адже навігація до визначень настільки важка ... grep -r "this_def" . --include "*.cpp" --include "*.h"здається настільки повільною і незграбною.

І тоді, налагодження, gdb працює, але незалежно від того, що я роблю, здається, що за налагоджувачем WinDbg або VisualStudio проходять світлові роки.

І ці речі роблять мене відчайдушним, я хочу написати код, але це йде так повільно ... Я починаю думати, що розробники Linux вивчають визначення функцій напам’ять і аналізують код очима, але я не можу повірити, що це так.

Хтось пережив це? Чи є щось, чого мені не вистачає, що могло б зробити мене більш продуктивною?


8
+1, я дійшов такого ж висновку щодо налагоджувача Visual Studio; жодна інша IDE на будь-якій платформі не наближається до своїх можливостей перевірки.
Афекс

Відповіді:


22

Цікаво, що у мене періодично виникає така ж проблема у зворотному напрямку. Я в першу чергу UNIX-кодер, але періодично мені доводиться надсилати речі до Windows. Я не можу сказати вам, скільки разів я хотів витягнути волосся, тому що не можу знайти відповідний прапорець для параметра компілятора, похованого на одній із 35 сторінок налаштувань уподобань для проекту. Я вважаю за краще просто відкрити файл proj і додати XML сам.

Рухаючись в будь-який бік, секрет - це набратися терпіння та вивчити набір інструментів для платформи, на якій ви намагаєтеся працювати. Звичайно, ви будете розчаровані, це нове, і незнайоме, і ви зведені до статусу новачка Знову і знову. Неможливо цього уникнути.

У вашому конкретному випадку є деякі додаткові інструменти, про які слід пам’ятати. Перший - DDD , передній край GUI для gdb. Це не так гладко, як Visual Studio, але буде тримати вашу руку. Однак я б дуже порекомендував кусати кулю і почати вивчати основні та додаткові можливості gdb. По правді, якщо ви є звичайним користувачем, між запам'ятовуванням команд, які слід вводити проти запам'ятовування, яке діалогове вікно ви повинні підняти, щоб змінити налаштування.

Вам також потрібно знати про такі інструменти, як CScope та CTags . Я б запропонував вивчити VIM або EMACS . Вони добре поєднуються з інструментами тегів, про які я тільки що згадував. Коли в Римі, роби так, як роблять римляни. Ви можете знайти розширення для VIM та EMACS, які виконають завершення коду для вас. Мій власний досвід роботи з інструментами, які пропонують доповнення коду, полягає в тому, що так, це дозволяє заощадити деякий набір тексту, але в цілому введення тексту легко. Думати - це те, що важко. Ваша думка може відрізнятися, особливо якщо у вас синдром зап'ястного каналу.

Що стосується виготовлення. Зробити це, мабуть, жахливо, але вам, мабуть, просто доведеться його висмоктати і навчитися.


6
+1, запам'ятовування команд не складніше, ніж запам'ятовування графічних інтерфейсів
Хав'єр

5
Однозначно вивчіть VIM або EMACS. Причина, що в Linux насправді немає такого типу, як Visual Studio, полягає в тому, що VIM та EMACS мають однакові функції та інше. У мене є копія VIM, налаштована на використання набору плагінів, які дають мені автоматичне завершення з вкладками, фрагментами, навігацією по проекту, вбудованим терміналом, тегами, навігацією тегів, перетворенням білого простору, і все це резервне копіювання до github . На роботі я використовую вікна, тож саме так використовується інформація про шлях у файлі vimrc.
Спенсер Ратбун

2
@Javier Останній раз, коли я перевірив, графічні інтерфейси відображали багато функціональних можливостей просто на очах, не потрібно запам'ятовувати. Екран VIM позбавлений будь-яких натяків чи нагадувань.
Quant_dev

2
@tdammers Я свого часу бачив достатньо коду Linux, щоб зателефонувати на BS.
Quant_dev

4
@quant_dev, швидко! Де ви встановите параметр зв’язувача, щоб дублювати символи як помилку? Звичайно, ви можете знайти його, вивчивши всі елементи в розділі "лінкер" властивостей проекту C / C ++, але це не більше (або менше) на увазі, ніж переглядати його на сторінці "man" для посилання.
Чарльз Е. Грант

11

Я розробляю програми для Windows на C ++ вже 10 років. І останнім часом я почав розкопуватися в деяких проектах Linux, і не можу витримати, наскільки я непродуктивний ...

Чи є щось, чого мені не вистачає, що могло б зробити мене більш продуктивною?

Розробка в Windows, розгортання в Linux.

Сюди входять запуски тестів на власному комп'ютері (Windows) та на сервері збірки (Linux).

Як побічний ефект ви дізнаєтесь, як писати портативний код.

Ще один позитивний ефект полягає в тому, що використання різних компіляторів генерує більше попереджень і, таким чином, виявить більше помилок.

ОНОВЛЕННЯ : Для всіх шанувальників Linux, які підтримують цю відповідь: я не кажу, що всі повинні розвиватися в Windows! Але використання платформи, яку ви добре знаєте, є більш продуктивним, ніж витрачати багато часу на вивчення нової платформи.


Чи міг би проголосити прохання, чому він подав заяву?
Sjoerd

Моя здогадка, тому що ви не відповідаєте на питання. Проблема полягає в роботі над існуючим проектом Linux; спочатку перенести його в Windows, а потім назад - не є прийнятним рішенням.
tdammers

-1: Якби це був варіант, ОП не мала б своєї первісної проблеми. І розвиваючись в Windows, ви отримуєте всі витрати на розробку Windows (як жахлива процедура встановлення програмного забезпечення 18 століття), і вам все одно доведеться написати Makefile і перехрестити свою програму з gdb, якщо щось не є повністю портативним.
титон

@tdammers Перевірка джерел та створення проекту з * .cpp працює у багатьох випадках. Навіть якщо на налаштування піде кілька годин, це набагато менше, ніж знадобиться для вивчення цілком іншого середовища розробки.
Sjoerd

1
З іншого боку, дізнатися більше про платформу, над якою слід працювати, виглядає природним та вартим.
Василь Старинкевич

4

Ваша проблема вже багато разів вирішується в світі Linux, однак, на відміну від інструментів Windows / Microsoft, її не передаватимуть на срібній тарілці з гарніром з допоміжними стравами. Можливо, вам доведеться провести якусь роботу, щоб її отримати.

Я використовую комерційний редактор (Visual Slick Edit, який вважається дорогим тим, хто не цінує свій час так само, як я) для цієї точної проблеми. Eclipse з плагіном CDT - це відкритий вихідний шлях, який має виправдане величезне наступне. (Недоцільно для мене, оскільки мені часто потрібна підтримка ADA)

Що я цього не роблю, намагаюся переробити інженерні файли в якийсь проект. Я використовую вбудований IDE в системах і вручну додаю / видаляю файли за потреби. Я впевнений, що міг би це написати, але часу, мабуть, не варто. Для цього я виявив затемнення трохи менш корисним, ніж Slickedit (Це могло легко (і, ймовірно, змінилося), коли я востаннє подивився)

У Linux є величезний набір інструментів, хлопці, які добре знають мене, виконуючи мене в усіх аспектах редагування, він має пошукові посилання тощо, просто крута крива навчання. Я впевнений, що Emacs може зробити це все добре, хоча ніколи цього не використовував.


3
"Ваша проблема вже багато разів вирішується в світі Linux, однак, на відміну від інструментів Windows / Microsoft, її не передаватимуть на срібній тарілці з гарніром з додатковими приладдями." Тож це ще не вирішено повністю.
Quant_dev

4
@quant_dev. Правильно чи неправильно, нечасто, що частина програмного забезпечення Linux намагається бути всіма речами кожного користувача. Частіше зустрічається модель, де кожен твір добре робить невелику річ, а кінцевий користувач збирає те, що потрібно йому для вирішення своїх проблем. Для користувача Windows проблема не вважається вирішеною, для користувача Linux - це, хто правий, явно ви думаєте, що ви є, я не знаю, і більшість користувачів Linux вважають, що вони є. Це трохи суворо дає мені -1 лише тому, що не згоден з таким, яким є світ.
mattnz


3

одна пропозиція щодо того, наскільки нудно використовувати греп для пошуку коду: налаштувати псевдоніми bash у файлі .bashrc. Тож тоді це лише одна команда:

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

Можливо, є кращі способи написання команди, але ідея така ж. Хочете шукати код? написати псевдонім, який називається searchCode. Пам’ятайте, що, хоча вони нудні і складні, інструменти Unix також можуть бути використані для полегшення вашого життя.


3

Мій 2с як хтось, хто розробив C ++ на обох платформах і подобається їм обом.

1) Makefiles болісний - найкраща порада, яку я можу дати вам, спробуйте перейти на іншу систему складання, якщо це можливо.

2) Для редагування коду та перегляду є кілька досить корисних інструментів. Звичайно, вони не інтегровані, але насправді це не має значення, коли справа доходить до виконання. vim + ctags + grep просто потрапить до вас. Звичайно, є і IDE, але, чесно кажучи, мені нічого не сподобалось: я спробував: Eclipse + CDT, KDevelop, Code :: Block. Ви можете прийти до іншого висновку.

3) Для налагодження просто дотримуйтесь командного рядка gdb. Звичайно, він значно відстає від Windbg, що стосується функцій, але для більшості цілей це просто чудово. Графічні лицьові сторони (ddd, KDbg) були досить баггі в останній раз, коли я їх спробував, але знову все може змінитися :)

Підсумок - так, вам потрібно докласти певних зусиль для навчання, але після цього ви будете настільки ж продуктивними, як і у Windows.


Я часто біжу gdbзсередини emacs(на Linux) і це дуже допомагає.
Василь Старинкевич

1

До всіх інших хороших порад, які ви вже отримали, я хотів би додати пару посилань відповідно на ack та pss .

Вони орієнтовані на програмістів, яким доводиться особливо дбати про вихідний код, намагаючись покращити над grep.


0

Чудові відповіді. Додаючи їх,

Коли я здійснив цей крок, помилка, яку я зробила, намагалася стрибнути в код, не надавши належної уваги системі побудови GNU, яка повернулася, щоб вкусити мене, коли я хотів внести зміни до коду. Витратьте пару днів, щоб зрозуміти, як працює AutoMake / AutoConf / Make set набір інструментів, після цього ви будете дуже швидкими.

Щодо інструментів - Eclipse + CDT / GDB + DDD проходить дійсно довгий шлях.


-1

Ось декілька порад, щоб полегшити роботу:

  1. Почніть з початку. Це означає, що ви спочатку будете використовувати bash-скрипт як заміну makefile, а потім прості файли, коли вам знадобляться залежності. Нехай це буде просто на початку. Ваш makefile не потребує обробки 15 різних платформ Unix - просто змусьте його компілювати залежність. (ваш початковий makefile буде виглядати так: all: g ++ -o main main.cpp) (більш складний приклад можна знайти з http://sivut.koti.soon.fi/~terop/Makefile - коли починається з нуля , просто скопіюйте файл у проект, змініть назви файлів, каталог mkdir objs, змініть потрібні файли)
  2. Забудьте про IDE. Це лише зробить вас повільніше. Навчіться читати код і запам’ятовуйте ієрархію файлів вашого проекту. Звичайні інструменти командного рядка, такі як "cd dir" та "emacs foo.cpp", повинні бути настільки автоматичними, що вам не спадає на думку вводити його двічі.
  3. Забудьте про підсвічування синтаксису та інтелігенцію. Це ніколи не буде працювати так, як це працює у візуальній студії, і натяки, що їх дають, лише збентежать вас, оскільки це відрізняється від того, що ви звикли. Навчіться не покладатися на них.
  4. Gdb - хороший налагоджувач. Ви отримаєте стек дзвінків. Навіть не намагайтеся обіймати код, це не спрацює дуже добре. Використовуйте і valgrind. Точки розриву теж хороші, але не надто покладайтеся на них; лише рідко використовується з gdb.
  5. Якщо ваша компіляція - це щось інше, ніж просте «зробити» в оболонці, вам потрібно переосмислити цикл edit-compile-debug-edit.
  6. Ось хитрість, яку візуальна студія не може зробити: Показуйте одночасно і заголовок, і .cpp-файл на екрані, щоб обидва були видні, не перекладаючи їх між собою вкладками. Emacs може це зробити. Так може блокнот. Візуальна студія або IDE не можуть.
  7. Дізнайтеся про зв'язки клавіш emacs. Це зробить вас швидше. Приємний натяк на те, що всі клавіші розташовані зовсім поруч на клавіатурі. Послідовності команд довші, але все ж швидше набирати їх.
  8. Для заміни переходу до визначення є легкий трюк: запишіть код у той самий файл і використовуйте esc- <і Cs :: myfunction в emacs, щоб знайти потрібну функцію. Процес відрізняється, якщо ви звикли до багатьох коротких файлів - ваш код буде виглядати інакше. (вивчіть ctrl-f в блокноті, і ви отримаєте ідею). Але вам точно не потрібно робити це в оболонці.
  9. Час запуску текстового редактора дуже важливий. Якщо для її відкриття потрібно більше 1 секунди, це не добре. Кожна IDE порушена через цю вимогу. Блокнот і emacs все в порядку.
  10. goto-line в emacs є важливою особливістю для програмування. Прив’яжіть його до якоїсь клавіші. Я використовую Cx g

1
-1 для "запису коду в той самий файл": Ви мусите жартувати! І як ти можеш визнати "Навіть не намагайся обійти код" і все ще наполягаєш на тому, що "Gdb - хороший налагоджувач"!
Sjoerd

@sjoerd: Ми виявили, що ми працюємо належним чином. Можливо, це не те, чим користуються інші люди, але вони добре працюють в середовищі Linux - більші програми обов’язково повинні використовувати великі файли. Маючи 10-річний досвід програмування, йому більше не потрібно вступати в код - він уже знає, як працює виконання програми, і не потребує допомоги, яку надає покроковий код.
tp1
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.