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

GR>Я не совсем понимаю идею... Изначально я хотел добиться того, чтобы экспериментальная ветка смотрела на сборки компилятора из boot, а рабочая — на Program Files. Как этого добиться введением переменной NemerleBoot?

В немерловом проекте студии указан путь к Nemerle как %Program Files%. Что, если его поменять на что-нибудь более подходящее? Может вообще можно указать прямые ссылки? А если всё засунуть в один солюшин?

IT>>Хорошо бы вообще разделить установленный на машине Nemerle стандартным образом с тем, с чем работают девелоперв. Тогда можно будет писать интеграцию на самой интеграции.
GR>У нас мысли сходятся Как первый шаг на пути к этому я изменил все проекты (кроме самого компилятора) так, чтобы они смотрели на boot, но Влад такой ход раскритиковал — будем искать более удачное решение.

Насчёт бута он прав. Нужно, чтобы ссылка была на свежеоткомпилированную версию.

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

GR>Сначала опишу, чего я хотел этим добиться.
GR>1. Иметь две версии Nemerle на одной машине:
GR> а. Стабильная версия, установленная последним официальным инсталлятором.
GR> б. Девелоперская версия, собранная из исходников.
GR>2. Избавиться от необходимости в процессе сборки копировать компилятор в Program Files и регистрировать его там. Это автоматом делает невозможным п. 1
GR>3. Разрабатывать компилятор и интеграцию на чуть более ранней версии интеграции.

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

Интеграция же из под интеграции и так запускается. Проблема только в самокомпиляции. Для ее решения нужно копировать сборки в разные места. Но бут использовать нельзя.

Переменную Nemerle можно задать:
1. Через параметр — /p:Nemerle=... в MSBuild.
2. Через установку переменной среды окружения — set Nemerle=....
3. Изнутри проекта задавая свойства проекта — <Nemerle>...</Nemerle>. При этом можно использовать условия.

Но есть одна глобальная проблема. Сборки для целей интеллисенса и сборки для самой игтерации грузятся в один домен приложений. А вот в один домен нельзя загрузить (без ужасных последствий) оду и ту же сборку разных версий. Так что боюсь, что попытка обречена на неудачу.

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

GR>Сейчас так и делается. Последовательность сборки компилятора:
GR>1. Первая фаза компиляции (исп. оригинальный boot)
GR>2. В случае успеха п.1 копируем в boot то, что скомпилировалось
GR> 2.1 Вторая фаза — компилируем новой версией самого себя.
GR> 2.2 В случае ошибки восстанавливаем оригинальный boot.
GR>То есть в результате сборки второй фазы boot будет уже изменен, и там лежит вполне рабочая версия компилятора.
GR>Это то, как я понимал до сих пор процесс сборки. Но видимо в это справедливо только для тех, кому интересно просто нажать кнопку и получить работающую интеграцию. По-этому я прошу описать наиболее типичные варианты сборки для девелопера и для потребителя, т.к. удовлетворить нужно всех.

Двухфазная компиляция в два раза более медленная. По этому при работе над компилятором в основном используется однофазная компиляция. При этом копировать результат в boot нельзя, так как этой версией уже можно не скомпилировать компилятор.

VD>>Файлы в нем должны комититься как можно реже, так как это довольно большие бинарные файлы, к тому же ктитичные.
GR>Для комита можно предусмотреть специальный таск, который в случае необходимости можно указать при сборке в командной строке явно:
GR>

msbuild NemerleAll.nproj /t:Stage2;Commit

Еще раз... медленно. Комитить бинарники надо КАК МОЖНО РЕЖЕ. Они банально большие. Копирование же файлов в boot приводит к тому, что их можно закомитить по неволе.

Учитывая вышесказанное мы должны иметь полноценный вариант одностадийной компиляции. В нем ничего не должно копироваться в boot, а интеграция должна собираться новыми файлами (не из бута).

VD>>Кроме того очень важно производить прекомпиляцию сборок компилятора ngen-ом, так как это во много раз ускоряет загрузку компилятора.
GR>Это можно делать сразу после Stage2 вот так:
GR>

msbuild NemerleAll.nproj /t:Stage2;RegProgramFiles

При одностадийной компиляции регистрация тоже необходима.

GR>Для самых частых типов задач можно придумать что-нить покороче.

Да, корочен не надо. Часто используемые варианты можно тупо вынести в батники. Главное, чтобы они были простыми как три копйки, а не как сейчас.

