Здравствуйте, _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 вроде бы ещё до меня сделали. И простейший проект собирается. Только кажется что это не связано с моими изменениями.
Но тесты по прежнему не билдятся.
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]
Здравствуйте, Вестильд, Вы писали:
В>Ура! Я впилил патч с 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 .
Есть мнение, что проще плюнуть и приспособить Nemerle к распространению через NuGet (то есть рантайма, компилятора, вообще всего). Нет, правда, тащить что-то в GAC — это моветон. Заодно автоматически починится проблема "не работает интеграция со студией после обновления, так как в GAC остались старые сборки".
Для Mono же отладочные символы можно всегда сконвертить в моновский формат через pdb2mdb.
Здравствуйте, 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 с правильным выхлопом.
Здравствуйте, Вестильд, Вы писали:
В>Мы же в *nix Nemerle продвинуть хотим. Какой Powershell?
Вот такой. Используют Pash. Будущее наступило полгода назад, да.
Повторюсь, хватит мусорить в GAC, это порочная практика, создающая ненужные проблемы при сборке/деплое.
И вообще, сложные 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
Звучит разумно. А расширение для студии сейчас в общем инсталляторе?
Надо будет тогда его отделить, чтобы он через менеджер плагинов в студии ставился.
