Comments 12
Спасибо за публикацию, было очень интересно почитать.
Скажите, а есть продвижение в портировании сред разработки NetMF на Linux? Если я правильно понял, Mono для Mac уже поддерживает NetMF, а Mono для linux ещё нет.
Скажите, а есть продвижение в портировании сред разработки NetMF на Linux? Если я правильно понял, Mono для Mac уже поддерживает NetMF, а Mono для linux ещё нет.
Сейчас есть интеграция только с Visual Studio 2015 (Community, Pro or Ultimate editions). Даже компиляция самого дистрибутива требует установленной VisualStudio, потому что используется MSBuild. Боюсь с другими ОС тут туго.
Ну как же? Вот add-in для xamarin: https://developer.xamarin.com/guides/cross-platform/robotics/,
вот репа на гитхабе: https://github.com/DavidKarlas/MonoDevelop.MicroFramework
По отывам запустить на MacOS используя Mono можно, но вот не обновляется ничего давно уже.
вот репа на гитхабе: https://github.com/DavidKarlas/MonoDevelop.MicroFramework
По отывам запустить на MacOS используя Mono можно, но вот не обновляется ничего давно уже.
Спасибо за ссылки. Посмотрим что это такое
MonoDevelop.MicroFramework — это AddIn для Xamarin Studio, который разрабатывался самим Xamarin. Команда разработки .NetMF на текущий момент отношения к этому не имеет.
Но, так как Xamarin был не так давно куплен Microsoft, то может ситуация и поменяется :)
Но, так как Xamarin был не так давно куплен Microsoft, то может ситуация и поменяется :)
Вот ответ разработчиков .NetMF: «There are no current plans to do any additional work to support Xamarin tools. The focus, at the moment, is delivering a great story with VisualStudio.»
Так что пока только VisualStudio.
Так что пока только VisualStudio.
Ну, радует, что он и отвечают, а то по частоте коммитов складывается ощущение, что они почти не занимаются проектом.
Работа идет. Коммиты везде не старше 2х недель.
У авторов системы сборки .NET Micro Framework явно что-то не в порядке с логикой.
Поставили целью универсальность, а смогли портировать только на STM32 и только со сборкой в GCC или MDK.
При этом сборка сложнее чем у линукса.
Я бы предложил в следующих статьях описать что можно выкинуть из системы сборки, что можно заранее скомпилировать и оставить в сборке уже скомпилированным (например все что касается архитектуры ядра ARM и симуляторов).
Почему тот же MetadataProcessor.exe надо билдить каждый раз? Почему все это нельзя вставить уже скомпилированое и готовое к применению?
Самым полезным было бы объяснение структуры директорий и поименное указание какие скрипты что делают.
Но в целом спасибо, что вы актуализируете эту тему. Может еще дотянутся руки в ней окончательно разобраться.
Поставили целью универсальность, а смогли портировать только на STM32 и только со сборкой в GCC или MDK.
При этом сборка сложнее чем у линукса.
Я бы предложил в следующих статьях описать что можно выкинуть из системы сборки, что можно заранее скомпилировать и оставить в сборке уже скомпилированным (например все что касается архитектуры ядра ARM и симуляторов).
Почему тот же MetadataProcessor.exe надо билдить каждый раз? Почему все это нельзя вставить уже скомпилированое и готовое к применению?
Самым полезным было бы объяснение структуры директорий и поименное указание какие скрипты что делают.
Но в целом спасибо, что вы актуализируете эту тему. Может еще дотянутся руки в ней окончательно разобраться.
Изначально я хотел написать что-то типа пошаговой инструкции — как сделать новый порт. Но чем дальше я погружаюсь в эти дебри, тем больше убеждаюсь, что от этого мало толку. Нужно слишком много знать про дистрибутив, чтобы нормально работать с ним и пошаговой инструкцией тут не обойтись.
Во второй части я как раз хочу написать в каких папках что лежит и, в общем виде, что на что там ссылается. Хотя на 100% сам еще не разобрался во всех подробностях. Проблема еще в том, что нет редактора xml скриптов для MSBuild. И, чтобы хоть как то построить дерево ссылок, приходиться чуть ли не в notepad все это дело открывать :)
Думаю я простенький парсер напишу, который мне все это дело хоть как-то ситематизирует.
По поводу универсальности — они почему-то выкинули все ARM7 контроллеры. А их было много. GCC и MDK самые популярные наборы. Тут похоже на правило 20/80. Эти два набора охватывают 80% потребностей. Но, при желании, можно и другие добавить.
Сейчас на GitHub идет дискуссия о том, как же должна выглядеть система сборки. Об этом я хочу написать в третьей части. Рассматривается пакетный подход. Что-то вроде среднее между mVision, CMSIS-Pack и NuGet. У разработчиков есть желание навести в этом всем порядок, но не хочется изобретать велосипед. Работы в этом направлении уже ведутся.
Во второй части я как раз хочу написать в каких папках что лежит и, в общем виде, что на что там ссылается. Хотя на 100% сам еще не разобрался во всех подробностях. Проблема еще в том, что нет редактора xml скриптов для MSBuild. И, чтобы хоть как то построить дерево ссылок, приходиться чуть ли не в notepad все это дело открывать :)
Думаю я простенький парсер напишу, который мне все это дело хоть как-то ситематизирует.
По поводу универсальности — они почему-то выкинули все ARM7 контроллеры. А их было много. GCC и MDK самые популярные наборы. Тут похоже на правило 20/80. Эти два набора охватывают 80% потребностей. Но, при желании, можно и другие добавить.
Сейчас на GitHub идет дискуссия о том, как же должна выглядеть система сборки. Об этом я хочу написать в третьей части. Рассматривается пакетный подход. Что-то вроде среднее между mVision, CMSIS-Pack и NuGet. У разработчиков есть желание навести в этом всем порядок, но не хочется изобретать велосипед. Работы в этом направлении уже ведутся.
А язык F# поддерживается?
Sign up to leave a comment.
Как объять необъятное: система сборки .NET Micro Framework Часть 1