Здравствуйте, Nik_1, Вы писали:

N_>Это специфично для каждого проекта. Если в приложении есть иконки — хранятся в репозитории. Есть разные картинки, звуки и т.п. — тудаже. Набор хранимых в репозитории типов файлов специфичен для разных проектов.

Я спрашиваю про файлы отвечающие за сборку проекта (аналог makefile). Что конкретно храните и как хранимое мержите. Вот представь проект без иконок и ресурсов, только один cpp с функцией main, что нужно положить в репозиторий, чтобы на другом компьютере сбилдить?

Здравствуйте, Ytz, Вы писали:

Ytz>Здравствуйте, Nik_1, Вы писали:

N_>>Это специфично для каждого проекта. Если в приложении есть иконки — хранятся в репозитории. Есть разные картинки, звуки и т.п. — тудаже. Набор хранимых в репозитории типов файлов специфичен для разных проектов.

Ytz>Я спрашиваю про файлы отвечающие за сборку проекта (аналог makefile). Что конкретно храните и как хранимое мержите. Вот представь проект без иконок и ресурсов, только один cpp с функцией main, что нужно положить в репозиторий, чтобы на другом компьютере сбилдить?
.vcproj
Это обычный текстовый xml файл, если используется нормальная система контроля версий и изменения сделаны только в разных местах — безпроблем мержится.

Здравствуйте, Nik_1, Вы писали:

N_>Здравствуйте, Ytz, Вы писали:

Ytz>>Здравствуйте, Nik_1, Вы писали:

N_>>>Это специфично для каждого проекта. Если в приложении есть иконки — хранятся в репозитории. Есть разные картинки, звуки и т.п. — тудаже. Набор хранимых в репозитории типов файлов специфичен для разных проектов.

Ytz>>Я спрашиваю про файлы отвечающие за сборку проекта (аналог makefile). Что конкретно храните и как хранимое мержите. Вот представь проект без иконок и ресурсов, только один cpp с функцией main, что нужно положить в репозиторий, чтобы на другом компьютере сбилдить?
N_>.vcproj
N_>Это обычный текстовый xml файл, если используется нормальная система контроля версий и изменения сделаны только в разных местах — безпроблем мержится.

Понял. Для простых проектов, должно работать.

Здравствуйте, Privalov, Вы писали:

P>Здравствуйте, Sheridan, Вы писали:

S>>Это у вас в виндах одна ИДЕ. И есть смысл ее проектные файлы выкладывать, ибо без них и не соберешь какбы.

P>Какая одна? Eclipse? NetBeans? Code::Blocks? IDEA? Или я что-то пропустил? QT Creator, наверное?
Есть ещё дедушка SunOne Studio.

Здравствуйте, Ytz, Вы писали:

Ytz>Здравствуйте, Wissenschaftler, Вы писали:

W>>Здравствуйте, Ytz, Вы писали:

Ytz>>>Здравствуйте, Nik_1, Вы писали:

N_>>>>Хз как в линуксе, а в студии это очень даже легко и удобно делается. И платформу выбираешь из комбобокса( как и вариант сборки).

Ytz>>>А какие из проектных файлов создаваемых студией ты хранишь в репозитории, как организована совместная работа? Ты же ведь не студент одиночка?
W>>Все кроме
W>>Debug\*, Release\* (бинарные файлы)
W>>*.ncb (большаааая база данных IntelliSense, по сути распарсенные инклуды из всего проекта и Platform SDK)
W>>*.user (локальные настройки типа адреса последней машины, использовавшейся для удаленной отладки)
W>>*.suo (снапшот состояния окон, открывающий все окошки-панельки 1-в-1 в том виде, в котором они были при закрытии проекта)
W>>Эти правила были ОДИН РАЗ прописаны в глобальном игнор-листе SVN и всё. Добавление проектов теперь состоит в выборе TortoiseSVN->Add.
W>>Что, кстати, гораздо удобнее Eclipse с его неперевариваемым .metadata

Ytz>Понял, что хранить не надо, а что надо?
Все остальное. Исходники + sln + vcproj.
Ytz>Как мержить?
Дык XML.