GR>>>Еще я реализовал возможность зарегистрировать путь к Nemerle.MSBuild.targets в boot, но толку от этого мало, т.к. во всех шаблонах проектов есть такой код:

GR>>>

GR>>>    <PropertyGroup>
GR>>>        <NoStdLib>true</NoStdLib>
GR>>>        <Nemerle Condition=" '$(Nemerle)' == '' ">$(ProgramFiles)\Nemerle</Nemerle>
GR>>>    </PropertyGroup>
GR>>>

GR>>>Единственный способ, который я нашел, заставить студию смотреть на boot — определить переменную окружения Nemerle=<путь к boot>. Если такой вариант устроит, то нужно будет в таск RegBoot добавить инструкцию, которая создает эту переменную в системе.

MSBuild-проекту можно передать это дело задав свойство. На то этот Condition и был введен. Сложнее будет с компиляцией из под VS.

Однако не думаю, что разделение сборок по каталогам поможет писать интеграцию из под старой игтеграции. Как я уже говорил проблема в несовместимости сборок.

VD>>Не надо работать из бута. Можно сделать тупое копирование файлов из бута в %ProgramFiles%\Nemerle, если это кому-то надо. Но надо понимать, что современные версии Интеграции могут попросту не собираться из бута.
GR>В %ProgramFiles%\Nemerle очень хотелось бы иметь версию, установленную инсталлятором. Может рассмотреть вариант — копировать все это в некий \work, и там обрабатывать ngen-ом. work в SVN класть будет совсем не обязательно.

Можешь попробовать, но боюсь, что ничего не выйдет. Точнее можно будет запускать Интеграцию собранную из исходников и Интеграцию из %ProgramFiles%\Nemerle, но, боюсь, что использовать инсталлированную для работы над текущей не выйдет.

GR>Или определить эту переменную в NemerleAll.nproj...

Наверно. Незнаю "наследуется" ли она или нет. Если — да, то проблем нет... ну акромя упомянутых мною выше.

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

GR>К стати наткнулся на редактор msbuild скриптов http://www.attrice.info/downloads/index.htm — может кому пригодится.

К сожалению:

The installation package includes MSBuild Sidekick v2 application 14-days trial

в прочем может 1.х тоже что-то дает.

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

GR>Я хотел это сделать, но времени небыло. Реально эти xml нужны только при сборке инсталлятора, а значит предлагаемое свойство можно попытаться устанавливать автоматически в зависимости от таргетов.

В зависимости от конфигурации. Так оно и было. Если ты не обратил внимание, комментированные варианты были в Debug-конфигурации.

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

GR>В данной версии скриптов это не предусмотрено, но сделать можно. Но пред тем, как что-то делать хотелось бы договориться насчет копирования (а точнее не копирования) бинарников в Program Files.

Это пожалуйста, но нужно сделать вариант с копированием и регистрацией в %ProgramFiles%\Nemerle.

GR>Как вариант рядом с boot можно разместить папку work, и туда класть результат превой фазу. Туда же копировать и targets, и там же все это регистрировать. При этом work в SVN класть не нужно — он всегда будет создаваться на первой фазе компиляции.

Папки лучше называть Stage1, Stage2 и Stage3.

VD>>А как регистрировать в %ProgramFiles%\Nemerle?
GR>msbuild NemerleAll.nproj /t:RegProgramFiles

А при этом проект скомпилируется если он устарел?

VD>>При работе над интеграцией и компилятором самый частый сценарий это:
VD>>1. Однопроходная сборка компилятора.
VD>>2. Регистрация файлов компилятора в %ProgramFiles%\Nemerle.
VD>>3. Сборка тестов.
VD>>4. Сборка Интеграции.
GR>Добро, реализую такой сценарий и сделаю его по умолчанию. Сборка будет до безобрази проста: msbuild NemerleAll.nproj

По умолчанию лучше как раз самый сложный вариант, так как его будут запускать новички. Уж лучше они будут скучать или обламываться, но не смогут закомитить нерабочие сборки.
А описанный вариант можно назвать Stage1 или Fast.

VD>>Э... нужно чтобы компиляция и регистрация могла бы производиться в оду стадию. Иначе резко замедлится работа над компилятором. Я выполняю сборку в две стадии исключительно когда подготавливаю файлы к комиту в SVN.
GR>Не вопрос
GR>msbuild NemerleAll.nproj /t:Stage2;RegProgramFiles
GR>или
GR>msbuild NemerleAll.nproj /t:Stage2;RegBoot

