Я закомитил новую версию скрипта NemerleAll.nproj.
Что в ней нового:
1. Сборка компилятора, инструментов, интеграции и инсталлятора никак не зависит от наличия или отсутствия папки $(ProgramFiles)\Nemerle
2. Файл Compiler.MSBuild.targets больше не используется.
3. Добавлен батник BuildInstallerFast.cmd. Он позволяет собрать инсталлятор из Stage1 (значительно быстрее, чем из Stage4)
Инсталлятор собирается в конфигурации Release. Для сборки в конфигурации Debug еще нужно будет докручивать nemerle.wixproj, т.к. пока не понятно, где брать *.xml.
После установки только что собранного инсталлятора Visual Studio у меня нормально работала, а вот NemerleStudio отказалась. У меня есть подозрения, что причиной этого может быть файл Nemerle.VisualStudio.pkgdef, т.к. в нем фигурируют абсолютные пути, специфичные для моей машины. После инсталляции на девственно чистой машине (установлена только Visual Studio) в реестре фигурируют эти самые пути.
И еще, мне пришлось в nemerle.wixproj добавить вот такую инструкцию:
Дело в том, что в конфигурации Debug файл Nemerle.VisualStudio.pkgdef копируется в bin\Debug, а в конфигурации Release — не копируется в bin\Release.
Пришлось копировать из obj\Release. Может здесь какой-то косяк.
З.Ы. Доработка Nemerle.MSBuild.Tasks.dll для указания пути к Ncc.exe помогла
Здравствуйте, gloomy rocker, Вы писали:
GR>Дело в том, что в конфигурации Debug файл Nemerle.VisualStudio.pkgdef копируется в bin\Debug, а в конфигурации Release — не копируется в bin\Release. GR>Пришлось копировать из obj\Release. Может здесь какой-то косяк.
А кто нибудь в курсе, зачем в инсталятору нужны и файл Nemerle.VisualStudio.pkgdef и файл vs2008.wxi? Имхо они дублируют друг друга.
Причем Nemerle.VisualStudio.pkgdef герерируется автоматически по атрибутам класса NemerlePackage, а vs2008.wxi по моему поддерживается вручную. Хотя утилита regpkg, котороая генерирует pkgdef, умеет также создавать и wxi файлы, для этого ее следует запускать с ключом /wixfile, как это описано в статье Tutorial: Simple VSPackage Deployment / Deployment By Using the Windows Installer XML Toolset (http://msdn.microsoft.com/en-us/library/bb458038.aspx).
Возможно я просто не разобрался с процессом сборки и vs2008.wxi тоже генерируется автоматически? Если нет, то неплохо бы избавиться от такого дублирования.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, gloomy rocker, Вы писали:
VD>Все это здорово. Но что нужно задать в командной строке, чтобы собрать отладочную версию проекта (без инсталлятора, но с интеграцией)?
Вот такой батник должен сделать то, что тебе нужно:
set MSBuild="%SystemRoot%\Microsoft.NET\Framework\v3.5\msbuild.exe"
%MSBuild% NemerleAll.nproj /t:IntegrationFast /p:Configuration=Debug
В результате в $(NRoot)\bin\Debug\Stage1 будет лежать собранный компилятор, а бинарники интеграции будут лежать там, куда настроено в соответствующих проектах.
А вообще могут пригодиться следующие варианты сборки (Здесь "|" означает или):
%MSBuild% NemerleAll.nproj /t:Stage1 /p:Configuration=Debug|Release — сборка дебажной или релизной Stage1
%MSBuild% NemerleAll.nproj /t:CompilerTests /p:Configuration=Debug|Release — запуск тестов дебажной или релизной Stage4 (если нужно, могу сделать цель и для Stage1)
%MSBuild% NemerleAll.nproj /t:Install /p:Configuration=Debug|Release — Пока не работает, но будет копировать и NGen-ить все необходимое в $(ProgramFiles)\Nemerle
GR>В результате в $(NRoot)\bin\Debug\Stage1 будет лежать собранный компилятор, а бинарники интеграции будут лежать там, куда настроено в соответствующих проектах.
Облом.
Проект "C:\Nemerle\NemerleAll.nproj" (1) выполняет построение "C:\Nemerle\VsIntegration\Shell\NemerleStudio\NemerleStudio.vcproj" (14) на узле 0 (конечные объекты Rebuild).
C:\Nemerle\VsIntegration\Shell\NemerleStudio\NemerleStudio.vcproj : warning MSB4098: MSBuild вызывает VCBuild для сборки проекта. При сборке автономных проектов VC++ перекрестные ссылки между проектами VC++ (.VCPROJ) и проектами C#/VB/VJ# (.CSPROJ, .VBPROJ, .VJSPROJ) не поддерживаются системами, управляемыми из командной строки. Сборка проектов, содержащих такие перекрестные ссылки, невозможна. Вместо этого создайте файл решения с этим проектом.
vcbuild.exe : error VCBLD0004: Project 'C:\Nemerle\VsIntegration\Shell\NemerleStudio\NemerleStudio.vcproj' does not contain
a configuration called 'Debug'.
Причем, я даже не понял, что это за NemerleStudio.vcproj. Может это просто где-то опечатка и имеломсь в виду NemerleStudio.csproj ?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, gloomy rocker, Вы писали:
VD>Причем, я даже не понял, что это за NemerleStudio.vcproj. Может это просто где-то опечатка и имеломсь в виду NemerleStudio.csproj ?
Посмотрел внимательнее... это проект собирающий что-то для NemerleStudio. Но ее не нужно собирать для целей отладки.
1. Можно как-то не собирать этот проект?
2. Что с ним? Почему он не собирается?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, gloomy rocker, Вы писали:
VD>>Причем, я даже не понял, что это за NemerleStudio.vcproj. Может это просто где-то опечатка и имеломсь в виду NemerleStudio.csproj ?
VD>Посмотрел внимательнее... это проект собирающий что-то для NemerleStudio. Но ее не нужно собирать для целей отладки.
VD>1. Можно как-то не собирать этот проект? VD>2. Что с ним? Почему он не собирается?
Не собирается потому, что "does not contain a configuration called 'Debug'".
Нужно добавить в проект соответствующую конфигурацию.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, gloomy rocker, Вы писали:
GR>>Я закомитил новую версию скрипта NemerleAll.nproj.
KV>Полагаю, что BuildInstallerRelease.cmd можно удалить за ненадобностью? (для полной сборки теперь вполне хватает BuildInstallerFull.cmd)
Думаю, вполне можно. Изобилие батников только вводит в заблужение.
Здравствуйте, VladD2, Вы писали:
VD>Посмотрел внимательнее... это проект собирающий что-то для NemerleStudio. Но ее не нужно собирать для целей отладки.
VD>1. Можно как-то не собирать этот проект?
Можно сделать раздельную компиляцию интеграции и NemerleStudio. И соответствующие цели для этого.
Здравствуйте, gloomy rocker, Вы писали:
GR>Не собирается потому, что "does not contain a configuration called 'Debug'". GR>Нужно добавить в проект соответствующую конфигурацию.
Ее Павел Блудов из-за какой-то зависимости ранее убрал.
Здравствуйте, gloomy rocker, Вы писали:
GR>Не собирается потому, что "does not contain a configuration called 'Debug'". GR>Нужно добавить в проект соответствующую конфигурацию.
Я поступил проще. Я убрал эти проекты из дебажной конфигурации. Добавить в них ее нельзя. Точные причины знает только Павел Блудов.
И вообще, в текущем состоянии собирать инсталлятор в дебаге нельзя. Нужно просто добавить генерацию PDB в релиз.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
У меня тут возник вопрос по поводу цели "Install". Хотелось бы, чтобы она копировала и регистрировала сборки из bin\Satge1 если перед этим выполнялся цель IntegrationFast и из bin\Satge4 если перед этим выполнялся цель IntegrationFull. Как это можно сделать?
Из цели можно объявлять или менять свойства? Тогда в IntegrationFull и IntegrationFast можно было бы установить одно свойство — путь к бинарникам, и использовать его в цели Install.
ЗЫ
Я там направил NemerleAll.nproj. Добавил две цели: DevBuildFast и DevBuildFull. Она должны компилировать и регистрировать девелоперскую версию студии. Как отладим, я махну старые батники чтобы он вызвали эти цели.
Посмотри, не напортичил ли я чего?
Потом, у меня возникла одна проблема:
Я ввел свойство TargetName. Расчет был на то, что это значение этого свойства будет подставляться в значение атрибута Targets задачи MSBuild. Но что-то не выходит каменный цветок. Если используется значение по умолчанию для этого свойства (т.е. Rebuild, см. строку 4 в NemerleAll.nproj), то все работает как предполагалось. Но если я задаю значение свойства через параметр МСБилда "/p:TargetName=Build", то все бинарники получают имя Build.*. Почему это так и что делать, я так и не разобрался. Меж тем для работы над проектом при вызове цели DevBuildFast лучше использовать Build, а не Rebuild, так как зачастую все компилироваться нет смысла.
Нет мыслей по поводу того в чем я ошибся?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
А расскажите плиз, как сейчас правильно собирать немерле для запуска отладочной версии интеграции?
Я деинсталировал интеграцию, полностью удалил старые исходники, удалил папку c:\program files\nemerle.
Затем скачал все заново из репозитория и теперь не могу собрать билд для отладки.
Я раньше использовал комбинацию из Build-1-phase.cmd и VsIntegration\build_dev.cmd, но сейчас (rev 8604) она не работает (
Build-1-phase.cmd вылетает с сообщением:
D:\Projects\Nemerle\svn\Nemerle.nproj(32,11): error MSB4019:
The imported project "D:\Projects\Nemerle\svn\boot\Nemerle.MSBuild.targets" was not found.
Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
Build.cmd вылетает с такой же ошибкой.
Если скопировать вручную \tools\msbuild-task\Nemerle.MSBuild.targets в \boot\Nemerle.MSBuild.targets, то Build-1-phase.cmd отрабатывает без ошибок, но затем начинает вылетать VsIntegration\build_dev.cmd:
D:\Projects\Nemerle\svn\VsIntegration\Nemerle.Compiler.Utils.Tests\Nemerle.Compiler.Utils.Tests.csproj(100,11):
error MSB4019: The imported project "D:\Nemerle.MSBuild.targets" was not found.
Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
Сборка почемуто ищет файл targets в корне диска d:
Здравствуйте, seregaa, Вы писали:
S>Если скопировать вручную \tools\msbuild-task\Nemerle.MSBuild.targets в \boot\Nemerle.MSBuild.targets, то Build-1-phase.cmd отрабатывает без ошибок, но затем начинает вылетать VsIntegration\build_dev.cmd: S>
S>D:\Projects\Nemerle\svn\VsIntegration\Nemerle.Compiler.Utils.Tests\Nemerle.Compiler.Utils.Tests.csproj(100,11):
S>error MSB4019: The imported project "D:\Nemerle.MSBuild.targets" was not found.
S>Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
S>
Удалось собрать, создав предварительно вручную папку c:\program files\nemerle и скопировав в нее файлы из boot
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, gloomy rocker, Вы писали:
VD>А можно собирать компилятор в духстдийном режиме + интеграцию и выполнять тесты?
В данный момент тесты заточены только на Stage4, но если нужно, можно и для Stage2 сделать. Я попробую ввести свойство NStage, которое будет устанавливаться в конце каждой стадии и указывать на последние собранные бинарники. Потом его можно будет использовать в других целях (например в Install, CompilerTests). А еще лучше добавить 2 свойства NCurStage и NPrevStage. Тогда можно будет и цель Validate обобщить.
Здравствуйте, gloomy rocker, Вы писали:
VD>>А можно собирать компилятор в духстдийном режиме + интеграцию и выполнять тесты? GR>В данный момент тесты заточены только на Stage4, но если нужно, можно и для Stage2 сделать. Я попробую ввести свойство NStage, которое будет устанавливаться в конце каждой стадии и указывать на последние собранные бинарники. Потом его можно будет использовать в других целях (например в Install, CompilerTests). А еще лучше добавить 2 свойства NCurStage и NPrevStage. Тогда можно будет и цель Validate обобщить.
Это было бы то что нужно. Давай!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>У меня тут возник вопрос по поводу цели "Install". Хотелось бы, чтобы она копировала и регистрировала сборки из bin\Satge1 если перед этим выполнялся цель IntegrationFast и из bin\Satge4 если перед этим выполнялся цель IntegrationFull. Как это можно сделать?
VD>Из цели можно объявлять или менять свойства? Тогда в IntegrationFull и IntegrationFast можно было бы установить одно свойство — путь к бинарникам, и использовать его в цели Install.
Думаю, можно. Надо попробовать.
VD>ЗЫ
VD>Я там направил NemerleAll.nproj. Добавил две цели: DevBuildFast и DevBuildFull. Она должны компилировать и регистрировать девелоперскую версию студии. Как отладим, я махну старые батники чтобы он вызвали эти цели. VD>Посмотри, не напортичил ли я чего?
Ок. Посмотрю.
VD>Потом, у меня возникла одна проблема: VD>Я ввел свойство TargetName. Расчет был на то, что это значение этого свойства будет подставляться в значение атрибута Targets задачи MSBuild. Но что-то не выходит каменный цветок. Если используется значение по умолчанию для этого свойства (т.е. Rebuild, см. строку 4 в NemerleAll.nproj), то все работает как предполагалось. Но если я задаю значение свойства через параметр МСБилда "/p:TargetName=Build", то все бинарники получают имя Build.*. Почему это так и что делать, я так и не разобрался. Меж тем для работы над проектом при вызове цели DevBuildFast лучше использовать Build, а не Rebuild, так как зачастую все компилироваться нет смысла.
Цель Rebuild там стоит намеренно, т.к. в данный момент в bin\$(Configuration)\StageX бинарники складируются по стадиям, а в obj\$(Configuration) все лежит в одной куче. И чтобы obj очищался перед каждой фазой я и поставил насильственный Rebuild. Нужно сделать так, чтобы в obj бинарники складировались так же как в bin. Тогда цель Build будет собираться корректно.
VD>Нет мыслей по поводу того в чем я ошибся?
Судя по тому, что я видел в истории изменения NemerleAll.nproj, проблема уже решена. Дело было в отсутствии "$" (вместо (TargetName) нужно было $(TargetName)).
По крайней мере сейчас со сборкой проблем нет.
Здравствуйте, gloomy rocker, Вы писали:
VD>>Из цели можно объявлять или менять свойства? Тогда в IntegrationFull и IntegrationFast можно было бы установить одно свойство — путь к бинарникам, и использовать его в цели Install. GR>Думаю, можно. Надо попробовать.
Попробуй. Это решило бы проблему информирования цели Install о том из какой стадии брать бинарники.
GR>Цель Rebuild там стоит намеренно, т.к. в данный момент в bin\$(Configuration)\StageX бинарники складируются по стадиям, а в obj\$(Configuration) все лежит в одной куче. И чтобы obj очищался перед каждой фазой я и поставил насильственный Rebuild. Нужно сделать так, чтобы в obj бинарники складировались так же как в bin. Тогда цель Build будет собираться корректно.
Так давай это сделаем. Что для этого нужно?
VD>>Нет мыслей по поводу того в чем я ошибся? GR>Судя по тому, что я видел в истории изменения NemerleAll.nproj, проблема уже решена. Дело было в отсутствии "$" (вместо (TargetName) нужно было $(TargetName)). GR>По крайней мере сейчас со сборкой проблем нет.
К сожалению нет.
Если выполнить следующее:
set MSBuild="%SystemRoot%\Microsoft.NET\Framework\v3.5\msbuild.exe"
%MSBuild% NemerleAll.nproj /target:DevBuildFast /p:Configuration=Debug /p:TargetName=Build
То происходит следующее:
C:\Nemerle>set MSBuild="C:\Windows\Microsoft.NET\Framework\v3.5\msbuild.exe"
C:\Nemerle>"C:\Windows\Microsoft.NET\Framework\v3.5\msbuild.exe" NemerleAll.nproj /target:DevBuildFast /p:Configuration=Debug
/p:TargetName=Build
Microsoft (R) Build Engine Version 3.5.30729.1
[Microsoft .NET Framework версии 2.0.50727.4200]
(C) Корпорация Майкрософт (Microsoft Corp.), 2007.
Построение начато 14.03.2010 23:25:36.
Проект "C:\Nemerle\NemerleAll.nproj" на узле 0 (конечные объекты DevBuildFast).
Framework tools found at:
MSBuild - c:\Windows\Microsoft.NET\Framework\v3.5\msbuild.exe
NGen - "C:\Windows\Microsoft.NET\Framework\v2.0.50727\ngen.exe"
SDK tools found at:
GacUtil - "C:\Program Files\Microsoft SDKs\Windows\v6.0A\\bin\gacutil.exe"
Ildasm - "C:\Program Files\Microsoft SDKs\Windows\v6.0A\\bin\ildasm.exe"
PEVerify - "C:\Program Files\Microsoft SDKs\Windows\v6.0A\\bin\peverify.exe"
ExternalDependences:
Junction - C:\Nemerle\ExternalDependences\junction.exe
Stage1:
Копирование файла из "C:\Nemerle\tools\msbuild-task\Nemerle.MSBuild.targets" в "C:\Nemerle\boot\Nemerle.MSBuild.targets".
Проект "C:\Nemerle\NemerleAll.nproj" (1) выполняет построение "C:\Nemerle\Nemerle.nproj" (2) на узле 0 (конечные объекты Build).
Копирование файла из "obj\Debug\Build.dll" в "C:\Nemerle\bin\Debug\Stage1\Build.dll".
Nemerle -> C:\Nemerle\bin\Debug\Stage1\Build.dll
Копирование файла из "obj\Debug\Build.pdb" в "C:\Nemerle\bin\Debug\Stage1\Build.pdb".
...
Nemerle.Macros -> C:\Nemerle\bin\Debug\Stage1\Build.dll
IncrementalClean:
Удаление файла "C:\Nemerle\obj\Debug\Nemerle.Macros.dll".
Удаление файла "C:\Nemerle\obj\Debug\Nemerle.Macros.pdb".
Удаление файла "C:\Nemerle\bin\Debug\Stage1\Nemerle.Macros.dll".
Удаление файла "C:\Nemerle\bin\Debug\Stage1\Nemerle.Macros.pdb".
Завершенный проект сборки "C:\Nemerle\Nemerle.Macros.nproj" (конечные объекты Build).
Проект "C:\Nemerle\NemerleAll.nproj" (1) выполняет построение "C:\Nemerle\NCC.nproj" (5) на узле 0 (конечные объекты Build).
ncc\main.n(55,23,55,35): error : unbound type name `ManagerClass'
ncc\main.n(56,23,56,41): error : unbound type name `CompilationOptions'
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Если можно, сделай как можно скорее возможность собирать интеграцию и компилятор в двух-стадийном режиме. А то 4 стадии + тесты и проверки — это очень долго. Для процесса разработки двух стадий без тестов достаточно. Главное понимать, что компилятор не угроблен и можно двигаться дальше. А уж четырех-стадийную сборку можно вызывать один раз перед комитом.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, gloomy rocker, Вы писали:
VD>>>Из цели можно объявлять или менять свойства? Тогда в IntegrationFull и IntegrationFast можно было бы установить одно свойство — путь к бинарникам, и использовать его в цели Install. GR>>Думаю, можно. Надо попробовать.
VD>Попробуй. Это решило бы проблему информирования цели Install о том из какой стадии брать бинарники.
Похоже, работает
GR>>Цель Rebuild там стоит намеренно, т.к. в данный момент в bin\$(Configuration)\StageX бинарники складируются по стадиям, а в obj\$(Configuration) все лежит в одной куче. И чтобы obj очищался перед каждой фазой я и поставил насильственный Rebuild. Нужно сделать так, чтобы в obj бинарники складировались так же как в bin. Тогда цель Build будет собираться корректно.
VD>Так давай это сделаем. Что для этого нужно?
Проблема решена. Для задачи MSBuild нужно было устанавливать дополнительное свойство IntermediateOutputPath.
VD>>>Нет мыслей по поводу того в чем я ошибся? GR>>Судя по тому, что я видел в истории изменения NemerleAll.nproj, проблема уже решена. Дело было в отсутствии "$" (вместо (TargetName) нужно было $(TargetName)). GR>>По крайней мере сейчас со сборкой проблем нет.
VD>К сожалению нет.
VD>Если выполнить следующее:
[skip]
Есть подозрение, что свойство TargetName является предопределенным... И используется для именования результирующих сборок.
Думаю, если переименовать его в NTargetName, то должно заработать.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, gloomy rocker, Вы писали:
VD>Да... и еще один вопрос...
VD>А почему в NemerleAll.nproj проекты компилятора и интеграции перечислены явно вместо того чтобы компилировать соответствующие решения (sln-файлы)?
Была идея использовать свойство TargetOutputs задачи MSBuild, в которое помещаются пути к скомпилированным сборкам. Но где-то прочитал, что работает это только если задать конкретные проекты. Сейчас это свойство не используется, так что можно использовать sln.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, gloomy rocker, Вы писали:
VD>Если можно, сделай как можно скорее возможность собирать интеграцию и компилятор в двух-стадийном режиме. А то 4 стадии + тесты и проверки — это очень долго. Для процесса разработки двух стадий без тестов достаточно. Главное понимать, что компилятор не угроблен и можно двигаться дальше. А уж четырех-стадийную сборку можно вызывать один раз перед комитом.
Этим и занимаюсь.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, gloomy rocker, Вы писали:
VD>И вот еще что... В IntegrationFull нужно еще включить выполнение тестов для интеграции.
VD>Это должно быть что-то вроде: VD>???\nunit-console.exe Nemerle.Compiler.Utils.Tests.dll /nologo
Согласен. Сделаю как только десяток-другой свободных минут выкрою.
Здравствуйте, gloomy rocker, Вы писали:
VD>>Это должно быть что-то вроде: VD>>???\nunit-console.exe Nemerle.Compiler.Utils.Tests.dll /nologo GR>Согласен. Сделаю как только десяток-другой свободных минут выкрою.
Сам сделал. Сейчас зайлью.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, gloomy rocker, Вы писали:
VD>>>Это должно быть что-то вроде: VD>>>???\nunit-console.exe Nemerle.Compiler.Utils.Tests.dll /nologo GR>>Согласен. Сделаю как только десяток-другой свободных минут выкрою.
VD>Сам сделал. Сейчас зайлью.
Я пытался сравнить на уровне IL Stage1 и Stage2. Они оказались идентичны. Это должно настораживать?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, gloomy rocker, Вы писали:
GR>>Я пытался сравнить на уровне IL Stage1 и Stage2. Они оказались идентичны. Это должно настораживать?
VD>Почему?
Затрудняюсь обосновать, но когда я года полтора назад работал над этой задачей, понадобилось 4 стадии, чтобы различия между предыдущей и последней стадиями исчезли. А сейчас различий между Stage1 и Stage2 нет. Возможно, это потому, что boot относительно свежий. А вообще я ни тогда ни сейчас не могу понять, почему нужно именно 4 стадии. По идее в худшем случае должно быть достаточно трех.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, gloomy rocker, Вы писали:
VD>>>А можно собирать компилятор в духстдийном режиме + интеграцию и выполнять тесты? GR>>В данный момент тесты заточены только на Stage4, но если нужно, можно и для Stage2 сделать. Я попробую ввести свойство NStage, которое будет устанавливаться в конце каждой стадии и указывать на последние собранные бинарники. Потом его можно будет использовать в других целях (например в Install, CompilerTests). А еще лучше добавить 2 свойства NCurStage и NPrevStage. Тогда можно будет и цель Validate обобщить.
VD>Это было бы то что нужно. Давай!
Готово.
Похоже сравнение сборок работает некорректно. Я тут подпатчил компилятор так чтобы он генерировал код для операторов >, <, <=, >= более похожий на C#-ный, но это привело к тому, что стадия проверки il-а стала сбоить. При этом сам компилятор собирается и все тесты проходят на ура.
У меня очень весомое подозрение на то, что проверка работает не верно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.