Здравствуйте, Aleх, Вы писали:

A>Вот, например, я скачиваю опенсорс проект на Java.
A>НО как, КАК? Мне из этой кучи скриптов и мейкфайлов создать проект для Эклипса?

IDEA цепляет pom.xml как проектный файл и не требует импорта проекта. Очень удобно.

Здравствуйте, jazzer, Вы писали:

J>Но мой блокнот (как и Emacs, как и VIM) умеют запускать эту команду для компиляции по горячей клавише и выводить сообщения об ошибках и прочем в отдельное окошко этого же блокнота, из которого ты можешь прыгать с ошибки на соответствующую строчку кода.

Собрат по разуму! Скажи как ты приучил nedit на строчку с ошибкой прыгать!

Здравствуйте, alpha21264, Вы писали:

A>Здравствуйте, jazzer, Вы писали:

J>>Но мой блокнот (как и Emacs, как и VIM) умеют запускать эту команду для компиляции по горячей клавише и выводить сообщения об ошибках и прочем в отдельное окошко этого же блокнота, из которого ты можешь прыгать с ошибки на соответствующую строчку кода.

A>Собрат по разуму! Скажи как ты приучил nedit на строчку с ошибкой прыгать!

есть такой пакет макросов от Frank Perbet, называется macro kit. Там много вкусностей, в том числе эта.

You will always get what you always got
  If you always do  what you always did

Здравствуйте, Aleх, Вы писали:

B>>Скажите, это действительно так? Зачем же быть такими мазахистами?

A>Visual Basic это просто другой язык. То есть ты в своей аналогии сравниваешь два языка. Два однотипных объекта.
A>А я сравниваю подходы которые существенно различаются. Ну это примерно как считать вручную по логарифмической линейке и использовать калькулятор.

Так ты это серьезно писал?? о_О

Здравствуйте, azzx, Вы писали:

A>А по ночам, в полнолуние, они выходят на улицу... и ищут того, что так интересно расположил и поименовал каталоги в дефолтно создаваемых проектах в студии.

Ррррррр!!!
Уууууу!!!!

<хрусь-хрусь-хрусь>

Здравствуйте, x-code, Вы писали:

XC>А мораль такова: если бы мейкфайлы и/или файлы проектов были включены в стандарт языка, и их формат был бы жестко документирован в тех же документах, что и сам язык — этого зоопарка бы не было, и ВСЕ(!!!) IDE и компиляторы были бы вынуждены работать с единым форматом проекта. Но увы, до этого еще никто не додумался, кроме меня И даже в Visual Studio с каждой новой версией будет появляться новый формат проекта, почему-то несовместимый со всеми предыдущими.

Скорее всего, Вы об этом в курсе. И тем не менее.
Вполне успешно перекидывал проекты-солюшены между VS2005 и VS2008 правкой пары строчек. Правда, там был шарп и сравнительно простой проект.
Но я, честно говоря, тоже ни в зуб ногой, почему MS целенаправленно не делает кросс-поддержку своих проектов между релизами студии. А несовместимость там в районе маркера "сделано для VSXXXX"

Здравствуйте, Aleх, Вы писали:

A>Я вот одного не понимаю. Программисты под линукс вообще используют среду разработки?
A>Не редактор кода, а именно СРЕДУ РАЗРАБОТКИ.
сижу, программирую под линух. сижу под виндой. переползаю на мак. разницы не заметил. командная строка есть. svn/git есть. отладчик -- отладочная печать и питон для анализа логов. редактор -- пока решил остановится на vim. пробовал macromates -- его пилить и пилить. пощупал xcode -- парные скобки не хочет подсвечивать сволочь, а я к этому уже привык.

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

Здравствуйте, мыщъх, Вы писали:

М>а что вам нужно от среды? просто интересно.

Чтобы ошибки на лету подсвечивала, warnings, TODOs, bad coding practices тоже неплохо;
code completion;
документация по методу под курсором одной клавишей и список параметров когда внутри скобок;
встроенный отладчик со всеми причиндалами;
для больших файлов — панель структуры модуля (иерархический список классов/методов/вложенных их же) с навигацией;
мало ли...

Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, мыщъх, Вы писали:

