MSBuild / Visual Studio распределил сборки
К сожалению, Вы только в состоянии определить структуру в где пункт в этом экземпляре. Кажется странным, что Вы не можете определить Int16, Int32, и т.д. конкретно, но я уверен, что существует некоторая глубокая причина реализации, лежащая в основе решения не разрешить, чтобы значение ввело где пункт.
я предполагаю, что единственное решение состоит в том, чтобы сделать проверку на этапе выполнения, которая, к сожалению, предотвращает проблему, взятую во время компиляции. Это пошло бы что-то like:-
static bool IntegerFunction<T>(T value) where T : struct {
if (typeof(T) != typeof(Int16) &&
typeof(T) != typeof(Int32) &&
typeof(T) != typeof(Int64) &&
typeof(T) != typeof(UInt16) &&
typeof(T) != typeof(UInt32) &&
typeof(T) != typeof(UInt64)) {
throw new ArgumentException(
string.Format("Type '{0}' is not valid.", typeof(T).ToString()));
}
// Rest of code...
}
, Который немного ужасен, я знаю, но по крайней мере обеспечивает необходимые ограничения.
я также изучил бы возможные последствия производительности для этой реализации, возможно, там существует более быстрый путь.
6 ответов
Посмотрите http://www.xoreax.com/ для Incredibuild. Это не бесплатно, но мы им пользуемся, и это довольно впечатляюще. Он хорошо интегрирован в Visual Studio и чрезвычайно прост в использовании. Время от времени вы можете столкнуться с проблемой, но на нее определенно стоит обратить внимание.
После установки в Visual Studio принцип состоит в том, чтобы использовать пункт меню «Построить решение с помощью Incredibuild» вместо «Построить решение». один. Все необходимые файлы прозрачно передаются на удаленные компьютеры, а выходные файлы загружаются обратно.
Теоретически с Visual Studio 2010 вы можете написать свои собственные задачи msbuild, которые могут планировать задачи и передавать код на другие машины для компиляции.
В предыдущих версиях Visual Studio вы могли переопределить cl. exe, lib.exe и link.exe и создайте свои собственные оболочки. Этот метод был успешно использован для добавления компиляции и связывания неподдерживаемых типов платформ.
Изучите возможность разделения вашего проекта на несколько проектов, которые можно построить независимо. У вас может быть проект для пользовательского интерфейса, проекты DLL для уровня доступа к данным, бизнес-логики и т. Д. Это должно немного упростить отладку и структурировать ваш проект таким образом, чтобы он подходил для распределенной сборки.
Скотт Хансельман опубликовал сообщение о параллельных сборках здесь . Он не распространяется полностью, но может некоторым помочь.
Также обратите внимание, что MSBuild не создает сами проекты C ++. Фактически, он вызывает vcbuild, чтобы сделать за него грязную работу.
За последние десять лет я потратил слишком много времени на то, чтобы сборки C ++ работали намного быстрее, а параллельные сборки могут творить чудеса, но простые вещи иногда имеют неожиданное значение.
Вы этого не сделали. Не уточняю, поэтому спрошу ...
Каковы масштабы проекта? Сколько исходных файлов и т. Д. Метрика, которую я использовал в прошлом, - ориентироваться в среднем на одну секунду на один исходный модуль (.cpp). В источниках от 200 до более 32 000 строк (не опечатка!) Это хорошо работало в качестве метрики в моем прошлом.
Каковы характеристики вашей машины сборки, и является ли она только сборкой машина или она используется для другой работы одновременно? Глупо медленные жесткие диски, слишком мало оперативной памяти, использование других процессов; все может вызвать катастрофические последствия во время сборки.
Вы создаете монолитные статические библиотеки и приложения? Если это так, иногда преобразование в файлы DLL приведет к сокращению общего времени сборки, поскольку это приведет к уменьшению размера отдельных единиц связи. Это особенно верно для оптимизированных сборок с генерацией кода во время компоновки.
Эффективно ли в ваших проектах используются предварительно скомпилированные заголовки? Если ваш проект настроен на автоматическое создание предварительно скомпилированных заголовков, я утверждаю, что вы должны протестировать сборку, отключив все использование предварительно скомпилированных заголовков. В Visual Studio 2003 и Visual Studio 2005 я обнаружил, что это на самом деле быстрее и надежнее, чем автоматическая генерация. Правильные предварительно скомпилированные заголовки (сгенерированные одним файлом, который выполняет только , и используются всеми остальными файлами), по-видимому, являются наилучшей скоростью сборки. К сожалению, это
TeamBuild предоставит вам систему распределенной сборки, которая хорошо интегрируется с Visual Studio.