как правильно соединить несколько проектов в один (dependensies, workspace и т.д

[Malaja]

Господа,

сейчас столкнулась с совершенно идиотской проблемой. Есть один немаленький проект, состоящий из подпроектов (каждый из них формирует свою dll). Среди этих подпроектов есть один основной (он при компиляции формирует основной файл проекта - exe).
Причем как это все собирали в свое время - уже никто не помнит, т.к. динозавры проекта или потеряли память или вымерли  ) Тот единственный, который еще что-то знает, придет в лучшем случае в среду... А исправить было бы неплохо раньше, если получится. 

Далее:
с проектом можно работать двояко:
- либо загружать .dsw основного подпроекта, а он, в свою очередь, потянет все остальные подпроекты (так делаю, например, я - мне так удобней), и затем работать с любым из необходимых подпроектов
- либо открывать только .dsw того подпроекта, с которым в данный момент надо работать (делают многие коллеги). Этот .dsw , в свою очередь, потянет все те подпроекты, от которых он зависит.

Проблема: если я работаю по своей методике, то при необходимости изменения конфигурации какого-то подпроекта я делаю его активным проектом (Set Active project), затем вызываю диалог "dependensies", корректирую, сохраняю, устанавливаю активным опять тот основной подпроект и довольна, т.к. компиляция прекрасно работает.
Но я ж рано радовалась...   Кто-то из коллег пошел по второму пути, загрузил только нужный ему подпроект, который через dependensies потянул и мой, который я изменила, попытался компилировать и получил кучу ошибок в моем подпроекте, т.к. все установленные мной dependensies тут неизвестны... Что и следовало ожидать, т.к. все мои изменения сохранились в проектном файле основного подпроекта, а не в файлах моего подпроекта.

Ладно, тогда я пошла другим путем и открыла свой подпроект отдельно, через "Insert project into workspace" добавила все недостающие подпроекты, установила "dependensies", добавила Libs, откомпилировала, все работает. Изумительно! 
Ага, щас.... А у коллеги так ничерта и не работает!... 
Когда я открываю его подпроект и смотрю там на свой, то вижу, что все те dependensies, которые я внесла, там не видны...

И как с этим бороться??? Караул! 

[Джон]

Ир, главное - спокойствие, только спокойствие. Вся инфа о зависимостях записывается толко в dsw. И пока у вас у каждого свой - ничего не получится. Ты можешь менять в своём файле всё, что угодно - коллеге от этого не тепло и не холодно. Так что в этом направлении можешь не копать.
А почему бы вам не работать с одним dsw?

[npak]

А почему бы не научиться писать nmakefile?
ИМХО, когда сборкой занимаются несколько человек, то надо делать несколько makefile (под одному на каждый проект), хранить  в системе управления версиями и собирать из командной строки или через проект-makefile в Visual Studio.

[Malaja]

Джон,

ага, вот в этом-то и дело... Они хотели иметь возможность работать и так, и эдак А нефиг, нефиг Я уже поняла, что я никак их не поженю, да и остальные тоже ничего не сделают. Тут возможно только поддерживать конфигурацию основного подпроекта.
Причем на уровне независимой ежедневной компиляции проекта (это генерирует скрипт) происходит все именно так, как делаю я, т.е. загружается основной подпроект и вперед и с песнями. И все работает, т.к. его .dsp и .dsw обязаны поддерживать в актуальном состоянии все программисты, работающие в проекте.

npak,

понимаешь, они делают все по установившейся схеме, которую сломать можно только подписав кучу документов и пройдя кучу согласований Я тут вообще сотрудник купленный на проект у другой фирмы и посему в производственный процесс допускаемый с большими ограничениями Посему никакие кардинальные меры принимать не могу.
А для себя было бы интересно - просто я никогда этим не занималась. Ты можешь подсказать, если тебе не сложно, где и что посмотреть на эту тему?

Короче, я сейчас пообщалась с начальником - надо будет на совещании просто всем поставить на вид, что все должны работать с основным подпроектом, а все остальное - под свою ответственность. Иначе это нереально - отслеживать все изменения во всех частях и поддерживать их.

Еще раз спасибочки вам за поддержку!

[npak]

Ирина,

справочная информация по NMAKE на сайте Microsoft http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcug98/html/_asug_overview.3a_.nmake_reference.asp

[Malaja]

npak,

спасибочки!

[Джон]

Ир, на примере проще. Например есть один ЕХЕшник и куче ДЛЛ. Ты работаешь с ЕХЕшником, кто-то работает с ДЛЛ. Ему совсем не обязательно каждый раз компилить ТВОЮ ехе. Ему достаточно копии, которую можно переименовать и положить рядом с оригинальной. Тогда при отладке своей ДЛЛ он указывает стартовую прогу - копию. В этом случае не должно существовать зависимости ДЛЛ от ЕХЕ (бред полнейший)
У тебя стоят все зависимости ЕХЕ от всех ДЛЛ, и когда ты её компилишь, получаешь все свежие ДЛЛ автоматически. Всё это делается в пределах ОДНОГО dsw.
Я так делал в проекте, когда была одна "центральная" ДЛЛ - ядро, с цепочкой других. И несколько ЕХЕшников, разные типы, которые использовали это ядро. Каждыё ЕХЕшник в свою очередь зависил от своих персональных ДЛЛ. И всё работало замечательно. Даже был враппер для одно VB проги. Те для него я указывал именно эту бейсиковскую прогу. ВОт и всё.
А актуализировать копию ЕХЕшника, бедешь всегда ты, как за неё ответственная.

зы С праздничком

[Malaja]

Джон,

ага, это работает только в случае компиляции одного отдельно взятого подпроекта через F7. Но проблема в том, что народ любит делать "rebuild all"... Вот тут как раз и наступает момент истины в виде белого и пушистого зверька типа вчерашнего ... Т.е. в переводе - нервы, поиск проблемы и виноватого

Спасибочки! тебя тоже с ним родимым! Отосплюсь же! Тем более, у ребенка каникулы

[Джон]

Ну дык, надо отучать от пагубной привычки - rebuild all. Мы тут как раз на похожую тему разговариваем.

А чё эт у вас каникулы? Моя уже давно в школу ходит?

[Malaja]

Дык у вас же другая земля, другие нравы
Ну да, мои коллеги уже задумываются над этим. Проблема заключается в том, что иногда при обычной компиляции все ОК, а при полной выясняются огрехи, посему полная при больших изменениях просто необходима, чтобы быть уверенным в том, что никто не забыт и ничто не забыто И вот тут как раз и появляется проблема загрузки всего целого вместо частей - это потеря времени по сравнению с частью, но если подумать, сколько они теряют, если не сходятся зависимости, то уж лучше подождать, пока весь проект переведется.