М>>а что вам нужно от среды? просто интересно.

D>Чтобы ошибки на лету подсвечивала,
у вас так много ошибок? а что за ошибки? ошибки в ключевых словах подвечивает и текстовой редактор, он же подсвечивает непарные скобки и делает еще много чего... ошибки компиляции видны только после компиляции, причем не факт, что используемый компилятор их покажет. ms vc даже с /w4 не показывает много того что показывает gcc

D> warnings, TODOs,
TODO посвечиваются по общим правилам подсветки, т.е. выделяются так как вам надо. ну и быстрый переход по всем TODO и FIXIT -- для редактора совсем несложная работа. интеграции с чем либо тут не требуется.

D>code completion;
ищу где его отключить в макроматесах и x-code. невозможно же работать с этой штукой (возможно, потому что не привык).

D>документация по методу под курсором одной клавишей и список параметров когда внутри скобок;
интеграция с документацией в текстовых редакторах делается легко. параметры внутри скобок лично у меня вызывают тошноту и я сразу же ищу как их отключить (впрочем, тут дело привычки)

D>встроенный отладчик со всеми причиндалами;
везет же. у вас такие задачи, которые можно отлаживать... хотя бы в принципе... а вот FMS уже отлаживать смысла нет и нужно прикручивать отладочную печать самостоятельно. отладчик тут бесполезен на 100%.

D>для больших файлов — панель структуры модуля (иерархический список классов/методов/вложенных их же) с навигацией;
практически все, о чем вы говорите, и ИДЕ (т.е. интеграции) не имеет никакого отношения и относится исключительно к редактору. разве что отладчик... но многие люди обходятся и без него. мне лече прямо в редакторе задать точку останова со сложным условием, выполняемую на строго определенной итерации (и она сохранится в системе контроля версий) и это так же делается любым редактором, хоть "блокнотом".

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

Здравствуйте, мыщъх, Вы писали:

М>так что привычка великая штука. мне для программирования хватает нетбука и мне что вынь, что мак, что никсы, т.к. перед глазами текстовой редактор.

То что вы привыкли к чему-то, не значит что это эффективно. IDE это уже давно не просто редактор.

Здравствуйте, Danchik, Вы писали:

D>Здравствуйте, мыщъх, Вы писали:

М>>так что привычка великая штука. мне для программирования хватает нетбука и мне что вынь, что мак, что никсы, т.к. перед глазами текстовой редактор.

D>То что вы привыкли к чему-то, не значит что это эффективно.

разумеется, не значит. но отладчик (независимо от степени его итегрированности) покрывает меньше сценариев, чем логгер + скрипт для обработки результатов логгирования. но даже если использовать отладчик. в чем смысл его итеграции? запуск одной кнопкой? такое даже самый примитивный редактор может. обеспечить. в чем эффективность интеграции? в чем неэффективность использования различных инструментов? как раз ide обычно устроено по принципу дешево и сердито, а по отдельности можно найти намного более мощные инструменты.


D> IDE это уже давно не просто редактор.
в чем прелесть интеграции?! почему нельзя отдельно юзать редатор, отдельно ситему контроля версий, отдельно багтреккер... отладчик тоже отдельно. и профайлер отдельно. причем, все это настраивается. к любому нормальному текстовому редактору прикручивается скриптовый парсер разбирающий сообщения компилятора об ошибках и автоматически переводящий курсор на нужное место. для популярных компиляторов скрипты уже есть. в ms vc компилятор не встроенный (как когда-то в турбопаскале). и линкер там ни разу не встронный, а вызывается как внешняя тулза и дальше парсится вывод.

Здравствуйте, azzx, Вы писали:

A>Здравствуйте, Aleх, Вы писали:

A>>Такое впечатление, что проекты разрабатываются в блокноте с подсветкой ключевых слов кода. И каждый раз при компиляции запускается командная строка. Скажите, это действительно так? Зачем же быть такими мазахистами?

