Здравствуйте, Вестильд, Вы писали:
В>Мы же в *nix Nemerle продвинуть хотим. Какой Powershell?
Вот такой. Используют Pash. Будущее наступило полгода назад, да.
Повторюсь, хватит мусорить в GAC, это порочная практика, создающая ненужные проблемы при сборке/деплое.
Ура! Я впилил патч с ItemDefinitionGroup, ItemGroup и PropertyGroup в Target вроде бы ещё до меня сделали. И простейший проект собирается. Только кажется что это не связано с моими изменениями.
Но тесты по прежнему не билдятся.
xbuild Tests.nproj /p:TargetFrameworkVersion=v4.5 /p:Configuration=Release /tv:4.0
ncc/testsuite/test.n(342,29): error : expected list[Nemerle.Compiler.ISource], got list[string-] in assigned value: System.String is not a subtype of Nemerle.Compiler.ISource [simple require]
У меня таки собрался DevBuildFull под 4.5
Только для этого пришлось сделать в NemerleAll.nproj для PEVerify ContinueOnError="False" (https://bugzilla.xamarin.com/show_bug.cgi?id=4147 видимо никто не собирается исправлять)
и в Linq.nproj и CSharpParser.nproj сделать <NoStdLib>false</NoStdLib>. Поднятия не имею почему именно эти не хотят билдится.
При билде падают 6 тестов, я не стал разбираться — какие.
Билд Tests.nproj по прежнему падает
ncc/testsuite/test.n(342,29): error : expected list[Nemerle.Compiler.ISource], got list[string-] in assigned value: System.String is not a subtype of Nemerle.Compiler.ISource [simple require]
такая же ошибка под виндой
На данный момент я хочу переключится на создание nuget пакета с всем необходимым для билда.
Кажется, что это будет проще, и гораздо быстрее, чем делать линуксовый пакет. Пока он попадёт хотя бы в убунту, пройдёт наверно пол года.
Есть мнение, что проще плюнуть и приспособить Nemerle к распространению через NuGet (то есть рантайма, компилятора, вообще всего). Нет, правда, тащить что-то в GAC — это моветон. Заодно автоматически починится проблема "не работает интеграция со студией после обновления, так как в GAC остались старые сборки".
Для Mono же отладочные символы можно всегда сконвертить в моновский формат через pdb2mdb.
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, _NN_, Вы писали:
_NN>Итак хорошие новости. _NN>Моно из мастера таки умеет собирать компилятор из исходников
Точно умеет? Там последний комментарий
Rodrigo Kumpera 2014-02-20 15:05:51 EST
Reverted Zoltan's fix.
We should keep the old behavior when possible. Now we're using getrlimit to get
the max thread stack size.
И, если не секрет, как его собрать-то? Я пробовал так:
git clone https://github.com/rsdn/nemerle.git && cd nemerle
bash configure.sh
make -j 8
В ответ получил
make[1]: Вход в каталог `/home/pbludov/src/nemerle/ncc'
make[2]: Вход в каталог `/home/pbludov/src/nemerle/ncc'
make[2]: Вход в каталог `/home/pbludov/src/nemerle/ncc'
make[2]: Вход в каталог `/home/pbludov/src/nemerle/ncc'
MKDIR out.stage1
MKDIR out.stage3
MKDIR out.stage2
make[3]: Вход в каталог `/home/pbludov/src/nemerle/ncc'
make[3]: *** Нет правила для сборки цели `out.stage1/ncc.exe', требуемой для `out.stage2/Nemerle.stage2.dll'. Останов.
make[3]: Выход из каталога `/home/pbludov/src/nemerle/ncc'
make[2]: *** [aux-stage] Ошибка 2
make[2]: Выход из каталога `/home/pbludov/src/nemerle/ncc'
make[1]: *** [stage2] Ошибка 2
make[1]: *** Ожидание завершения заданий...
make[3]: Вход в каталог `/home/pbludov/src/nemerle/ncc'
make[3]: *** Нет правила для сборки цели `out.stage2/ncc.exe', требуемой для `out.stage3/Nemerle.dll'. Останов.
make[3]: Выход из каталога `/home/pbludov/src/nemerle/ncc'
make[2]: *** [last-stage] Ошибка 2
make[2]: Выход из каталога `/home/pbludov/src/nemerle/ncc'
make[1]: *** [stage3] Ошибка 2
make[3]: Вход в каталог `/home/pbludov/src/nemerle/ncc'
make[3]: *** Нет правила для сборки цели `typing/MType.n', требуемой для `out.stage1/Nemerle.Compiler.stage1.dll'. Останов.
make[3]: Выход из каталога `/home/pbludov/src/nemerle/ncc'
make[2]: *** [aux-stage] Ошибка 2
make[2]: Выход из каталога `/home/pbludov/src/nemerle/ncc'
make[1]: *** [stage1] Ошибка 2
make[1]: Выход из каталога `/home/pbludov/src/nemerle/ncc'
make: *** [all] Ошибка 2
Здравствуйте, Блудов Павел, Вы писали:
БП>Здравствуйте, _NN_, Вы писали:
_NN>>Итак хорошие новости. _NN>>Моно из мастера таки умеет собирать компилятор из исходников БП>Точно умеет? Там последний комментарий БП>
Rodrigo Kumpera 2014-02-20 15:05:51 EST
БП>Reverted Zoltan's fix.
БП>We should keep the old behavior when possible. Now we're using getrlimit to get
БП>the max thread stack size.
Не могу найти этот коммит.
На всякий случай я говорю про ветку master.
БП>И, если не секрет, как его собрать-то? Я пробовал так:
make давно никто не поддерживает в актуальном состоянии.
Есть xbuild.
[MonoTODO]
public override bool Execute ()
{
throw new NotImplementedException ();
}
Последние изменения у этого файла были 7 лет назад. Полагаю, его нужно просто взять и написать.
Вот оригинальный код для примера:
using Microsoft.Build.Framework;
using Microsoft.Build.Shared;
using Microsoft.Build.Utilities;
using System;
using System.Collections;
using System.Globalization;
using System.Reflection;
using System.Runtime;
using System.Text;
namespace Microsoft.Build.Tasks
{
public class GetAssemblyIdentity : TaskExtension
{
private ITaskItem[] assemblyFiles;
private ITaskItem[] assemblies;
[Required]
public ITaskItem[] AssemblyFiles
{
get
{
ErrorUtilities.VerifyThrowArgumentNull((object) this.assemblyFiles, "assemblyFiles");
return this.assemblyFiles;
}
[TargetedPatchingOptOut("Performance critical to inline this type of method across NGen image boundaries")] set
{
this.assemblyFiles = value;
}
}
[Output]
public ITaskItem[] Assemblies
{
[TargetedPatchingOptOut("Performance critical to inline this type of method across NGen image boundaries")] get
{
return this.assemblies;
}
[TargetedPatchingOptOut("Performance critical to inline this type of method across NGen image boundaries")] set
{
this.assemblies = value;
}
}
[TargetedPatchingOptOut("Performance critical to inline this type of method across NGen image boundaries")]
public GetAssemblyIdentity()
{
}
public override bool Execute()
{
ArrayList arrayList = new ArrayList();
foreach (ITaskItem taskItem in this.AssemblyFiles)
{
AssemblyName assemblyName;
try
{
assemblyName = AssemblyName.GetAssemblyName(taskItem.ItemSpec);
}
catch (BadImageFormatException ex)
{
this.Log.LogErrorWithCodeFromResources("GetAssemblyIdentity.CouldNotGetAssemblyName", (object) taskItem.ItemSpec, (object) ex.Message);
continue;
}
catch (Exception ex)
{
if (ExceptionHandling.NotExpectedException(ex))
{
throw;
}
else
{
this.Log.LogErrorWithCodeFromResources("GetAssemblyIdentity.CouldNotGetAssemblyName", (object) taskItem.ItemSpec, (object) ex.Message);
continue;
}
}
ITaskItem destinationItem = (ITaskItem) new TaskItem(assemblyName.FullName);
destinationItem.SetMetadata("Name", assemblyName.Name);
if (assemblyName.Version != (Version) null)
destinationItem.SetMetadata("Version", ((object) assemblyName.Version).ToString());
if (assemblyName.GetPublicKeyToken() != null)
destinationItem.SetMetadata("PublicKeyToken", GetAssemblyIdentity.ByteArrayToHex(assemblyName.GetPublicKeyToken()));
if (assemblyName.CultureInfo != null)
destinationItem.SetMetadata("Culture", assemblyName.CultureInfo.ToString());
taskItem.CopyMetadataTo(destinationItem);
arrayList.Add((object) destinationItem);
}
this.Assemblies = (ITaskItem[]) arrayList.ToArray(typeof (ITaskItem));
return !this.Log.HasLoggedErrors;
}
private static string ByteArrayToHex(byte[] a)
{
if (a == null)
return (string) null;
StringBuilder stringBuilder = new StringBuilder(a.Length);
foreach (byte num in a)
stringBuilder.Append(num.ToString("X02", (IFormatProvider) CultureInfo.InvariantCulture));
return ((object) stringBuilder).ToString();
}
}
}
Свежие вести с полей.
Компилятор собирает все 4 стадии, собирает библиотеки и запускает тесты
Осталось только разобраться почему некоторые (всего 5) тесты падают.
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, _NN_, Вы писали:
_NN>Свежие вести с полей. _NN>Компилятор собирает все 4 стадии, собирает библиотеки и запускает тесты _NN>Осталось только разобраться почему некоторые (всего 5) тесты падают.
Здравствуйте, Аноним, Вы писали:
А>НемерлиВеб требуется?
Для чего ? Для сборки компилятора ?
Для сборки компилятора нужен только компилятор
И Mono собранный из мастера, не уверен, что на 3.4.0 все работает.
: error : Target '_ComputeNonExistentFileProperty', a dependency of target 'CoreCompile', not found.
Done building project "/ld/program/nemerle/nemerle-trunk/nemerle/Nemerle.nproj".-- FAILED
моно собрано из мастера (пару недель назад).
Проблема случаем не в том, что "Item/PropertyGroups in targets" не реализовано?
Я вроде реализовал ItemDefinitionGroup. Вернее адаптировал патч с этим, который у них в багтрекере валялся лет 5.
В том что он корректен (и что я его корректно втянул в текущую версию) у меня сомнения, но вроде бы сам моно с ним собирается.
А сборка Немерле одинаково падает, что на патченной версии, что на чистой из мастера.
Здравствуйте, Вестильд, Вы писали:
В>выпадают ошибки: В>
В>: error : Target '_ComputeNonExistentFileProperty', a dependency of target 'CoreCompile', not found.
В> Done building project "/ld/program/nemerle/nemerle-trunk/nemerle/Nemerle.nproj".-- FAILED
В>
Target '_ComputeNonExistentFileProperty' для msbuild находится в Microsoft.Common.targets, надо найти где оно в моно и подключить.
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, Вестильд, Вы писали:
В>>выпадают ошибки: В>>
В>>: error : Target '_ComputeNonExistentFileProperty', a dependency of target 'CoreCompile', not found.
В>> Done building project "/ld/program/nemerle/nemerle-trunk/nemerle/Nemerle.nproj".-- FAILED
В>>
Z>Target '_ComputeNonExistentFileProperty' для msbuild находится в Microsoft.Common.targets, надо найти где оно в моно и подключить.
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, Вестильд, Вы писали:
В>>Я правильно понимаю, что причина в том, что моно не умеет "Item/PropertyGroups in targets"?
H>Да, там нужно CreateItem кажется городить, который в свежем MSBuild-е стал Obsolete.
Это вы предлагаете в Nemerle? Может лучше mono допилить?
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, Вестильд, Вы писали:
В>>Это вы предлагаете в Nemerle? Может лучше mono допилить?
_NN>Конечно лучше, но кто этим займется ?
Ну вот я пытаюсь. Вроде адаптировал старый патч с ItemDefinitionGroup.
Моя проблема в том, что почти не разбираюсь в MSBuild, и соответственно не понимаю, каким должен быть результат.
Ну и в open source никогда не комитил, надо научится это делать.
Здравствуйте, Вестильд, Вы писали:
В>Здравствуйте, _NN_, Вы писали:
_NN>>Здравствуйте, Вестильд, Вы писали:
В>>>Это вы предлагаете в Nemerle? Может лучше mono допилить?
_NN>>Конечно лучше, но кто этим займется ?
В>Ну вот я пытаюсь. Вроде адаптировал старый патч с ItemDefinitionGroup.
Я пытался адаптировать но в итоге не сработало https://bugzilla.xamarin.com/show_bug.cgi?id=10017
В>Моя проблема в том, что почти не разбираюсь в MSBuild, и соответственно не понимаю, каким должен быть результат.
Компилятор должен собираться
В>Ну и в open source никогда не комитил, надо научится это делать.
Это как раз проще всего.
Форк в github-е на github.com/mono/mono
Коммитим, пушим.
А сам пул реквест через веб можно сделать, в ващем форке даже сама кнопочка появится
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, Вестильд, Вы писали:
В>>Здравствуйте, _NN_, Вы писали:
_NN>>>Здравствуйте, Вестильд, Вы писали:
В>>>>Это вы предлагаете в Nemerle? Может лучше mono допилить?
_NN>>>Конечно лучше, но кто этим займется ?
В>>Ну вот я пытаюсь. Вроде адаптировал старый патч с ItemDefinitionGroup. _NN>Я пытался адаптировать но в итоге не сработало _NN>https://bugzilla.xamarin.com/show_bug.cgi?id=10017
ArgumentNullException фиксится одной строчкой, вот только я опять же не понимаю, правильно ли я её пофиксил.
В>>Моя проблема в том, что почти не разбираюсь в MSBuild, и соответственно не понимаю, каким должен быть результат. _NN>Компилятор должен собираться
компилятор-то и так собирается. я про то, что я очень плохо понимаю, как должны работать недостающие фичи xbuild-а.
В>>Ну и в open source никогда не комитил, надо научится это делать. _NN>Это как раз проще всего. _NN>Форк в github-е на github.com/mono/mono _NN>Коммитим, пушим. _NN>А сам пул реквест через веб можно сделать, в ващем форке даже сама кнопочка появится
наверно в нём надо будет сразу ветку под это дело открыть. только вопрос от какого коммита её делать? HEAD master-а естественно нифига не билдится.
Можно взять последний коммит в мастере, который билдился (он 26 сентября был https://jenkins.mono-project.com/job/test-mono-mainline/label=debian-amd64/)
а можно от mono-3.12.0-branch идти. Что посоветуете?
Здравствуйте, Вестильд, Вы писали:
В>Здравствуйте, _NN_, Вы писали:
_NN>>Здравствуйте, Вестильд, Вы писали:
В>>>Здравствуйте, _NN_, Вы писали:
_NN>>>>Здравствуйте, Вестильд, Вы писали:
В>>>>>Это вы предлагаете в Nemerle? Может лучше mono допилить?
_NN>>>>Конечно лучше, но кто этим займется ?
В>>>Ну вот я пытаюсь. Вроде адаптировал старый патч с ItemDefinitionGroup. _NN>>Я пытался адаптировать но в итоге не сработало _NN>>https://bugzilla.xamarin.com/show_bug.cgi?id=10017
В>ArgumentNullException фиксится одной строчкой, вот только я опять же не понимаю, правильно ли я её пофиксил.
Можно тест добавить простой. ItemDefinitionGroup
В принципе это как CreateItem + CreateProperty но проще в использовании.
Можно взять какой-нибудь готовый msbuild файл с этим делом и проверить.
Referencing Item Metadata in a Project File
В>>>Моя проблема в том, что почти не разбираюсь в MSBuild, и соответственно не понимаю, каким должен быть результат. _NN>>Компилятор должен собираться В>компилятор-то и так собирается. я про то, что я очень плохо понимаю, как должны работать недостающие фичи xbuild-а.
А Peg собирается тоже ?
В>>>Ну и в open source никогда не комитил, надо научится это делать. _NN>>Это как раз проще всего. _NN>>Форк в github-е на github.com/mono/mono _NN>>Коммитим, пушим. _NN>>А сам пул реквест через веб можно сделать, в ващем форке даже сама кнопочка появится
В>наверно в нём надо будет сразу ветку под это дело открыть. только вопрос от какого коммита её делать? HEAD master-а естественно нифига не билдится. В>Можно взять последний коммит в мастере, который билдился (он 26 сентября был https://jenkins.mono-project.com/job/test-mono-mainline/label=debian-amd64/) В>а можно от mono-3.12.0-branch идти. Что посоветуете?
Да тут как угодно, если свой форк то можно хоть с веткой хоть без.
Странно, обычно у меня мастер всегда собирается.
Я думаю не важно откуда начинать, в этой части все рано никто не меняет код и конфликтов не будет.
Здравствуйте, Вестильд, Вы писали:
В>Ура! Я впилил патч с ItemDefinitionGroup, ItemGroup и PropertyGroup в Target вроде бы ещё до меня сделали. И простейший проект собирается. Только кажется что это не связано с моими изменениями.
В>Но тесты по прежнему не билдятся. В>DevBuildFull тоже не билдится
Тут есть другая проблема.
Если посмотреть в консоль то можно заметить , что берется всегда компилятор из Stage1, вместо 2,3 и 4.
Похоже проблема еще не решена.
Также при компиляции берутся зависимости без /macro из-за нерабочего Condition="%(ReferencePath.OutputItemType) != 'macro'" о котором я писал.
Тут даже не знаю как чинить, разве что надеется на открытие кода MSBuild
В>Изменения в репозитории https://github.com/vestild/mono/tree/improve_msbuild В>Кто бы глянул? В>И что с ними теперь делать? Push request в мастер основного репозитория?
Конечно !
Я только не понял зачем менять ToolsVersion=4.0 на 3.5 .
Здравствуйте, kekekeks, Вы писали:
K>Есть мнение, что проще плюнуть и приспособить Nemerle к распространению через NuGet (то есть рантайма, компилятора, вообще всего). Нет, правда, тащить что-то в GAC — это моветон. Заодно автоматически починится проблема "не работает интеграция со студией после обновления, так как в GAC остались старые сборки". K>Для Mono же отладочные символы можно всегда сконвертить в моновский формат через pdb2mdb.
Только это не работает для пуристов , которые собирают все исключительно через исходники.
Как например требует ideone.com .
Здравствуйте, kekekeks, Вы писали:
K>Есть мнение, что проще плюнуть и приспособить Nemerle к распространению через NuGet (то есть рантайма, компилятора, вообще всего). Нет, правда, тащить что-то в GAC — это моветон. Заодно автоматически починится проблема "не работает интеграция со студией после обновления, так как в GAC остались старые сборки". K>Для Mono же отладочные символы можно всегда сконвертить в моновский формат через pdb2mdb.
Проблема в сборке .nproj. Можно ли с помощью NuGet добавлять необходимые таргеты и таски?
Здравствуйте, Вестильд, Вы писали:
В>Здравствуйте, kekekeks, Вы писали:
K>>Есть мнение, что проще плюнуть и приспособить Nemerle к распространению через NuGet (то есть рантайма, компилятора, вообще всего). Нет, правда, тащить что-то в GAC — это моветон. Заодно автоматически починится проблема "не работает интеграция со студией после обновления, так как в GAC остались старые сборки". K>>Для Mono же отладочные символы можно всегда сконвертить в моновский формат через pdb2mdb.
В>Проблема в сборке .nproj. Можно ли с помощью NuGet добавлять необходимые таргеты и таски?
Здравствуйте, _NN_, Вы писали:
_NN>Можно все что угодно. _NN>К примеру: https://www.nuget.org/packages/MSBuildTasks/
_NN>NuGet умеет запускать Powershell скрипт, там вообще можно делать что хотим.
Мы же в *nix Nemerle продвинуть хотим. Какой Powershell?
Вообще цель — пакет deb/rpm. Чтобы поставил пакет, и можешь xbuild Solution.sln с правильным выхлопом.
И вообще, сложные PowerShell-скрипты не обязательны. Достаточно чтобы Nemerle ставил всё нужное ему, включая MSBuild-таски, в packages/Nemerle.1.2.3 (что NuGet делает без всяких скриптов сам), а содержимое nproj указывало туда, а не на C:\Program Files\Nemerle или куда там всё устанавливается. Разве что симлинк какой стоит сделать для упрощения жизни.
Здравствуйте, Вестильд, Вы писали:
В>Мы же в *nix Nemerle продвинуть хотим. Какой Powershell?
А тогда какой NuGet ?
В>Вообще цель — пакет deb/rpm. Чтобы поставил пакет, и можешь xbuild Solution.sln с правильным выхлопом.
А зачем собирать если будет пакет ?
Кстати есть старый deb 0.9.3: https://launchpad.net/ubuntu/+source/nemerle
Здравствуйте, kekekeks, Вы писали:
K>Здравствуйте, Вестильд, Вы писали:
В>>Мы же в *nix Nemerle продвинуть хотим. Какой Powershell?
K>Вот такой. Используют Pash. Будущее наступило полгода назад, да.
Круто.
Только в мире *Nix все равно удобнее пакетами deb/rpm распространять.
K>Повторюсь, хватит мусорить в GAC, это порочная практика, создающая ненужные проблемы при сборке/деплое.
Тут согласен полностью, даже MS уходят от этого.
Здравствуйте, _NN_, Вы писали:
_NN>Круто. _NN>Только в мире *Nix все равно удобнее пакетами deb/rpm распространять.
Распространять что? Конечный софт — да. Библиотеки же по меньшей мере странно, это противоречит заложенному в .NET принципу распространения ПО "всё своё ношу с собой".
Посмотрите на список .NET-библиотек в репозиториях Ubuntu. Знаете, что их объединяет? Они либо поставляются как часть Mono, либо имеют нативные зависимости. Исключением являются MySql.Data, JSON.NET и libnini, которые нужны для работы MonoDevelop. Всё. Больше ничего нигде по пакетам не раскидывали, хотя .NET-приложений на GTK# в репозиториях предостаточно. Просто потому что это не имеет смысла. Зачем мучиться со сборкой и захламлять GAC, если можно сделать нормальное решение.
Да и сам переход на NuGet для Nemerle будет благом. Что имеем сейчас?
1) для работы над проектом Nemerle должен быть установлен на билд-сервере
2) каждый разработчик должен регулярно обновлять версию рантайма, которая глобальна
3) нет возможности работать над проектами, использующими разные версии Nemerle, если в одном новая что-то ломает, а в другом нужен позарез какой-то багфикс, надо каждый раз удалять и ставить нужную
4) единственный способ нормально распространять через NuGet библиотеки, написанные на Nemerle — использовать ILMerge и не выставлять наружу никаких немерлеспецифичных типов, что бред
Идеально:
1) рантайм и компилятор подключаются NuGet-пакетом
2) солюшн собирается на любом компьютере с .NET 4.0
Здравствуйте, kekekeks, Вы писали:
K>Идеально: K>1) рантайм и компилятор подключаются NuGet-пакетом K>2) солюшн собирается на любом компьютере с .NET 4.0
Здравствуйте, kekekeks, Вы писали:
K>Да и сам переход на NuGet для Nemerle будет благом. Что имеем сейчас?
K>1) для работы над проектом Nemerle должен быть установлен на билд-сервере K>2) каждый разработчик должен регулярно обновлять версию рантайма, которая глобальна K>3) нет возможности работать над проектами, использующими разные версии Nemerle, если в одном новая что-то ломает, а в другом нужен позарез какой-то багфикс, надо каждый раз удалять и ставить нужную K>4) единственный способ нормально распространять через NuGet библиотеки, написанные на Nemerle — использовать ILMerge и не выставлять наружу никаких немерлеспецифичных типов, что бред
K>Идеально: K>1) рантайм и компилятор подключаются NuGet-пакетом K>2) солюшн собирается на любом компьютере с .NET 4.0
Звучит разумно. А расширение для студии сейчас в общем инсталляторе?
Надо будет тогда его отделить, чтобы он через менеджер плагинов в студии ставился.
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, Вестильд, Вы писали:
В>>Мы же в *nix Nemerle продвинуть хотим. Какой Powershell? _NN>А тогда какой NuGet ?
В>>Вообще цель — пакет deb/rpm. Чтобы поставил пакет, и можешь xbuild Solution.sln с правильным выхлопом. _NN>А зачем собирать если будет пакет ? _NN>Кстати есть старый deb 0.9.3: https://launchpad.net/ubuntu/+source/nemerle
Я имел ввиду: собирать свой солюшн с проектами на немерле.
Но Немерле тоже должен собираться, иначе не будет пакета
Вообще мне импонирует идея с nuget, но кажется сам nuget тогда неплохо было бы засунуть в пакет , но собирать сам Немерле под моно тоже наверно нужно.
Сильно nuget на powershell завязан? Пакеты с либами скриптов не содержат обычно.
Здравствуйте, Вестильд, Вы писали:
В>Сильно nuget на powershell завязан? Пакеты с либами скриптов не содержат обычно.
Сам NuGet вообще никак не завязан, позволяет просто хуки ставить. Для импорта msbuild-тасков он, по идее, и не нужен, есть вот такой механизм. Можно с PS не заморачиваться, а положить exeшник, который внесёт нужные правки и его дёргать из скрипта.
Здравствуйте, Вестильд, Вы писали:
В>У меня таки собрался DevBuildFull под 4.5 В>Только для этого пришлось сделать в NemerleAll.nproj для PEVerify ContinueOnError="False" (https://bugzilla.xamarin.com/show_bug.cgi?id=4147 видимо никто не собирается исправлять) В>и в Linq.nproj и CSharpParser.nproj сделать <NoStdLib>false</NoStdLib>. Поднятия не имею почему именно эти не хотят билдится.\\
Тут надо смотреть либо баг PEVerify от моно, либо действительно не собирается правильно.
Пробовали запускать PEVerify от .NET на сборку из Моно ? В>При билде падают 6 тестов, я не стал разбираться — какие.
В>Билд Tests.nproj по прежнему падает
В>ncc/testsuite/test.n(342,29): error : expected list[Nemerle.Compiler.ISource], got list[string-] in assigned value: System.String is not a subtype of Nemerle.Compiler.ISource [simple require]
Тут , насколько помню, xbuild не берет компилятор из последующей стадии.
Вроде как всегда брал Stage1, вместо 2 и 3 .
Стоит проверить.
В>такая же ошибка под виндой
В>На данный момент я хочу переключится на создание nuget пакета с всем необходимым для билда.
Тут банально не собираются нормально все стадии с тестами, о каком nuget-е речь ? В>Кажется, что это будет проще, и гораздо быстрее, чем делать линуксовый пакет. Пока он попадёт хотя бы в убунту, пройдёт наверно пол года.
Здравствуйте, _NN_, Вы писали: _NN>Тут надо смотреть либо баг PEVerify от моно, либо действительно не собирается правильно. _NN>Пробовали запускать PEVerify от .NET на сборку из Моно ?
у меня негде толком проверить. я вроде пытался под вайном, но там другие ошибки падали.
Если есть возможность, проверьте: https://yadi.sk/d/HFZhb4XQeDDxh В>>При билде падают 6 тестов, я не стал разбираться — какие.
В>>Билд Tests.nproj по прежнему падает
В>>ncc/testsuite/test.n(342,29): error : expected list[Nemerle.Compiler.ISource], got list[string-] in assigned value: System.String is not a subtype of Nemerle.Compiler.ISource [simple require] _NN>Тут , насколько помню, xbuild не берет компилятор из последующей стадии. _NN>Вроде как всегда брал Stage1, вместо 2 и 3 . _NN>Стоит проверить.
Stage4 использует. И разве с stage1 можно собрать всё, включая Peg и Linq?
лог сборки: https://yadi.sk/i/766hjJc2eDFQo
В>>такая же ошибка под виндой
В>>На данный момент я хочу переключится на создание nuget пакета с всем необходимым для билда. _NN>Тут банально не собираются нормально все стадии с тестами, о каком nuget-е речь ? В>>Кажется, что это будет проще, и гораздо быстрее, чем делать линуксовый пакет. Пока он попадёт хотя бы в убунту, пройдёт наверно пол года.
Да вот вроде бы собираются
PS использую свежий mono 3.12
PPS а как здесь новую тему создать?
[MD]: Warning: MemberRef has a duplicate, token=0x0a002e01. [token:0x0A003298]
[MD]: Warning: MemberRef has a duplicate, token=0x0a003126. [token:0x0A003299]
[MD]: Warning: MemberRef has a duplicate, token=0x0a003129. [token:0x0A00329A]
[MD]: Warning: MemberRef has a duplicate, token=0x0a00312a. [token:0x0A00329B]
All Classes and Methods in Nemerle.Compiler.dll Verified.
(10543 Warnings)
[MD]: Warning: MemberRef has a duplicate, token=0x0a000569. [token:0x0A00056A]
All Classes and Methods in Nemerle.Macros.dll Verified.
(166 Warnings)
http://files.rsdn.ru/16901/a.zip
В>>>ncc/testsuite/test.n(342,29): error : expected list[Nemerle.Compiler.ISource], got list[string-] in assigned value: System.String is not a subtype of Nemerle.Compiler.ISource [simple require] _NN>>Тут , насколько помню, xbuild не берет компилятор из последующей стадии. _NN>>Вроде как всегда брал Stage1, вместо 2 и 3 . _NN>>Стоит проверить. В>Stage4 использует. И разве с stage1 можно собрать всё, включая Peg и Linq? В>лог сборки: https://yadi.sk/i/766hjJc2eDFQo
_NN>Stage3 собирается с помощью Stage1 , а не Stage2.
Да, я не заметил, что ссылки ставятся не туда.
Странный баг, похоже в таске ResolveAssemblyReference.
А почему это важно? На что влияет, какая сборка будет использована в зависимости при сборке?
Здравствуйте, Вестильд, Вы писали:
В>Да, я не заметил, что ссылки ставятся не туда. В>Странный баг, похоже в таске ResolveAssemblyReference. В>А почему это важно? На что влияет, какая сборка будет использована в зависимости при сборке?
Ну это нужно, чтобы доказать работоспособность собранного компилятора.
А потом сравниваются IL выхлопы стадий 3 и 4 через дизассемблер.
Это доказывает, что компилятор точно собирает себя без проблем.
Здравствуйте, Вестильд, Вы писали:
В>открыл баг: https://bugzilla.xamarin.com/show_bug.cgi?id=26395
Года через два думаю починят.
Или раньше если МС портируют их MSBuild В>есть идеи, где копать и как локализовывать?
Ну можно в коде MSBuild добавить Debugger.Launch() и отлаживать.
Только вот все занятия с MSBuild довольно муторно
Здравствуйте, Вестильд, Вы писали:
В>Здравствуйте, _NN_, Вы писали: В>Использование неправильных стадий в ссылках я поборол. Но PEVerify всё равно ругается.
Проблема где была ? В сборке Nemerle или Mono ?
PEVerify от моно наверное починить легко, надо найти этот 0x0000017a и понять что происходит.
А вот даже не знаю, как обычно тут либо баг SRE , либо Mono либо PEVerify
[IL]: Error: [Z:\ld\program\nemerle\nemerle-mono-patched\bin\Release\mono-4.5\Stage4\Nemerle.Compiler.dll : Nemerle.Compiler.Typer+DelayedTyping+_N__N_lambda__122632__122701::apply][offset 0x0000003A] Unable to resolve token.
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, Вестильд, Вы писали:
В>>Здравствуйте, _NN_, Вы писали: В>>Использование неправильных стадий в ссылках я поборол. Но PEVerify всё равно ругается. _NN>Проблема где была ? В сборке Nemerle или Mono ?
В Mono (https://github.com/vestild/mono/commit/c40df43191a202086d32add31556682ab81e2f9d)
_NN>PEVerify от моно наверное починить легко, надо найти этот 0x0000017a и понять что происходит.
Я понятия не имею, что там (там это где?) должно происходить.
_NN>А вот даже не знаю, как обычно тут либо баг SRE , либо Mono либо PEVerify _NN>
Может там не правильно ссылки ставятся. Если я выложу дизасемблированный файлы, это поможет?
По прежнему, чтобы сбилдить дальше, потребовалось в Linq.nproj и CSharpParser.nproj сделать <NoStdLib>false</NoStdLib>. Есть идеи, что там может быть не так?
Зачем вообще во всех этих проектах стоит <NoStdLib>trueNoStdLib>?
Здравствуйте, Вестильд, Вы писали:
_NN>>Проблема где была ? В сборке Nemerle или Mono ? В>В Mono (https://github.com/vestild/mono/commit/c40df43191a202086d32add31556682ab81e2f9d)
Неудивительно Это вошло уже официальный репозиторий ?
_NN>>PEVerify от моно наверное починить легко, надо найти этот 0x0000017a и понять что происходит. В>Я понятия не имею, что там (там это где?) должно происходить.
В>Может там не правильно ссылки ставятся. Если я выложу дизасемблированный файлы, это поможет?
Тут тема сложная.
Я вот открывал баг давно, но его решили отклонить: https://bugzilla.xamarin.com/show_bug.cgi?id=4147
Возможно это еще та же проблема.
В>По прежнему, чтобы сбилдить дальше, потребовалось в Linq.nproj и CSharpParser.nproj сделать <NoStdLib>false</NoStdLib>. Есть идеи, что там может быть не так? В>Зачем вообще во всех этих проектах стоит <NoStdLib>trueNoStdLib>?
Не уверен.
Наверное чтобы не загружать глобальный Nemerle.dll если вдруг есть в системе.
Круто. Значит я зря время тратил. Интересно имеет смысл сейчас разбираться, что там в рантайме падает? Или лучше подождать годик, пока весь .NET портируют?
Здравствуйте, Вестильд, Вы писали:
В>Здравствуйте, kekekeks, Вы писали:
K>>И начали портировать
K>>https://github.com/mono/msbuild K>>http://lists.ximian.com/pipermail/mono-devel-list/2015-March/042854.html
В>Круто. Значит я зря время тратил. Интересно имеет смысл сейчас разбираться, что там в рантайме падает? Или лучше подождать годик, пока весь .NET портируют?
Сомневаюсь что ли починят все баги, и неизвестно сколько это времени займёт.
В>Круто. Значит я зря время тратил. Интересно имеет смысл сейчас разбираться, что там в рантайме падает? Или лучше подождать годик, пока весь .NET портируют?
Я тут что-то не вижу в списке на интеграцию в Mono того же System.Reflection.Emit, например. Вообще есть мнение, что от использования SRE только проблемы (в частности бред с 2 версиями компилятора для 32 и 64 бит), имеет смысл перелезть либо на IKVM.Reflection.Emit, либо на инфраструктуру генерации IL из состава Roslyn.
Здравствуйте, kekekeks, Вы писали:
K>Я тут что-то не вижу в списке на интеграцию в Mono того же System.Reflection.Emit, например. Вообще есть мнение, что от использования SRE только проблемы (в частности бред с 2 версиями компилятора для 32 и 64 бит), имеет смысл перелезть либо на IKVM.Reflection.Emit, либо на инфраструктуру генерации IL из состава Roslyn.
На IKVM я не осилил переписать компилятор, времени потратил довольно много. На Roslyn переходить будет еще сложнее. Потому что нужна не только инфраструктура генерации IL, но еще и чтения метаданных — они связаны между собою.
Здравствуйте, kekekeks, Вы писали:
K>Здравствуйте, Вестильд, Вы писали:
В>>Круто. Значит я зря время тратил. Интересно имеет смысл сейчас разбираться, что там в рантайме падает? Или лучше подождать годик, пока весь .NET портируют?
K>Я тут что-то не вижу в списке на интеграцию в Mono того же System.Reflection.Emit, например. Вообще есть мнение, что от использования SRE только проблемы (в частности бред с 2 версиями компилятора для 32 и 64 бит), имеет смысл перелезть либо на IKVM.Reflection.Emit, либо на инфраструктуру генерации IL из состава Roslyn.
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, kekekeks, Вы писали:
K>>Я тут что-то не вижу в списке на интеграцию в Mono того же System.Reflection.Emit, например. Вообще есть мнение, что от использования SRE только проблемы (в частности бред с 2 версиями компилятора для 32 и 64 бит), имеет смысл перелезть либо на IKVM.Reflection.Emit, либо на инфраструктуру генерации IL из состава Roslyn.
H>На IKVM я не осилил переписать компилятор, времени потратил довольно много. На Roslyn переходить будет еще сложнее. Потому что нужна не только инфраструктура генерации IL, но еще и чтения метаданных — они связаны между собою.
не подхватываются правильные бинарники.
