Единая рабочая среда на нескольких системах (Windows, Linux, Mac)

[Akon]

Собственно, кто как организовывает свою рабочую среду (компиляторы, IDE, и т.д.), если нужно разрабатывать на C++/Qt из под нескольких ОСей, установленных на одной машине. Основными критериями эффективности выступают:
1. Исключение дублирования информации (например, сорцы библиотек - они будут одними и теми же для всех ОСей, или, например, конфигурационные файлы IDE).
2. Быстродействие (т.е., например, использовать прямой доступ к файловой системе, а не через git).

Например (сложный случай), установили мы Android SDK. Там помино бинарей, которые, ес-но, свои под каждую ОСь, есть сорцы и образы Android систем (здоровые ГБ файлы), которые могут быть едиными для всех ОСей. Опять же, произвели какие-нибудь манипуляции с Android SDK из под одной ОСи, желательно иметь эти же манипуляции совершенными и в других ОСях (общие конфиги).

[Racheengel]

Эх, больная и для нас тема....
Решили так.
Сырцы либ лежат в одном репозитории.
Дллки и бинарники отдельно для каждой оси и компилятора в других репах.
На рабочие машины отдельно качаются исходники и отдельно бинарники.
При сборке юзаем qmake, в которых прописаны правила для каждой оси и компиля отдельно для всех либ и инклудов (пути, имена, версии...)
Как то так.

[Igors]

1. Исключение дублирования информации (например, сорцы библиотек - они будут одними и теми же для всех ОСей,

Выглядит весьма логично, но меня всегда останавливало включение "сетевых" файлов в проект.

[vipet]

юзать кросс-платформенный менеджер-билдер проектов, напр. CMake. (А qmake - это имхо слабовато.)

IDE - это вторично и на выбор каждого девелопера. Кому-то vim за малину, кому-то гуевый подавай.

[Racheengel]

cmake, vim... Вообще-то уже 21-й век на дворе

[vipet]

cmake, vim... Вообще-то уже 21-й век на дворе

И?

[Racheengel]

Как бы работать в 21 веке принято в IDE, а не в блокноте
Но это так, оффтоп.

[qate]

Основная система linux (qtcreator, git), основная разработка и отладка в ней
Под венду собирается кросскомпиляцией mingw 
Возможностей qmake+bash хватает
Под android пока только тесты(изучение), но в qtcreator проект собирался и на устройство устанавливался, т.е. процесс сборки похож

[vipet]

Как бы работать в 21 веке принято в IDE, а не в блокноте
Но это так, оффтоп.

vim - это блокнот? это намного мощнее любого GUI-IDE.

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

P.S. Путешествие в увлекательный мир vim'a можно начать, например, с этого: https://www.quora.com/How-can-I-be-a-faster-programmer/answer/Tommy-Ip?srid=oNPp

[Racheengel]

vim - это блокнот? это намного мощнее любого GUI-IDE.

Вы серьезно?
Нет, я понимаю, там, скрипт поправить, питоном поиграться...
Ну а как насчет более трудоемких задач? Рефакторинг, отладка, например?

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

Это спорный момент. Опять же, для питонов-пхп, наверное, непринципиально.
Но C++ проекты, как правило, собираются с помощью конкретных тулчейнов и отлаживаются с учетом тех инструментов, которые предоставляются производителями IDE. Например, Visual Studio. Там отладчик прибит гвоздями к IDE. Какой смысл разработчику использовать что-то другое?

P.S. Путешествие в увлекательный мир vim'a можно начать, например, с этого: https://www.quora.com/How-can-I-be-a-faster-programmer/answer/Tommy-Ip?srid=oNPp

Чисто практический вопрос.
Смотрите, вот есть, допустим, фирма, пишущая софт на C++/Qt. Каким образом переход на vim "с прыжка" улучшит производительность компании? Что там есть такого, что "родная" IDE предоставить не сможет?
(Речь идет о профессиональной разработке, большой отдел, большие проекты, большие деньги - как следствие, "переучивать" людей добро никто не даст).

[qate]

P.S. Путешествие в увлекательный мир vim'a можно начать, например, с этого: https://www.quora.com/How-can-I-be-a-faster-programmer/answer/Tommy-Ip?srid=oNPp

т.е. чтобы довести vim до уровня креатора нужно ставить кучу плагинов, наверно даже чтобы просто мышь подвести к макросу и отобразить его нужен плагин
псевдографика тоже не красит внешний вид, и не сможет тягаться с графикой ибо она "псевдо"
двухрежимность (редактор и команды) vim на любителя, мне не неудобна
если кому нравится vim - я не против, не буду уговаривать на чтото иное, главное чтобы код был написан )
но новичкам vim я не посоветую

соглашусь с тем, что сборка не должна быть привязна к ide, и в qt она и не привязана

[_Bers]

Собственно, кто как организовывает свою рабочую среду (компиляторы, IDE, и т.д.), если нужно разрабатывать на C++/Qt из под нескольких ОСей, установленных на одной машине. Основными критериями эффективности выступают:
1. Исключение дублирования информации (например, сорцы библиотек - они будут одними и теми же для всех ОСей, или, например, конфигурационные файлы IDE).

все как обычно:
родные исходники - в одной репе,
external (готовые сборки сторонних библиотек) - в другой. можно хранить на фтп.
thirdparty (исходники сторонних библиотек) - в третьей.
ресурсы обычно на фтп живут.

и все это выкачивается в какой то рабочий каталог.

система сборки - cmake.
если хочется реально поиметь независимость от IDE.
если не хочется, тогда можно сидеть на qmake.

2. Быстродействие (т.е., например, использовать прямой доступ к файловой системе, а не через git).

этот бред даже комментировать не хочется.