Исключительно в контексте сравнения группы проектов Delphi 7 — которая на самом деле make файл но включает в себя только компиляцию и то с особенностями, с msbuild сборочными проектами современных Delphi которые уже способны полностью провести сборку из исходников.
Кстати brcc часто ломается на всякой фигне, лучше использовать rc из windows sdk.
brcc ломался от .ico с большим количеством разрешений. Были и другие поломки (вроде все тоже с разными вариантами графики) но точно уже не вспомню.
Её даже на живой винде упаковать в учётную запись сборочного агента проблематично бывает.
При этом если общаться с техподдержкой то они заявляют что можно поставить на сборочный сервер чисто компилятор без IDE. Вот только нигде нет (не было лет несколько назад) как это сделать. А руками сидеть и вылавливать зависимости нет никакого желания.
Я правильно понимаю, что multilang version info — это когда в version info содержится несколько блоков с разными language code?
Мне кажется, и это можно кастомизировать скриптом, а не руками делать )
Да, это когда в зависимости от локали ОС будет показано описание на соответствующем языке. Скриптами не получится, потому что rc генерирует расширение msbuild. Поставляемая на .net вместе с Delphi библиотека. И она просто физически не способна переварить формат отличный от того, который есть в .dproj. То есть кастомизировать скриптом будет означать всё равно генерацию rc руками и дальнейшую сборку :).
Идея использовать IDE для сборки уже почти никому не нравится. Но далеко не все вещи готовы к полноценной работе вне среды (речь не о Delphi, она это почти победила).
В целом неплохо.
Действительно в современных Delphi используется msbuild и это уже хоть какой то сборочный стандарт, который позволяет для простых случаев отказаться от самописных сборочных скриптов.
К сожалению в приближенной к реальности ситуации всё равно не получится.
Рассмотрим тот же VersionInfo — .dproj не умеет multilang. Это большой шаг вперёд по сравнению с Delphi 7 которая вообще не умеет генерировать .res без IDE, но всё ещё не спасает от необходимости генерировать .res руками.
Возможность передать Defines в сборку — замечательно. Но вот сама Delphi уж очень ограничена в возможностях своих Define и вставить ими в исходник например дату сборки не получится. Всё равно нужна кодогенерация или патч исходников. И вот уже дополнительный шаг сборки.
Можно упомянуть про prebuild и postbuild (и вы скорее всего напишете про них в следующих статьях), но это тоже не решение всех проблем. Они имеют сильную завязку на окружение. И есть сценарии где шагами сборочного сервера решить задачу будет проще чем шагами проекта.
В целом хорошо что статьи появляются. Глобально есть очень много тёмных пятен. Например мало кто использует динамическую линковку компонентов, потому что возникают сложности с распространением нужных bpl со своим продуктом. (и это при том, что многие опенсорс компоненты по лицензии требуют именно динамическую линковку).
Мало кто понимает что такое bpl\dcu и прочие файлы генерируемые Delphi.
Не все различают файлы проекта и файлы IDE лежащие рядом с проектом и не знают чего добавить в гитигнор.
Так что буду ждать новых статей. Может увижу и для себя что-то полезное.
В мобильном приложении для рекламной выдачи на главной странице в меню по многоточию есть какая то неочевидная опция типа «скрыть» или «не интересно» (не могу назвать точнее, как на зло именно сейчас выдаёт рекламу чего-то гуглового и ней нет этой опции, хотя обычно всякую фигню). И когда нажимаешь — выскакивает опрос «почему вам не понравилось» и там среди пунктов ответа есть «мошенничество».
А это заменит связку gitlab community как хостинг гита + TeamCity Enterprise на 3 агента как CI и багтрекер вообще отдельно и всё это добро на 200 пользователей?
Причём вопрос не только в функциональности, но и пожалуй в цене.
Для хостинга гит репозиториев оно будет кушать ресурсов больше чем гитлаб или меньше?
Сможет ли оно нормально работать на изолированной от интернета машине? (ну понятно что без всяких зеркаилрований репозиториев из коробки.)
Можно ли в нём отключить все вот эти чатики и так далее?
С одной стороны хочется верить что уж у JetBrains то точно получится нормально сделать всё в одном. С другой стороны пока ни один из таких многоликих проектов не выполняет хорошо всё что умеет, а из за этой многоликости страдает основная функциональность :(
Актуализация зависимостей, это когда несколько разработчиков используют разные пакеты и иногда им надо обновляться.
Если я в своё время правильно понял документацию на кеширующие npm прокси, когда изучал вопрос, то просто добавить новые файлы в их хранилище не получится и надо сначала взять с сервера полный кеш, потом на нём обновиться, потом вернуть обновлённый обратно на сервер. Но изучал я этот вопрос больше года назад. Мог что-то не правильно понять сам. Могла измениться ситуация за это время.
Решал подобную задачу на скорую руку. Вариант с кеширующим прокси мне не понравился. Он плохо масштабируется если нескольким разработчикам надо актуализировать зависимости.
Решил вопрос некрасиво, но руки не доходят сделать лучше.
Поднял локальный коуч и набрасал на том же node зеркалирующую утилиту. Она парсит package-lock.json, выгружате пакеты с оригинального npm и публикает на локальной версии, если их там нет. К сожалению резолвинг версий ломается полностью и без package-lock.json проекты в большинстве случаев не собрать.
Плюс очень много проблем с тем же gyp. И есть проблемы с правами доступа на коуч. Заливать пакеты как есть (с оригинальными авторами и информацией) можно только из под всея админа коуча.
Для полноценной реализации нужна и сильная доработка оригинальных npm скриптов на коуч, и серьёзная доработка зеркалирующей утилиты.
Очень грустно, что многие веб разработчики с которыми я общался о вопросах зеркалирования даже не задумываются считая интернет вечным.
После отправки правой панели в правила адблока интерфейс стал хоть чуть чуть юзабельным.
Если нажать из письма не кнопку вернуться а «почта» в верхней навигационной панели — получаем осминожью морду и двух а то и трёх секундную перезагрузку страницы.
То что это чудо с главной страницы мейла стало открываться в отдельном окне… Оно к лучшему да. Теперь я не бываю на главной странице мейла и экономлю трафик и нервы не видя обилия рекламы главной странице.
Грустно видеть как очередной раз дизайн побеждает здравый смысл.
Неожиданно узнал что PVS умеет в Embedded…
А совсем жёсткий Embedded — microchip xc семейство C-подобных компиляторов планируется?
На TI Code Composer Studio проектах обязательно поробую, когда будет больше свободного времени.
Сейчас в CLion можно собраться и отладиться без проблем в рамках одной машины (локальной или удалённой). Это хорошо и здорово.
Но когда надо собраться на одной машине, а отладиться на другой — надо сделать большое количество действий руками: перенести собранную программу, запустить gdb сервер, подключиться к серверу из Clion.
Ошибка, падение,… — руками перезапускать gdb сервер. Изменение — руками переносить собранный файл.
В моём случае железо это почти обычный Linux. Просто на ARM. С обычным ssh и прочими радостями жизни. Но ресурсов железа не хватит чтоб прям там собирать программу и пользоваться возможностью удалённой разработки. Нужна именно простая удалённая отладка. То есть грубо говоря rsync бинарника и запуск gdb сервера через ssh.
И WSL мне нужен как среда разработки но не как среда отладки. Из WSL мне всё равно надо будет скопировать приложение на целевое устройство, запустить gdb сервер и далее по пунктам.
Я смотрю приоритет отдался удалённой разработке, а как идут дела в вопросах удалённой отладки, удалённого профилирования и т.д.?
Есть локальная машина на которой идёт разработка, на ней все исходники, cmake, SDK целевой платформы. Целевая платформа это linux на ARM устройстве.
Проект собирается. Отлично. Проект можно руками перенести на целевую платформу, запустить под gdb сервером, создать конфигурацию удалённой отладки и ок, это в целом даже будет работать. Но это неудобно.
Хочется один раз настроить удалённую машину и получить синхронизацию. Собирать приложение сразу туда, запускать из среды разработки.
Может подобные сценарии будут рассматриваться в рамках вашей работы под Embedded?
Или ещё более сложные, например разработка под WSL и отладка на железе?
На сколько я понял с ценообразованием история немного другая.
У тебя всего два варианта — либо как решил стим, либо руками фиксированная сумма в конечной валюте.
А разработчикам хочется что-то вроде бегунка, который может выставить региональную цену как N% от основной цены с автопересчётом по текущему курсу или хотя бы фиксированную цену в своей валюте с автопересчётом.
И это не какая то великая сложность. Стим и так делает это, но только строго по своим статистическим процентам.
Хороший список.
А для Pascal/Delphi не планируете сделать анализатор? Там в списке про такой язык упоминают в комментариях два универсальных анализатора. :)
Если есть желание привлечь разработчиков — сделайте хорошие статьи по архитектуре radare2. Что в основе, как работает, что под капотом.
Наверняка читали «Образ мышления — дизассемблер IDA.» от Криса Касперски? Вот наверное чего-то такого не хватает для radare2.
А на сколько честно говорить про площадь, если ячейки перестали быть «плоскими»?..
Понятно что маркетологи и упаковка, но разве теперь не надо говорить про объём ячеек?
Или это связано с тех процессами и ключевой характеристикой всё ещё остаётся площадь?
Я не знаю как правильно сформулировать вопрос, по этому попробую описать ситуацию…
Существует разрабатываемый энтузиастами плагин для IDEA I-Pascal, для поддержки языка pascal соответственно. При этом он строится на проектной (модульной) модели IDEA. Но на самом деле проекты pascal очень близки по своей структуре к C++. В них включенные в проект файлы определяются файлом системы сборки, там же указываются дополнительные зависимости, параметры. В Pascal так же активно применяется препроцессор (не такой функциональный как c++, но так же влияющий на поведение кода, его разбор, анализ и рефакторинг).
Сейчас вы активно развиваете проектную модель и я хотел бы спросить — попадут ли эти наработки в основную IDEA и станут ли доступны для написания языковых плагинов к языкам с похожим поведением? Конкретно — построение структуры проекта из условной сборочной системы и обслуживание препроцессора?
Исключительно в контексте сравнения группы проектов Delphi 7 — которая на самом деле make файл но включает в себя только компиляцию и то с особенностями, с msbuild сборочными проектами современных Delphi которые уже способны полностью провести сборку из исходников.
Кстати brcc часто ломается на всякой фигне, лучше использовать rc из windows sdk.
brcc ломался от .ico с большим количеством разрешений. Были и другие поломки (вроде все тоже с разными вариантами графики) но точно уже не вспомню.
При этом если общаться с техподдержкой то они заявляют что можно поставить на сборочный сервер чисто компилятор без IDE. Вот только нигде нет (не было лет несколько назад) как это сделать. А руками сидеть и вылавливать зависимости нет никакого желания.
Для версий с ограниченным сроком жизни, например.
Да, это когда в зависимости от локали ОС будет показано описание на соответствующем языке. Скриптами не получится, потому что rc генерирует расширение msbuild. Поставляемая на .net вместе с Delphi библиотека. И она просто физически не способна переварить формат отличный от того, который есть в .dproj. То есть кастомизировать скриптом будет означать всё равно генерацию rc руками и дальнейшую сборку :).
Идея использовать IDE для сборки уже почти никому не нравится. Но далеко не все вещи готовы к полноценной работе вне среды (речь не о Delphi, она это почти победила).
Действительно в современных Delphi используется msbuild и это уже хоть какой то сборочный стандарт, который позволяет для простых случаев отказаться от самописных сборочных скриптов.
К сожалению в приближенной к реальности ситуации всё равно не получится.
Рассмотрим тот же VersionInfo — .dproj не умеет multilang. Это большой шаг вперёд по сравнению с Delphi 7 которая вообще не умеет генерировать .res без IDE, но всё ещё не спасает от необходимости генерировать .res руками.
Возможность передать Defines в сборку — замечательно. Но вот сама Delphi уж очень ограничена в возможностях своих Define и вставить ими в исходник например дату сборки не получится. Всё равно нужна кодогенерация или патч исходников. И вот уже дополнительный шаг сборки.
Можно упомянуть про prebuild и postbuild (и вы скорее всего напишете про них в следующих статьях), но это тоже не решение всех проблем. Они имеют сильную завязку на окружение. И есть сценарии где шагами сборочного сервера решить задачу будет проще чем шагами проекта.
В целом хорошо что статьи появляются. Глобально есть очень много тёмных пятен. Например мало кто использует динамическую линковку компонентов, потому что возникают сложности с распространением нужных bpl со своим продуктом. (и это при том, что многие опенсорс компоненты по лицензии требуют именно динамическую линковку).
Мало кто понимает что такое bpl\dcu и прочие файлы генерируемые Delphi.
Не все различают файлы проекта и файлы IDE лежащие рядом с проектом и не знают чего добавить в гитигнор.
Так что буду ждать новых статей. Может увижу и для себя что-то полезное.
Причём вопрос не только в функциональности, но и пожалуй в цене.
Для хостинга гит репозиториев оно будет кушать ресурсов больше чем гитлаб или меньше?
Сможет ли оно нормально работать на изолированной от интернета машине? (ну понятно что без всяких зеркаилрований репозиториев из коробки.)
Можно ли в нём отключить все вот эти чатики и так далее?
С одной стороны хочется верить что уж у JetBrains то точно получится нормально сделать всё в одном. С другой стороны пока ни один из таких многоликих проектов не выполняет хорошо всё что умеет, а из за этой многоликости страдает основная функциональность :(
Если я в своё время правильно понял документацию на кеширующие npm прокси, когда изучал вопрос, то просто добавить новые файлы в их хранилище не получится и надо сначала взять с сервера полный кеш, потом на нём обновиться, потом вернуть обновлённый обратно на сервер. Но изучал я этот вопрос больше года назад. Мог что-то не правильно понять сам. Могла измениться ситуация за это время.
Решил вопрос некрасиво, но руки не доходят сделать лучше.
Поднял локальный коуч и набрасал на том же node зеркалирующую утилиту. Она парсит package-lock.json, выгружате пакеты с оригинального npm и публикает на локальной версии, если их там нет. К сожалению резолвинг версий ломается полностью и без package-lock.json проекты в большинстве случаев не собрать.
Плюс очень много проблем с тем же gyp. И есть проблемы с правами доступа на коуч. Заливать пакеты как есть (с оригинальными авторами и информацией) можно только из под всея админа коуча.
Для полноценной реализации нужна и сильная доработка оригинальных npm скриптов на коуч, и серьёзная доработка зеркалирующей утилиты.
Очень грустно, что многие веб разработчики с которыми я общался о вопросах зеркалирования даже не задумываются считая интернет вечным.
Если нажать из письма не кнопку вернуться а «почта» в верхней навигационной панели — получаем осминожью морду и двух а то и трёх секундную перезагрузку страницы.
То что это чудо с главной страницы мейла стало открываться в отдельном окне… Оно к лучшему да. Теперь я не бываю на главной странице мейла и экономлю трафик и нервы не видя обилия рекламы главной странице.
Грустно видеть как очередной раз дизайн побеждает здравый смысл.
А совсем жёсткий Embedded — microchip xc семейство C-подобных компиляторов планируется?
На TI Code Composer Studio проектах обязательно поробую, когда будет больше свободного времени.
Но когда надо собраться на одной машине, а отладиться на другой — надо сделать большое количество действий руками: перенести собранную программу, запустить gdb сервер, подключиться к серверу из Clion.
Ошибка, падение,… — руками перезапускать gdb сервер. Изменение — руками переносить собранный файл.
В моём случае железо это почти обычный Linux. Просто на ARM. С обычным ssh и прочими радостями жизни. Но ресурсов железа не хватит чтоб прям там собирать программу и пользоваться возможностью удалённой разработки. Нужна именно простая удалённая отладка. То есть грубо говоря rsync бинарника и запуск gdb сервера через ssh.
И WSL мне нужен как среда разработки но не как среда отладки. Из WSL мне всё равно надо будет скопировать приложение на целевое устройство, запустить gdb сервер и далее по пунктам.
Есть локальная машина на которой идёт разработка, на ней все исходники, cmake, SDK целевой платформы. Целевая платформа это linux на ARM устройстве.
Проект собирается. Отлично. Проект можно руками перенести на целевую платформу, запустить под gdb сервером, создать конфигурацию удалённой отладки и ок, это в целом даже будет работать. Но это неудобно.
Хочется один раз настроить удалённую машину и получить синхронизацию. Собирать приложение сразу туда, запускать из среды разработки.
Может подобные сценарии будут рассматриваться в рамках вашей работы под Embedded?
Или ещё более сложные, например разработка под WSL и отладка на железе?
У тебя всего два варианта — либо как решил стим, либо руками фиксированная сумма в конечной валюте.
А разработчикам хочется что-то вроде бегунка, который может выставить региональную цену как N% от основной цены с автопересчётом по текущему курсу или хотя бы фиксированную цену в своей валюте с автопересчётом.
И это не какая то великая сложность. Стим и так делает это, но только строго по своим статистическим процентам.
А для Pascal/Delphi не планируете сделать анализатор? Там в списке про такой язык упоминают в комментариях два универсальных анализатора. :)
Наверняка читали «Образ мышления — дизассемблер IDA.» от Криса Касперски? Вот наверное чего-то такого не хватает для radare2.
Понятно что маркетологи и упаковка, но разве теперь не надо говорить про объём ячеек?
Или это связано с тех процессами и ключевой характеристикой всё ещё остаётся площадь?
Существует разрабатываемый энтузиастами плагин для IDEA I-Pascal, для поддержки языка pascal соответственно. При этом он строится на проектной (модульной) модели IDEA. Но на самом деле проекты pascal очень близки по своей структуре к C++. В них включенные в проект файлы определяются файлом системы сборки, там же указываются дополнительные зависимости, параметры. В Pascal так же активно применяется препроцессор (не такой функциональный как c++, но так же влияющий на поведение кода, его разбор, анализ и рефакторинг).
Сейчас вы активно развиваете проектную модель и я хотел бы спросить — попадут ли эти наработки в основную IDEA и станут ли доступны для написания языковых плагинов к языкам с похожим поведением? Конкретно — построение структуры проекта из условной сборочной системы и обслуживание препроцессора?