Comments 24
Последнее, что я сделал — отказался от ccache. В моем случае, он давал задержку примерно в секунду. Да, если подходящий файл найден, это ускоряет сборку. Но такое не часто случается, когда ты пишешь новый код.
ccache больше подходит не для случая, если вы занимаетесь разработкой, а для случая, если это build-сервер, который собирает десятки-сотни-тысячи проектов регулярно и не все из них изменяются.
Или если у вас source-based дистрибутив linux, например gentoo.
А так системы сборки, умеющие «инкрементально» дают намного больше пользы
Почему бы не использовать Xcode?
Потому что автор использует Linux. Ещё многим просто не нравится Xcode, не поверите :)
Зато многие отговаривали. В общем, имидж у него не очень :)
Там есть большая подляна.
Вроде всё подсвечивается и собирается (можно из проекта CMake, на котором живёт CLion создать билд-солюшн XCode, и даже открыть его...)
Но! Как только пытаешься редактировать новый код, Он через мгновение очухивается и говорит: а… это не Objective C? Ну тогда я умываю руки… И отключает множество фичей, вроде подсказок и т.д.
Это какая-то проблема именно при импорте CMake? Какая версия Xcode?
Это какая-то проблема с C++. Когда я работал над проектом под macOS, в котором портируемое между системами ядро было написано на C++, поддержка его была довольно урезанной. Потому как это было давно, уже точно и не вспомню, что конкретно там было вырезано, но в итоге выяснилось, что со всеми задачами, кроме рисования интерфейса, гораздо лучше справляется AppCode.
Вчера сделал проект на C++ в свежем Xcode — подсказки и всё прочее работает. Судить о новом Xcode по какому-нибудь Xcode времён Objective-C как-то странно.
Так всё, что вы сказали, у меня работало. А вот рефакторинга не было, и это было печально. Речь идёт об Xcode образца зимы этого года.
Вот выбрал класс, нажал меню — Refactor -> Rename, Extract, Create Superclass и так далее, чего не хватает?
Занятно, мне он упорно утверждал, что "Xcode can only refactor C and Objective-C code"
Сорри, действительно есть такое. Тем не менее в 9-м уже всё должно быть.
А вообще надеюсь, что скоро сможем ninja поддержать как генератор в CLion/CMake.
Как-то все схематично описано, часть контекста очевидного автору мне совершенно непонятна.
Например,
Его плагины творят чудеса, можно настроить autocomplete, просмотр иерархии классов, быстрый >переход к определению или поиск, в общем всё, что должны уметь IDE, там можно поднять. Боль >приходит в тот момент, когда ты пытаешься установить и освоить новый плагин. Это всё >заводится не везде и не всегда, и, зачастую, жрет проц и память похлеще любой java.
Сколько машин у автора и зачем на них перенастраивать каждый день YouCompleteMe?
До этого, я пользовался библиотеками, которые поставляются в пакетах вместе ОС. С CLion мне >бы пришлось все заголовочные файлы ОС закидывать к себе на Mac, чего категорически не >хотелось
А зачем это вообще нужно? Почему не собрать для mac os x, протестировать на нем,
а потом отправить патч в CI для тестирования на linux. Все-таки системы (mac os x и linux) очень близки в плане API для серверного ПО.
Мне не улыбалось каждый раз, когда я синхронизирую свой код из репозитория или вливаю его >обратно, добавлять/удалять дополнительный Target в CMakeLists.txt, как мне советовали. Хотелось >иметь возможность склонировать любой проект и тут же собраться без танцев с бубном.
Почему не (псевдокод)
if(DEFINED ENV{LOCAL_EXT})
include(${LOCAL_EXT})
endif()?
выставили бы один раз в ~/.basrc путь до нужного скрипта добавляющего нужный
вам target и горя не знали
Попутно померил время сборки через ninja против стандартного make — разница вышла практически вдвое. Правда CLion требует собираться именно через make, иначе, прощайте подсказки. Пришлось прогонять сборку дважды, один раз через make, для CLion, второй — через ninja
Т.е. вместо 2X время сборки увеличилось до 3X, а ради чего?
macOS — это FreeBSD, а это совсем не linux. Например, там нет proc, абсолютно другая логика работы с shared library ну и еще по мелочам, которые, тем не менее, вполне могут испортить жизнь. + я не люблю засорять собственную ОС, предпочитая работать через chroot, virtualbox или docker.
Потому что, это, как ни крути, изменения проекта чисто под себя, чего я делать не хотел.
Возможно я не совсем точно сформулировал мысль. Да, при добавлении новый файлов cmake отрабатывает дольше, за счет двойной работы. Но это небольшая плата за возможность экономить 50% времени, при отладке.
ЗЫ
Я не против vim, до сих пор кое что правлю в нем. Его, в отличие от CLion, можно легко запустить удаленно. Он быстрее грузится. Глупо открывать проект в CLion, чтобы поправить пару строк :)
У меня есть конфиг для vim, который я, как правило, просто копировал на новое место (+установка некоторого количества плагинов, типа YCM)
Так в этом и вопрос, ноутбуков с ретиной слишком много? Сколько раз нужно перенастраивать чтобы почувствовать боль и желание что-то изменить, я думаю ноутбуков с ретиной должно быть штук 10?
Как правило проблемы начинаются, когда требуется сложная навигация между файлами. >Попробуйте поискать какое-нибудь имя по всему проекту? grep?
:! find . -name x
:! grep -r x *или просто открыть директорию в буфере и начать путешествие
как в обычном файловом менеджере,
по-моему при условии забытого сочетания клавиш намного быстрее
чем в любой IDE, а если сочетание клавиш помнишь то одинаково быстро
в любом редакторе/IDE.
macOS — это FreeBSD, а это совсем не linux. Например, там нет proc, абсолютно другая логика работы с shared library ну и еще по мелочам, которые, тем не менее, вполне могут испортить жизнь.
я знаю, а еще там kqueue вместо epoll, и что? действительно пишете софт который читает /proc, причем каждый день, никаких кроссплатформенных оберток которые прячут эти различия?
я не люблю засорять собственную ОС, предпочитая работать через chroot, virtualbox или docker.
да, пакетные менеджеры под mac os не настолько крутые как под linux,
но они есть и неплохо работают, зачем засорять-то?
Повторюсь, vim мне нравится, я им пользуюсь. Но, например, межфайловая навигация в нем — ужасна. Копирование через буфер обмена — тоже та еще рулетка. Нет, всё решаемо, но требует определенного напряжения.
Да, я пишу софт для настройки этой самой ОС и обертки тут не всегда помогают. Отсюда же нежелание запускать что-либо на своей ОС — можно поиметь кучу лишнего геморроя. Даже, когда вместо Mac у меня был Linux, я так не делал.
В процессе экспериментов в ОС скапливается туча ненужных пакетов и каких-то настроек. Создается неповторимое окружение, которое порождает неповторимые сборки (про запуск я вообще молчу). Это как раз тот случай, когда только у разработчика «всё работает».
В NetBeans из коробки есть поддержка сценариев «хочу работать из локальной IDE с проектом, который лежит за тридевять земель и собирать его (само-собой) под ОС удалённой машины».
Она называется Remote Development. Небольшое описание здесь [1] и про виды этого Remote Development здесь [2] (отличаются способы доступа к сорцам проекта: можно настроить авто-синхронизацию, можно использовать более щадящий режим, когда машины видят друг друга через NFS/SMB/...).
Собственно, Docker и Conan в этой связке становится не нужен. Поддержка ninja тоже есть из коробки, достаточно указать директорию с build.ninja при создании C/C++ Project With Existing Sources.
[1] https://netbeans.org/kb/docs/cnd/remotedev-tutorial.html
[2] https://netbeans.org/kb/docs/cnd/remote-modes.html
Как я варил CLion