А при этом регистрация произойдет если обломалась компиляция?

VD>>>>3. Третий солюшен должен собирать интеграцию.
GR>>>4. msbuild NemerleAll.nproj /t:VSIntegration

VD>>Здорово! А перед этим производится компиляция компилятора?
GR>Да, Stage2, но насколько я понял, здесь нужна Stage1.

Ага.

VD>>Отлично! Вот это и есть подход "зеленой факсовой кнопки".
GR>Это значительно приятней, чем когда только посвященные могут собрать инсталлятор

Ну, "волшебное слово" в командной строке все же знать нужно, так что посвятиться все же прийдется .
Тут главное другое. Главное, что упорядочив и систематизировав работу по сборке проектов мы убираем головную боль и позволяем разработчикам сосредоточиться на их задачах. Они больше не обязаны отвлекаться на ненужные вещи вроде контроля скомпилироанности частей проекта или запоминании комбинаций вызова батников перед комитом изменений в компиляторе.


VD>>Как я понимаю встроенными задачами это не реализовать (если только вызвать внешние утилиты командной строки). Но вот это

Автор: VladD2
Дата: 30.06.08

должно помочь. Можно залить бинарники этих тасков на сервер и пользоваться ими.
GR>Вот только как бы все это протестировать... На живом SVN, пожалуй, не хорошо. Нужно будет копию развернуть и в тестовом режиме туда комитить пока не заработает как положено.

Да пожалуй автоматический комит — это перебор. А вот забирать новые версии было бы очень даже удобно. И тестировать просто. К тому же SVN хорош тем, что всегда можно откатить ревизию.

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

VD>Но есть одна глобальная проблема. Сборки для целей интеллисенса и сборки для самой игтерации грузятся в один домен приложений. А вот в один домен нельзя загрузить (без ужасных последствий) оду и ту же сборку разных версий. Так что боюсь, что попытка обречена на неудачу.

А если сборки для интеграции переименовать?

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

VD>Но есть одна глобальная проблема. Сборки для целей интеллисенса и сборки для самой игтерации грузятся в один домен приложений. А вот в один домен нельзя загрузить (без ужасных последствий) оду и ту же сборку разных версий. Так что боюсь, что попытка обречена на неудачу.

Проблема видимо из-за того, что номера варсий различаются лишь в билде. Может быть сборкам компилятора для интеграции давать какую-нибудь версию типа 10.*? Тогда они точно должны в одном домене работать.

Предлагаю не зацикливаться на том варианте сборочных скриптов, который я прислал. Их можно рассматривать как демо альфа версии Что-то типа пробы сил.

Попытаюсь агрегировать обсуждения из соседних подветок.
Основные хотелки:

1. Сборка компилятора — CompilerFull
Stage1, используя boot. Обработка NGen-ом
Stage2, используя Stage1
Stage3, используя Stage2
Побайтное сравнение Stage2 и Stage3
Только после этого копировать Stage3 в boot (при этом BackupBoot и RestoreBoot не нужны)

2. Сборка компилятора — CompilerFast
а. Stage1, используя boot. Обработка NGen-ом

3. Сборка интеграции — VsMedium
а. Stage1, используя boot. Обработка NGen-ом
б. VSIntegration, используя Stage1

4. Сборка интеграции — VsFast
а. VSIntegration, используя Stage1

5. Сборка инсталлятора — Installer
а. Сборка компилятора — CompilerFull
б. Сборка утилит, используя Stage3
в. Сборка интеграции, используя Stage3
г. Сборка шела, используя Stage3
д. Сборка инсталлятора. Бинарники берутся из Stage3

6. Регистрация Stage1 в экспериментальной ветке — RegStage1

7. Установка Nemerle в Program Files инсталлятором

8. Мирное существование двух веток одновременно

9. Сборка всех проектов идет полностью в рамках каталога $(NemerleRoot)

Относительно фаз компиляции предлагаю поступить так: создаем каталог Stages, под нам три каталога — 1, 2, 3 (каталог = номер фазы). При первом проходе устанавливаем переменную Nemerle=$(NemerleRoot)\Sages\1, при втором — Nemerle=$(NemerleRoot)\Sages\2, и т.д. Вместо Program Files\Nemerle предлагаю использовать $(NemerleRoot)\Sages\1

Давайте проанализируем все эти хотелки, удалим лишние и добавим недостающее, пока без деталей реализации, если их отсутствие не вызывает неясности. После того, как список хотелок зафиксируем, обсудим детали, если потребуется.

