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

16

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

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

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

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

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

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

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

кодировщик
источник
8
+1, я пришел к тому же выводу относительно отладчика Visual Studio; ни одна другая IDE на любой платформе не приблизилась к его возможностям проверки.
Aphex

Ответы:

22

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

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

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

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

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

Чарльз Э. Грант
источник
6
+1, запоминание команд не сложнее, чем запоминание графического интерфейса
Хавьер
5
Обязательно изучите VIM или EMACS. Причина, по которой Linux не имеет графического интерфейса, подобного Visual Studio, заключается в том, что VIM и EMACS имеют все те же функции и многое другое. У меня есть копия VIM, настроенная для использования набора плагинов, которые дают мне автозаполнение с вкладками, фрагментами, навигацией по проекту, встроенным терминалом, тегами, навигацией по тегам, преобразованием пробелов и всем этим резервным копированием в github . На работе я использую Windows, хотя это то, что информация о пути использует в файле vimrc.
Спенсер Рэтбун
2
@Javier В прошлый раз, когда я проверял, GUI отображал много функций на виду, нет необходимости запоминать. Экран VIM лишен каких-либо подсказок или напоминаний.
Quant_Dev
2
@tdammers Я видел достаточно кода Linux в свое время, чтобы позвонить в BS.
Quant_Dev
4
@quant_dev, быстро! Где вы устанавливаете опцию компоновщика, чтобы рассматривать повторяющиеся символы как ошибку? Конечно, вы можете найти его, изучив все элементы в разделе компоновщика свойств C / C ++ проекта, но это не более (или менее) наглядно, чем поиск на странице руководства для компоновщика.
Чарльз Грант
11

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

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

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

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

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

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

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

Сьерд
источник
Может ли downvoter указать, почему он проголосовал?
Sjoerd
Я думаю, потому что ты не отвечаешь на вопрос. Проблема заключается в работе над существующим проектом Linux; сначала перенести его на Windows, а затем обратно - нереальное решение.
tdammers
-1: Если бы это был вариант, у ОП не было бы его первоначальной проблемы. А разработка под Windows берет на себя все затраты на разработку под Windows (например, на ужасную процедуру установки программного обеспечения 18-го века), и вам все равно придется написать Makefile и выполнить перекрестную отладку приложения с помощью gdb, если что-то не является полностью переносимым.
thiton
@tdammers Проверка исходных текстов и создание проекта из * .cpp работает во многих случаях. Даже если на настройку потребуется несколько часов, это намного меньше, чем на изучение совершенно другой среды разработки.
Sjoerd
1
С другой стороны, узнать больше о платформе, над которой вы должны работать, кажется естественным и полезным.
Василий Старынкевич
4

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

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

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

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

mattnz
источник
3
«Ваша проблема много раз решалась в мире Linux, однако, в отличие от инструментов Windows / Microsoft, она не будет передана на серебряной тарелке с гарниром из дополнений». Так что это еще не решено полностью.
Quant_Dev
4
@quant_dev. Правильно или неправильно, это нечасто для части программного обеспечения Linux, чтобы быть всем для каждого пользователя. Чаще встречается модель, в которой каждая деталь хорошо справляется со своей задачей, а конечный пользователь собирает то, что ему нужно для решения своих проблем. Для пользователя Windows проблема не считается решенной, для пользователя Linux - кто прав, очевидно, вы думаете, что вы, я не знаю, и большинство пользователей Linux думают, что это так. Это немного грубо, давать мне -1 только потому, что не согласен с тем, как устроен мир.
Mattnz
3

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

Василий Старынкевич
источник
3

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

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

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

Timmah
источник
3

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

1) Makefile'ы болезненны - лучший совет, который я могу вам дать, - это попытаться переключиться на другую систему сборки, если это возможно.

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

3) Для отладки просто придерживайтесь командной строки GDB. Конечно, это довольно далеко от Windbg, когда дело доходит до функций, но для большинства целей это просто хорошо. Графические интерфейсы (ddd, KDbg) были довольно глючными в последний раз, когда я их пробовал, но опять-таки вещи могли измениться :)

Суть в том - да, вам нужно приложить некоторые усилия для обучения, но после этого вы будете столь же продуктивными, как и в Windows.

Неманья Трифунович
источник
Я часто бегаю gdbизнутри emacs(в Linux), и это очень помогает.
Василий Старынкевич
1

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

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

Francesco
источник
0

Отличные ответы. Добавляя к ним,

Когда я сделал этот шаг, я совершил ошибку, пытаясь прыгнуть в код, не проявив должной осмотрительности к системе сборки GNU, которая вернулась ко мне, когда я захотел внести изменения в код. Потратьте пару дней, чтобы понять, как работают инструменты AutoMake / AutoConf / Make, после этого вы очень быстро освоитесь.

Что касается инструментов - Eclipse + CDT / GDB + DDD действительно проделал большой путь.

Субу Шанкара Субраманян
источник
-1

Вот несколько советов, как сделать это проще:

  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 г
ТР1
источник
1
-1 для "написать код в тот же файл": Вы, должно быть, шутите! И как вы можете признать, «даже не пытайтесь обойти код» и по-прежнему настаивать на том, что «GDB хороший отладчик»!
Sjoerd
@sjoerd: Это просто методы, которые мы нашли для правильной работы. Возможно, это не то, что используют другие люди, но они хорошо работают в среде Linux - большие программы обязательно должны использовать большие файлы. Имея 10-летний опыт в программировании, ему больше не нужно разбираться в коде - он уже знает, как работает выполнение программы, и ему не нужна помощь, которую предоставляет пошаговое выполнение кода.
tp1