Как эффективно решать масштабные проекты Linux / makefile?

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

Я быстро учусь и уже некоторое время использую Linux в качестве основной платформы. И я чувствую себя очень комфортно с оболочкой, принципами ОС и GUI. Но когда дело доходит до развития, мне кажется, что я вернулся в школу.

Как только я открываю какой-то более крупный проект, я застреваю. Большинство из них основаны на make-файлах, поэтому, в основном, когда я пытаюсь перемещаться по ним с помощью QT или CodeBlocks, в лучшем случае я могу использовать intellisense для каждого файла. И большая часть временных переменных вытекает из области видимости.

Затем есть материал для определения, который кажется несуществующим, попробуйте присоединиться к более крупному проекту из sourceforge, и вы застряли на несколько дней, потому что переход к определениям настолько сложен ... grep -r "this_def" . --include "*.cpp" --include "*.h"кажется таким медленным и неуклюжим.

И затем, отладка, GDB работает, но независимо от того, что я делаю, кажется, что он отстает от WinDbg или VisualStudio от световых лет.

И эти вещи приводят меня в отчаяние, я хочу писать код, но все идет так медленно ... Я начинаю думать, что разработчики Linux изучают определения функций наизусть и анализируют код на глаз, но я не могу поверить, что это так.

Кто-нибудь прошел через это? Есть ли что-то, чего мне не хватает, что может сделать меня более продуктивным?

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

Двигаясь в любом направлении, секрет в том, чтобы иметь терпение и изучить набор инструментов для платформы, на которой вы пытаетесь работать. Конечно, вы будете разочарованы, это новое, и это незнакомо, и вы будете переведены в статус новичка снова и снова Нет способа избежать этого.

В вашем конкретном случае есть некоторые дополнительные инструменты, о которых вы должны знать. Первый - DDD , интерфейс GUI для GDB. Это не так гладко, как Visual Studio, но он будет держать вас за руку. Тем не менее, я бы порекомендовал кусать пулю и приступить к изучению тонкостей GDB. По правде говоря, если вы являетесь обычным пользователем, нет большой разницы между запоминанием того, какие команды набирать, и запоминанием того, какое диалоговое окно вы должны вызвать, чтобы изменить настройку.

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

Что касается марки. Make, по общему признанию, ужасен, но вам, вероятно, просто придется смириться с этим и научиться этому.

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

Есть ли что-то, чего мне не хватает, что может сделать меня более продуктивным?

Разработка на Windows, развертывание на Linux.

Это включает в себя запуск модульных тестов как на вашем (Windows) компьютере, так и на сервере сборки (Linux).

В качестве побочного эффекта вы научитесь писать переносимый код.

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

ОБНОВЛЕНИЕ : Всем фанатам Linux, опровергающим этот ответ: я не говорю, что все должны разрабатывать на Windows! Но использование платформы, которую вы очень хорошо знаете, более продуктивно, чем тратить много времени на изучение новой платформы.

Ваша проблема много раз решалась в мире Linux, однако, в отличие от инструментов Windows / Microsoft, она не будет передана на серебряной тарелке с гарниром из дополнений. Возможно, вам придется сделать некоторую работу, чтобы получить его.

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

То, что я не делаю, - это попытка перепроектировать make-файлы в какой-то проект. Я использую встроенную систему IDE и вручную добавляю / удаляю файлы по мере необходимости. Я уверен, что мог бы написать это, но время, наверное, того не стоит. Для этого я обнаружил, что затмение менее пригодно для использования, чем Slickedit (который мог легко (и, вероятно, изменился) измениться с тех пор, как я в последний раз смотрел)

У Linux есть широкий набор инструментов, ребята, которые хорошо знают vi, превосходят меня по всем аспектам редактирования, у него есть поиск ссылок и т. Д., Просто крутая кривая обучения. Я уверен, что Emacs может сделать все это также, хотя никогда не использовал это.

Что бы это ни стоило, в Linux у вас есть лучшие системы сборки, чем в простой старой сборке GNU (которая часто идет с ужасным autoconf ), например, omake и многие другие ( cmake, scons...).

Одно предположение о том, насколько утомительно использовать grep для поиска кода: настройте псевдонимы bash в вашем файле .bashrc. Итак, это всего лишь одна команда:

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

возможно, есть лучшие способы написания команды, но идея та же. Хотите найти код поиска? написать псевдоним под названием searchCode. Помните, что, хотя они утомительны и сложны, инструменты unix также могут быть использованы для облегчения вашей жизни.

Мой 2c как человек, который разработал C ++ на обеих платформах и любит их обоих.

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-скрипт в качестве замены make-файла, а затем простые make-файлы, когда вам понадобятся зависимости. Держите это простым в начале. Ваш make-файл не должен обрабатывать 15 различных Unix-платформ - просто сделайте его компиляцией с зависимостями. (ваш начальный make-файл будет выглядеть так: all: g ++ -o main main.cpp) (более сложный пример можно найти по адресу http://sivut.koti.soon.fi/~terop/Makefile - при запуске с нуля , просто скопируйте файл в проект, измените имена файлов, каталог mkdir objs, измените библиотеки, которые вы хотите)
2. Забудьте IDE. Это только сделает тебя медленнее. Научитесь читать код и помните файловую иерархию вашего проекта. Обычные инструменты командной строки, такие как 'cd dir' и 'emacs foo.cpp', должны быть настолько автоматическими, что вы не подумаете дважды, набрав его.
3. Забудьте подсветку синтаксиса и intellisense. Он никогда не будет работать так же, как в визуальной студии, и намеки, которые он дает, только сбивают вас с толку, поскольку он отличается от того, к чему вы привыкли. Учитесь не полагаться на них.
4. GDB хороший отладчик. Вы получите стек вызовов. Даже не пытайтесь обойти код, он не будет работать очень хорошо. Используйте также valgrind. Точки останова тоже хороши, но не слишком полагайтесь на них; редко используется с GDB.
5. Если ваша компиляция - это что-то еще, кроме простого make в оболочке, вам нужно переосмыслить ваш цикл edit-compile-debug-edit -cycle.
6. Вот трюк, который Visual Studio не может сделать: Показать оба файла заголовка и файл .cpp на экране одновременно - так, чтобы оба были видимы, не переключаясь между ними с помощью вкладок. Emacs может это сделать. Так может блокнот. Visual studio или IDE не могут.
7. Изучите сочетания клавиш Emacs. Это сделает тебя быстрее. Приятный намек на то, что все клавиши расположены очень близко к клавиатуре. Последовательности команд длиннее, но их все же быстрее набирать.
8. Есть простой способ заменить go-to-definition: запишите код в тот же файл и используйте esc- <и Cs :: myfunction в emacs, чтобы найти нужную вам функцию. Процесс отличается, если вы привыкли ко многим коротким файлам - ваш код будет выглядеть по-другому. (изучите ctrl-f в блокноте, и вы поймете идею). Но вам определенно не нужно делать это в оболочке.
9. Время запуска текстового редактора очень важно. Если это займет больше 1 секунды, чтобы открыть его, это не хорошо. Каждый IDE сломан из-за этого требования. Блокнот и Emacs в порядке.
10. Goto-Line в Emacs является важной функцией для программирования. Свяжите это с некоторым ключом. Я использую Cx г