З.Ы. $(NemerleRoot) — каталог, где лежит http://nemerle.org/svn/nemerle/trunk

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

IT>Проблема видимо из-за того, что номера варсий различаются лишь в билде. Может быть сборкам компилятора для интеграции давать какую-нибудь версию типа 10.*? Тогда они точно должны в одном домене работать.

Попробуй.

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

GR>Основные хотелки:
GR>

1. Сборка компилятора — CompilerFull
GR> Stage1, используя boot. Обработка NGen-ом
GR> Stage2, используя Stage1
GR> Stage3, используя Stage2
GR> Побайтное сравнение Stage2 и Stage3
GR> Только после этого копировать Stage3 в boot (при этом BackupBoot и RestoreBoot не нужны)

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

GR>

2. Сборка компилятора — CompilerFast
GR> а. Stage1, используя boot. Обработка NGen-ом

GR>

3. Сборка интеграции — VsMedium
GR> а. Stage1, используя boot. Обработка NGen-ом
GR> б. VSIntegration, используя Stage1

GR>

4. Сборка интеграции — VsFast
GR> а. VSIntegration, используя Stage1

Работа из разных мест может привести к ненужным, и что самое главное, непонятным проблемам.
Так что лучше при удачной сборке копировать файлы из StageХ в некий каталог вроде DevBin. И уже там производить обработку NGen-ом и прочую регистрацию (если надо).

GR>

8. Мирное существование двух веток одновременно

Боюсь, что без изменения версий сборок это будет невозможно, так как дотнет не даст загрузить две сборки одной версии без глюков и проблем. Так что этот вопрос остается открытым. Конечно было бы хорошо если бы это удалось бы сделать, но не факт, что это будет так просто. Дело далеко не только в общих директориях.

GR>

9. Сборка всех проектов идет полностью в рамках каталога $(NemerleRoot)

GR>Относительно фаз компиляции предлагаю поступить так: создаем каталог Stages, под нам три каталога — 1, 2, 3 (каталог = номер фазы).

Называть каталоги "1", "2" и "3" — это плохая идея. Будет много много где данное название будет сбивать с толку. Пусть уж лучше каталоги называются NStageX где Х — это порядковый номер. Тогда по одному названию будет ясно о чем идет речь. Кроме того корневой каталог для сборки лучше (традиционно) назвать bin. Каталоги же NStageX пусть размещаются в нем. Кроме того в нево же имеет смысл засунуть каталог DevBin (в который копировать "рабочие" версии сборок для использования разработчиками.

GR>При первом проходе устанавливаем переменную Nemerle=$(NemerleRoot)\Sages\1, при втором — Nemerle=$(NemerleRoot)\Sages\2, и т.д. Вместо Program Files\Nemerle предлагаю использовать $(NemerleRoot)\Sages\1

Вместо %%ProgramFiles%%\Nemerle нужно использовать $(NemerleRoot)\bin\DevBin. Это позволит избежать многих странных ошибок уши которых растут из того, что используются не те бинарники (не из того каталога).

GR>Давайте проанализируем все эти хотелки, удалим лишние и добавим недостающее, пока без деталей реализации, если их отсутствие не вызывает неясности. После того, как список хотелок зафиксируем, обсудим детали, если потребуется.

GR>З.Ы. $(NemerleRoot) — каталог, где лежит http://nemerle.org/svn/nemerle/trunk

Это понятно. В общем, и целом план хороший. Но учти высказанные выше замечания.

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

IT>>Может быть сборкам компилятора для интеграции давать какую-нибудь версию типа 10.*? Тогда они точно должны в одном домене работать.
А если их другим ключиком (snk) подписывать?

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

IT>>>Может быть сборкам компилятора для интеграции давать какую-нибудь версию типа 10.*? Тогда они точно должны в одном домене работать.
БП>А если их другим ключиком (snk) подписывать?

Хз. Надо пробовать. А у меня и так список того что нужно подправить выше крыши.

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

VD>Это понятно. В общем, и целом план хороший. Но учти высказанные выше замечания.

Добро. На выходных буду курить улучшеный план

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

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

VD>>Это понятно. В общем, и целом план хороший. Но учти высказанные выше замечания.

GR>Добро. На выходных буду курить улучшеный план

Давай! Ждем! Это дело очень нужное. Хорошо бы еще проекты подправить, чтобы они не пересобирались если нет изменений.