Сообщение msbuild поверх xml - была плохая идея? от 22.11.2023 1:21
Изменено 22.11.2023 6:13 Эйнсток Файр
msbuild поверх xml - была плохая идея?
Мир в принципе отказывается от XML дублируя все его стандарты в комплекте технологий Json.
Какие идеи лежали в основе решения использовать XML?
1) не надо писать парсер под специфичный язык, можно использовать единый код XML-парсера.
(то же самое соображение действует и для Json)
2) использовать "декларативный подход", что бы это ни значило.
(то же самое соображение действует и для Json)
Одной из проблем XML-файлов является их "монолитность",
например, когда надо подключать классы из другой .dll-ки нельзя просто взять и положить рядом второй файл,
надо вписывать строки в уже существующий:
https://github.com/dotnet/msbuild/blob/main/src/Tasks/Microsoft.Common.tasks#L105-L107
это мешает интеграции с пакетными менеджерами.
(теоретически это решаемо, но не средствами XML, надо смотреть что там в коде msbuild)
В принципе непонятно, что мешало сделать любой произвольный 25-ый стандарт DSL для сборки.
Вот, например, в пакетном менеджере для Ruby прямо используют язык Ruby и не стесняются,
а в NixOS отдельный язык Nix, и ничего, нормально.
Или в powershell на C# пишут. И в msbuild могли бы так же, как в powershell.
Как считаете, msbuild заменят новой утилитой сборки (например на основе haskell), или всё, это навсегда?
Какие идеи лежали в основе решения использовать XML?
1) не надо писать парсер под специфичный язык, можно использовать единый код XML-парсера.
(то же самое соображение действует и для Json)
2) использовать "декларативный подход", что бы это ни значило.
(то же самое соображение действует и для Json)
Одной из проблем XML-файлов является их "монолитность",
например, когда надо подключать классы из другой .dll-ки нельзя просто взять и положить рядом второй файл,
надо вписывать строки в уже существующий:
https://github.com/dotnet/msbuild/blob/main/src/Tasks/Microsoft.Common.tasks#L105-L107
это мешает интеграции с пакетными менеджерами.
(теоретически это решаемо, но не средствами XML, надо смотреть что там в коде msbuild)
В принципе непонятно, что мешало сделать любой произвольный 25-ый стандарт DSL для сборки.
Вот, например, в пакетном менеджере для Ruby прямо используют язык Ruby и не стесняются,
а в NixOS отдельный язык Nix, и ничего, нормально.
Или в powershell на C# пишут. И в msbuild могли бы так же, как в powershell.
Как считаете, msbuild заменят новой утилитой сборки (например на основе haskell), или всё, это навсегда?
msbuild поверх xml - была плохая идея?
Мир в принципе отказывается от XML дублируя все его стандарты в комплекте технологий Json.
Какие идеи лежали в основе решения использовать XML?
1) не надо писать парсер под специфичный язык, можно использовать единый код XML-парсера.
(то же самое соображение действует и для Json)
2) использовать "декларативный подход", что бы это ни значило.
(то же самое соображение действует и для Json)
Одной из проблем XML-файлов является их "монолитность",
например, когда надо подключать классы из другой .dll-ки нельзя просто взять и положить рядом второй файл,
надо вписывать строки в уже существующий:
https://github.com/dotnet/msbuild/blob/main/src/Tasks/Microsoft.Common.tasks#L105-L107
это мешает интеграции с пакетными менеджерами.
(теоретически это решаемо, но не средствами XML, надо смотреть что там в коде msbuild)
Если они такие умные и предусмотрительные, что же они не сделали вывод процесса сборки и вывод списка ошибок в виде XML, чтобы их было легче парсить для последующих интеграций?
В принципе непонятно, что мешало сделать любой произвольный 25-ый стандарт DSL для сборки.
Вот, например, в пакетном менеджере для Ruby прямо используют язык Ruby и не стесняются,
а в NixOS отдельный язык Nix, и ничего, нормально.
Или в powershell на C# пишут. И в msbuild могли бы так же, как в powershell.
Как считаете, msbuild заменят новой утилитой сборки (например на основе haskell), или всё, это навсегда?
Какие идеи лежали в основе решения использовать XML?
1) не надо писать парсер под специфичный язык, можно использовать единый код XML-парсера.
(то же самое соображение действует и для Json)
2) использовать "декларативный подход", что бы это ни значило.
(то же самое соображение действует и для Json)
Одной из проблем XML-файлов является их "монолитность",
например, когда надо подключать классы из другой .dll-ки нельзя просто взять и положить рядом второй файл,
надо вписывать строки в уже существующий:
https://github.com/dotnet/msbuild/blob/main/src/Tasks/Microsoft.Common.tasks#L105-L107
это мешает интеграции с пакетными менеджерами.
(теоретически это решаемо, но не средствами XML, надо смотреть что там в коде msbuild)
Если они такие умные и предусмотрительные, что же они не сделали вывод процесса сборки и вывод списка ошибок в виде XML, чтобы их было легче парсить для последующих интеграций?
В принципе непонятно, что мешало сделать любой произвольный 25-ый стандарт DSL для сборки.
Вот, например, в пакетном менеджере для Ruby прямо используют язык Ruby и не стесняются,
а в NixOS отдельный язык Nix, и ничего, нормально.
Или в powershell на C# пишут. И в msbuild могли бы так же, как в powershell.
Как считаете, msbuild заменят новой утилитой сборки (например на основе haskell), или всё, это навсегда?