L>>Solution — это не проект. Проект — это Project. Открывай два проекта в одном Solution и работай на здоровье. R>Если бы вы внимательно прочитали, то поняли бы, в чем претензия. Если пихать все-все проекты в один solution, то, во-первых, боюсь, все умрет при определенном количестве проектов (да-да, знаю, их, конечно же, можно выгружать внутри solution, но см. "во-вторых"), а, во-вторых, таким образом вообще непонятно, что есть solution и на кой он нужен. Репозиторий проектов? Но MS же вкладывают иной смысл в него. Да и так бы по жизни хватило бы и одного репозитория с переключением на другие в настройках IDE.
На самом деле проекты и солюшны — это способ борьбы со сложностью систем
То есть, project — описание как собрать один target (EXE, Dll, MSI), причём в различных конфигурациях (набор которых может отличаться от проекта к проекту). Solution позволяет описывать зависимости между project-ами и между их конфигурациями. То есть, грубо говоря, solution завязан только на имя проекта и на имена его конфигураций. Очень удобно когда система у тебя разнородная — к примеру — проект состоит из части для PC, Pocket и Web-части. Тогда каждая часть билдится своим project-ом (или несколькими), но для каждого девелопера можно иметь свой solution (или несколько), где выделены те проекты которые ему нужны + общий solution для всего чего можно. До идеала, ИМХО, этой системе не хватает только возможности иметь вложеные solutions.
Кстати, насчёт проектов в Solution — на 2003-й студии вполне сносно работается с сотней-другой проектов. И, кстати, недавно вышел апдейт на новые студии как раз для ускорения работы с большими Solutions.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[9]: Почему не создают нормальных средств разработки?
Здравствуйте, Left2, Вы писали:
L>На самом деле проекты и солюшны — это способ борьбы со сложностью систем
Оно понятно, не хватает только одного: возможность открытия нескольких solutions или то, что вы предположили — их вложенность.
L>То есть, project — описание как собрать один target (EXE, Dll, MSI), причём в различных конфигурациях (набор которых может отличаться от проекта к проекту). Solution позволяет описывать зависимости между project-ами и между их конфигурациями. То есть, грубо говоря, solution завязан только на имя проекта и на имена его конфигураций. Очень удобно когда система у тебя разнородная — к примеру — проект состоит из части для PC, Pocket и Web-части. Тогда каждая часть билдится своим project-ом (или несколькими), но для каждого девелопера можно иметь свой solution (или несколько), где выделены те проекты которые ему нужны + общий solution для всего чего можно. До идеала, ИМХО, этой системе не хватает только возможности иметь вложеные solutions.
Это все понятно. Я же говорил только про то, что нужно бывает только одним глазком зыркнуть в старый solution, который никак не связан и не будет связан с текущим, чтобы просто посмотреть один-два метода или даже класса, быть может даже скопировать их. Простое действие же ж. Только ради этого добавлять проекты в решение, хм, не очень интуитивно...
L>Кстати, насчёт проектов в Solution — на 2003-й студии вполне сносно работается с сотней-другой проектов. И, кстати, недавно вышел апдейт на новые студии как раз для ускорения работы с большими Solutions.
Ага, в принципе, можно Unload Project делать, оно понятно.
Re[10]: Почему не создают нормальных средств разработки?
Здравствуйте, rsn81, Вы писали:
L>>Кстати, насчёт проектов в Solution — на 2003-й студии вполне сносно работается с сотней-другой проектов. И, кстати, недавно вышел апдейт на новые студии как раз для ускорения работы с большими Solutions. R>Ага, в принципе, можно Unload Project делать, оно понятно.
Зачем Unload? у меня на данный момен загружено 130 проектов, и ничего страшного не происходит. Потребности выгружать проекты не ощущаю.
... << RSDN@Home 1.2.0 alpha rev. 783>>
Re[5]: Почему не создают нормальных средств разработки?
Здравствуйте, Бусел, Вы писали:
Б>Например, в VStudio работа с БД никак не упрощена в то время как существоет много способов стандартизировать сей рутинный труд.
Что подразумевается под упрощением работы с БД? Если создание схемы, то есть VSDB, если деплоймент, то та же VSDB и Team Suite for System Administrators, если доступ к данным, то ADO.NET, если OR/M, то Linq to SQL и Linq to Entities, если упрощение создания каких то настройщиков и дизайнеров, то DSL Tools в составе VS SDK. Ну м т.д.
Left2 wrote: > В Eclipse работал только с CDT — могу смело утверждать что втыкает она > на С++ проектах намного сильнее чем Visual Studio 2003.
Ну CDT постепенно становится лучше. Хотя развиваться ему еще долго.
> Как человек который работает в основном с С++ могу сказать — связку MSVC > + Visual Assist по удобству навигации по коду, поддержки Intellisense и > т.п. удобностям Eclipse + CDT ещё очень долго не догонит. Насчёт других > языков —
Просто для С++ нормально ничего сделать нельзя. Такой уж язык...
Posted via RSDN NNTP Server 2.1 beta
Sapienti sat!
Re[6]: Почему не создают нормальных средств разработки?
rsn81,
_>>Ну вы не могли бы описать, чего на Ваш взгляд не хватает в VS ?
Сравнивать IDE под джаву и под C++ — это как бы сказать... нечестно. В C++ много труднее сделать интеллисенс, рефакторинг и компилятор реального времени, особенно когда исходник некорректный (например, в середине процесса редактирования).
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
_>>>Ну вы не могли бы описать, чего на Ваш взгляд не хватает в VS ? LCR>Сравнивать IDE под джаву и под C++ — это как бы сказать... нечестно. В C++ много труднее сделать интеллисенс, рефакторинг и компилятор реального времени, особенно когда исходник некорректный (например, в середине процесса редактирования).
Eclipse есть и for c++ developers. Да и студию человек сравнивает не только по с++, у него .Net Опыт есть
Re[7]: Почему не создают нормальных средств разработки?
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Сравнивать IDE под джаву и под C++ — это как бы сказать... нечестно. В C++ много труднее сделать интеллисенс, рефакторинг и компилятор реального времени, особенно когда исходник некорректный (например, в середине процесса редактирования).
C++ серьезно вообще не занимаюсь (здесь даже ничего сказать особенного не могу), говорил про MSVS С# (without Resharper) vs Eclipse SDK Java (with JDT) — у этих языков-то синтаксис одной ступени сложности.
Re[8]: Почему не создают нормальных средств разработки?
rsn81,
LCR>>Сравнивать IDE под джаву и под C++ — это как бы сказать... нечестно. В C++ много труднее сделать интеллисенс, рефакторинг и компилятор реального времени, особенно когда исходник некорректный (например, в середине процесса редактирования). R>C++ серьезно вообще не занимаюсь (здесь даже ничего сказать особенного не могу), говорил про MSVS С# (without Resharper) vs Eclipse SDK Java (with JDT) — у этих языков-то синтаксис одной ступени сложности.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Ага, понял. Токо почему "without Resharper"?
Потому что с одной стороны модуль JDT поставляемый с бесплатной Eclipse SDK Classic в коробке содержит intellisense, а платный MSVS2005 в коробке Resharper не содержит. От покупного продукта, тем паче от такого монстра как MS, хотелось бы большего... хотя бы в коробке Team Suit. Вы представьте простую гипотетическую ситуацию: с горем пополам обосновываешь начальству необходимость приобретения лицензии на MSVS (хотя оно все норовит с едкой ухмылкой спросить: "Ты чего, кряк сам найти не можешь, да?"), а потом приходится просить уже мизерную сумму на жизненно необходимый Add-In к ней, тут уже вопрос будет задан точно в лоб: "Так какого мы тогда лешего тратили деньги на прошлое приобретение, если оно тебя так сильно не устраивает, а?"
Re[8]: Почему не создают нормальных средств разработки?
Здравствуйте, rsn81, Вы писали:
L>>Чего не хватает?? Там и так не сыщешь нужного, за деревьями леса... R>Многого. В Eclipse SDK намного больше настроек.
Армяне лучше чем грузины. Чем? Чем грузины!(с)
Что конкретно-то вам не удаётся настроить в VS?
Re[9]: Почему не создают нормальных средств разработки?
Здравствуйте, Left2, Вы писали:
L>То есть, project — описание как собрать один target (EXE, Dll, MSI), причём в различных конфигурациях (набор которых может отличаться от проекта к проекту). Solution позволяет описывать зависимости между project-ами и между их конфигурациями. То есть, грубо говоря, solution завязан только на имя проекта и на имена его конфигураций.
Это "грубо говоря" — а вообще-то это не так — в этом месте определенная и вполне достаточная гибкость имеется: даже через IDE можно настроить чтобы Solution Target ("Configuration") собирал Project Targets ("Configuration"s) хоть в шахматном порядке — к тому же легко сделать новый что тот, что другой и подключается в солюшин именно "конфигурация", а не просто "проект по имени". Так что с этим все впорядке — просто "по умолчанию" это сделано настолько удобно, что редко кто на самом деле меняет "классический" порядок включения прожект билдов. Прошу прощения что постянно все называю по-разному.
L>... До идеала, ИМХО, этой системе не хватает только возможности иметь вложеные solutions.
Честно говоря, лично не сталкивался с такой потребностью. Можно спросить "зачем надо?" — какие будут прецеденты использования у такой функции?
Голь на выдумку хитра, однако...
Re[10]: Почему не создают нормальных средств разработки?
L>>... До идеала, ИМХО, этой системе не хватает только возможности иметь вложеные solutions. TL>Честно говоря, лично не сталкивался с такой потребностью. Можно спросить "зачем надо?" — какие будут прецеденты использования у такой функции?
К примеру, есть большая система, из десятка exe-файлов, и трёх десятков библиотек (зависимых друг от друга) из которых эти exe-файлы собираются. Иметь всё в одном solution неудобно — много лишнего перед глазами. А иметь всё в нескольких solutions — означает настраивать зависимости проектов друг от друга в каждом из solutions отдельно. Вложенные solutions тут бы мне здорово помогли.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[11]: Почему не создают нормальных средств разработки?
Здравствуйте, Left2, Вы писали:
L>>>... До идеала, ИМХО, этой системе не хватает только возможности иметь вложеные solutions. TL>>Честно говоря, лично не сталкивался с такой потребностью. Можно спросить "зачем надо?" — какие будут прецеденты использования у такой функции?
L>К примеру, есть большая система, из десятка exe-файлов, и трёх десятков библиотек (зависимых друг от друга) из которых эти exe-файлы собираются. Иметь всё в одном solution неудобно — много лишнего перед глазами. А иметь всё в нескольких solutions — означает настраивать зависимости проектов друг от друга в каждом из solutions отдельно. Вложенные solutions тут бы мне здорово помогли.
Как насчет того, чтобы не включать проект базовых библиотек в солюшин? Т.е. выполнять сборку (линковку) не по зависимостям проектов в солюшине, а прямой линковкой .lib? Какие недостатки такого метода на ваш вгляд?
Голь на выдумку хитра, однако...
Re[12]: Почему не создают нормальных средств разработки?
TL>Как насчет того, чтобы не включать проект базовых библиотек в солюшин? Т.е. выполнять сборку (линковку) не по зависимостям проектов в солюшине, а прямой линковкой .lib? Какие недостатки такого метода на ваш вгляд?
Ну а эту lib-у собирать — из другого Solution? Не очень удобно — удобно когда каждый Solution делает сборку конечного target-а (Exe или Dll, или ещё чего-нить) от начала до конца.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[13]: Почему не создают нормальных средств разработки?
Здравствуйте, Left2, Вы писали:
TL>>Как насчет того, чтобы не включать проект базовых библиотек в солюшин? Т.е. выполнять сборку (линковку) не по зависимостям проектов в солюшине, а прямой линковкой .lib? Какие недостатки такого метода на ваш вгляд?
L>Ну а эту lib-у собирать — из другого Solution? Не очень удобно — удобно когда каждый Solution делает сборку конечного target-а (Exe или Dll, или ещё чего-нить) от начала до конца.
Мало того: собрал один раз — и больше не пересобирать без необходимости. Да и код либы тоже можно всем подряд не раздавать, а только заголовки — ну и код, конечно, по мере необходимости.
P.S. Речь идет о проектах C++ объема средних и выше.
Голь на выдумку хитра, однако...
Re[11]: Почему не создают нормальных средств разработки?
Здравствуйте, Left2, Вы писали:
L>>>... До идеала, ИМХО, этой системе не хватает только возможности иметь вложеные solutions. TL>>Честно говоря, лично не сталкивался с такой потребностью. Можно спросить "зачем надо?" — какие будут прецеденты использования у такой функции?
L>К примеру, есть большая система, из десятка exe-файлов, и трёх десятков библиотек (зависимых друг от друга) из которых эти exe-файлы собираются. Иметь всё в одном solution неудобно — много лишнего перед глазами. А иметь всё в нескольких solutions — означает настраивать зависимости проектов друг от друга в каждом из solutions отдельно. Вложенные solutions тут бы мне здорово помогли.
Solution folder как раз для группировки проектов и существует.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[10]: Почему не создают нормальных средств разработки?
The Lex wrote: > Это "грубо говоря" — а вообще-то это не так — в этом месте определенная > и вполне достаточная гибкость имеется: даже через IDE можно настроить > чтобы Solution Target ("Configuration") собирал Project Targets > ("Configuration"s) хоть в шахматном порядке — к тому же легко сделать > новый что тот, что другой и подключается в солюшин именно > "конфигурация", а не просто "проект по имени".
Solution'ы в понятии Студии — мастдай. Гибкости очень сильно как раз не
хватает.
Например, ОЧЕНЬ ОЧЕНЬ неудобно управлять так 5-10 разными конфигурациями
проекта (32 bit и 64 bit, каждая в debug и release и еще static/dynamic
для библиотек).
Мне сейчас нравится как это сделано в Boost.Build — можно наследовать
настройки или автоматически подстраивать в зависимости от требований.
Posted via RSDN NNTP Server 2.1 beta
Sapienti sat!
Re[11]: Почему не создают нормальных средств разработки?
C>Мне сейчас нравится как это сделано в Boost.Build — можно наследовать C>настройки или автоматически подстраивать в зависимости от требований.
В 2005-й студии тоже можно наследовать настройки (для проектов). Правда, там таааакой неудобный user interface (ну или по крайней мере мне так показалось)... Но зато никто не мешает напрямую править XML-файлы
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[11]: Почему не создают нормальных средств разработки?
Здравствуйте, Left2, Вы писали:
L>К примеру, есть большая система, из десятка exe-файлов, и трёх десятков библиотек (зависимых друг от друга) из которых эти exe-файлы собираются. Иметь всё в одном solution неудобно — много лишнего перед глазами. А иметь всё в нескольких solutions — означает настраивать зависимости проектов друг от друга в каждом из solutions отдельно. Вложенные solutions тут бы мне здорово помогли.
Solution — это просто костыль. На самом деле, нужна просто вложенная иерархия проектов. Еще может иметь смысл понятие workspace, куда можно добавить проекты, которые не связаны непосредственно с главным проектом, но нужны чтобы подсмотреть в них какие-то детали, например.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
