гибридная среда разработки

Question

Переходя от Linux с его чистой иерархией файловой системы к окнам, я хотел бы установить одну или несколько выделенных папок для хранения компиляторов и связанных с ними библиотек, таких как sysfs, что-то вроде sysfs ... я хотел бы найти элегантный способ сделать это.

Я в основном разрабатываю с использованием C / C ++, Java и Python. и даже для проектов на C ++ управление библиотеками, созданными с использованием Visual Studio и Mingw, является проблемой. Я хочу поделиться своим опытом, если вы уже работали над этим вопросом. Вы устанавливаете выделенное дерево разработки для каждого компилятора, например, для архитектуры par (ia32 x86_64 и т. Д.), Или вы просто следуете программе установки, помещая все в программу \ / file и т. Д.?

Заранее спасибо

Answer 1

Это не совсем так, но я нахожусь в процессе конвертации Linux gcc / make в MSVS. Смена парадигмы может быть сложной. Я просто поделюсь прошлой неделей ага ! момент.

MSVS слишком охотно хранит абсолютные имена путей в метаданных проекта, что приводит к разочарованию при попытке, например, перейти на другой компьютер. Функция макроса позволяет указывать различные корневые каталоги символически в таких местах, как дополнительные каталоги include или библиотеки. Используйте их.

Answer 2

Я обычно позволяю VS, Qt / mingw и т. Д. Устанавливать себя там, где они хотели - т.е. я сохраняю настройки по умолчанию. Что касается моего src-code-tree и build-tree, я всегда тратил много времени и думал над их настройкой. Я начинаю с экспериментов с IDE (VS2008 в моем последнем случае), наблюдаю за поведением по умолчанию и только потом проектирую свое src-дерево и без bld. С VS2008 я пока использую относительно простое расположение:

C: \ PRJ \ common_lib_cpp C: \ PRJ \ common_lib_cpp \ lib1 C: \ PRJ \ common_lib_cpp \ lib2 C: \ PRJ \ common_lib_csharp C: \ PRJ \ common_lib_csharp \ lib3 C: \ PRJ \ my_exe_prj1 C: \ PRJ \ my_exe_prj2

Я немного упрощаю, но не сильно. Это работало хорошо для меня в течение 6 месяцев, никаких серьезных проблем. Когда я работал в Nuance некоторое время назад, дерево src было очень тщательно спроектировано, а система сборки на основе make была большой, сложной и надежной. В сборках Windows и Linux (несколько разновидностей) используется одно и то же дерево src. На самом деле это очень сложная задача. У Адриана Нигу (Nuance) были хорошие статьи в блогах и в Интернете по этой теме.

Answer 3

В прошлом я видел такие проекты:

    MyProject \
        docs \
        source\
            includes\
        tests \
        targets \
            gcc\
            xcode\
            vs2008\
            vs2010\
                MyProject\
                Debugx86\
                Debugx64\
                Releasex86\
                Releasex64\

Это позволяет всем компиляторам хранить свои файлы проектов отдельно и использовать один и тот же источник.Это также предотвращает случайную перекрестную связь между компиляторами / архитектурами