A>Ты не поверишь, есть люди, которые набирают код (ну не весь, но прилично) в страшном консольном FAR-е.
A>А по ночам, в полнолуние, они выходят на улицу... и ищут того, что так интересно расположил и поименовал каталоги в дефолтно создаваемых проектах в студии.

фигня, фигня, фигня. мне тут дали сорцы проекта в студии. с абсолютными путями. причем на самом деле это не один проект, а три (библиотека А, библиотека Б, использующая библиотеку А, и программа, использующая две библиотеки). причем библиотеки на диске D, где у меня сидиром. прелесть, просто прелесть. разумеется, никаких объясний в каком порядке его собирать нет. причем библиотека Б ищет библиотеку А в релизе, а пограмма хочет видеть отладочные версии библиотек. т.е. собрать нужно и релиз и дебаг.

вот сидел и думал -- какая прелесть эти make-файлы, не говоря за скриптовые сценарии сборки.

Здравствуйте, x-code, Вы писали:

XC>Здравствуйте, jazzer, Вы писали:

J>>Потому что файл проекта — это на самом деле не файл проекта, а файл настройки IDE, чтоб она смогла работать с этим проектом. И вполне естественно, что этот файл зависит как от самой IDE, так и от ее версии.

XC>Да ладно... Файлы проектов содержат имена файлов для компиляции, правила компиляции, опции компилятора.
в том числе и это. но еще и многое другое. унифицировать файлы проектов теоритически возможно. практически -- нет такого стандарта. зато можно сделать экспорт в make и потом импортировать его в другой среде разработке. make-файл содержит не только файлы, но и зависимости между ними -- указывая какие файлы пересобирать при изменении файла A.

XC> Это не настройки IDE. Можно было бы сделать так: определить на основе XML
а XML зачем? когда зарождались IDE никакого XML еще не было.

XC> минимальную структуру файла проекта, которую обязаны поддерживать все,
что значит "обязаны"? кто будет определять? кто контролировать и координировать?

XC>Параметры компилятора тоже не мешало бы стандартизировать таким же способом
посмотрите сначала на ключи компиляции и линковки. какой вы видите их стандартизацию? как стандартизировать ключи типа /GS ?! как стандаризировать опции оптимизации?

XC> Хотите дополнительные опции — именуйте их так, чтобы было понятно что они дополнительные (например, префикс "specific")
а кому это нужно, интересно?

Здравствуйте, x-code, Вы писали:

XC>Здравствуйте, Aleх, Вы писали:


XC>А мораль такова: если бы мейкфайлы и/или файлы проектов были включены в стандарт языка
какого языка? у меня в make-файлах в том числе и документация. если я изменил ms word doc (о! ужос!), то make вызовет конвретор в pdf. если я ничего не менял -- то не вызовет. а этот pdf засунут в zip. и если я поменяю readme или сгенерился новый pdf или изменилось что-то еще -- архив перепакуется.

какое отношение си имеет к make?

> и их формат был бы жестко документирован в тех же документах, что и сам язык
язык != ide. декларировать формат проектов в языке это что-то новое. даже в дотнете до такого не додумались.

> этого зоопарка бы не было, и ВСЕ(!!!) IDE и компиляторы были бы вынуждены работать с единым форматом проекта.
компиляторы с файлом проекта не работают. зачем он им? и вы забыли про линкеры. у вас компилятор уже make-файл переваривает что ли?

> Но увы, до этого еще никто не додумался, кроме меня
наверное, потому что вы не разделяете стадии компиляции/линковки/сборки проекта. посмотрите на серьезные проекты типа FireFox. оцените кол-во утилит, вовлеченных в процесс сборки.

Здравствуйте, Aleх, Вы писали:

A>Ок, но в таком случае должен быть стандартный формат проекта, который должен легко импортироваться в разные IDE.
A>Почему его нет? Почему вместо него makefile?

По хорошему это ортогональные вещи:
— Makefile — неотъемлемая составная часть проекта, описывающая зависимости, процесс сборки.
— файл проекта IDE — индивидуальные настройки разработчика: что и как открыто. Должен генериться на основе makefile.

Многие IDE прекрасно импортируют проекты на основе makefile`ов, создавая свои файлы проектов. Как минимум KDevelop, Qt Creator.