Ще е хубаво да се направи някакво представяне както на тия PlatformIO-та, така и на модерните идеи и философии.
Признавам си напоследък спрях да следя новини, щото отдавна не съм видял нищо ново под Слънцето. Имам предвид като концепции и в тоя смисъл твърденията за стария и затворен мейл не ми звучат някак си оптимистично. Но пък може и да съм изпуснал нещо ...

тя е стара философия, надградена е за узер-френдли

накратко:

аз по принцип съм С динозавър, обаче около 2016 година разни "чайници" около мен ме разпитваха:
- Ардуино тва КАК ???
- ибеш ли мааму, не ме занимавай с "детски" проблеми, учи С...
и ВСИКИ като мен, дори и тези дето хал хабер си нямат от MCU и програмиране изповядват тази теза ...
НО,
един младеж облъчи някакви западняци и продаде над 1000 бройки. на интересно добра цена, индустриално приложение - Ардуино базирано
и ми светна ламбата - бах мааму кво е това Ардуино?
платка, "Hello World", Blink() ...
и кво има "под капака":
С++ супер-луп приложение, стринг библиотека( кат за чайници ) и стандарт за драйвери - нищо особено...
( между другото, историята помни и по-зле реализирани индустриални приложения, по-зле и от Ардуино стил, но това е друга тема )

Около мен се търкаляха разни GSM модули с възможност за писане на приложения вътре в модула
- Епа що не пробвам Ардуино за GSM? ( та даже имаше едно Mediatek LinkIt One )
и то зе че стана за GPRS, LTE и NarrowBand модули ( няма споменавам фирмата - за мен са долнопробни пеераси ... както и да е )

Обаче Ардуино ИДЕ е отврат ... и от клик на клик попадам на PlatformIO ( Ivan Kravets - "нашенец" от Украйна )
историята му е: търсех Python ( опън сорс ) базирана логика за build на ембедед приложения
и попаднал на Scon ( https://scons.org/ ), надградил го с user frendly "екстри" ( да стане по удобно за потребителя ) и се родила идеята за PlatformIO
Arduino IDE killer ... и наистина е така и за повече от 10 години усъвършенстване работи достатъчно добре не само за Ардуино
подържа Зефири, MBED, разни SDK, кво ли не ... недостатък е че поддържа платки, а не чипове
но лично на мен, трябвало ли ми е специфичин чип, SoC, платка - си го писах, като факта е че все още съм Python чайник

кви платформи написах ( нямаха аналог ):
GSM модули, Microsoft AzureSphere, LoRa SoC-ове, Raspberry PI Pico, Microchip XC16, XC32, STM32, Nordic ... и разни други
и те това работи/работеше "перфектно" мултиплатформено .... написано от Pytnon чайник

Не облъчвам никой - просто казвам: разучете го - PlatformIO, та дори и Scon, много вероятно е да ви даде "криле" и да ви спести време, пари и нерви

Други нови билд тенденции не знам ( Джавашките не се интересувам )

Мерси, това е ценно представяне, кратко и ясно. Щото на няколко пъти питах гугъл и той ми пробутва разни дълги общи приказки дето не ми се четат...

Не ми се ще да ти развалям "густото" и изразявам чисто лично мнение, но на мен PlatformIO не ми допада. Прекалено е натруфено, екрана е някак си пълен и всичко ми се вижда адски сложно. Сигурно ми липсва девелопърския майндсет (никога не съм се имал за софтуерен девелопър по принцип). Аз ценя простите и изчистени неща, дори до степен минимализъм, а това е точно в обратната посока. IDE-то на ардуиното е супер грозно, няма спор, но като концепция по-скоро следва минимализма и не натоварва очите с неща по екрана дето нямат отношение към сорса. Трябва само да си намерят един добър UI дизайнер да го поошлайфа визуално. Може пък много хора да харесват тая концепция, не знам...
Както казах, лично мнение и не искам да се дърпаме за тия неща

Четох бегло за идеята на IDE-то, но не ми се изясни. Според презентацията, идеята била улеснение на разработчиците. Един вид сингъл клик, и развойната среда си инсталирала каквото и трябва.
А предвидена ли е възможност инсталацията да става по класическия начин - изтеглям каквото ми трябва и го инсталирам?

по принцип PlatformIO не е IDE, a "билдер" система която "усъвършенства" Scon ( същото като make, ninja, cmake ... но с "отворена" Питон логика )
промт >>> pio run ... от папката на проекта билдва проекта ... до ELF, HEX, BIN ... etc
https://docs.platformio.org/en/latest/c ... d_run.html

PlatformIO се вгражда в около 12 IDE-та ... най-използвано е VSCode
квото може VSCode, Eclips, etc, това "виждаш" на екрана
BTW: VSCode IntelliSense ( подсказки, рисуване на код ... ) е добре развит от микромеките ( на база Атом ) ( много по-развит от Еклипси и други )
https://code.visualstudio.com/docs/editor/intellisense

пак повтарям: недостатъка е че е развит за платки а не за отделни чипове или отделни SDK

също така не съм Ардуино фен, но онзи ден ме питаха как се прави еди какво си в ESP32 IDF и се оказа че в Ардуино ESP е направено много "по-културно", семпло и минималистично , но това го дава производителя не самото IDE или билдера

аз не говоря за IDE а за самия build процес на нящо като С приложение
най-минимум е: notepad .... gcc параметри main.c
после идва makefile с логика на билда компилирана в make, ninja etc
надграждаме със cmake ... пак ограничена логика от самото cmake

scons e същото като горните неща, обаче да се учи тепърва е загуба на време
но всичко което ще напишеш за даден билд е "прост" питон скрипт ( логика колкото позволява самия комп ... дори рънваш и make и cmake )

може да се инсталира станд алоне - терминално без ИДЕ
аз го инсталирам кат плъгин за VSCode,
пробвах го за еклипс и Расбери ПИ Пико - работи, но спрямо VSCode - куцо ИДЕ

На мен ми хареса какво са насътворили Нордиците за Зефир върху Студио Код. Ей тук едно малко дългичко но интересно видео:

https://webinars.nordicsemi.com/introdu ... -vs-code-5

Има идея но за момента като го гледам е само за зефир. Но предполагам, че ако концепцията е читава ще започне да се прилага и по други платформи.

филма показва как да си организираш проект...
това дето са направили Нордиците е само меню екшани за CMAKE, който си зефира на практика
всъщност Зефир билдера е 80% Питон скриптове ( затова преди мислех да го портвам в ПИО )
а С++ / cmake за ВСКод има много отдавна

Да налея малко масло в огъня... Сори, ама това видео не можах да го изгледам.

Това не е толкова важно... друго искам да кажа. Значи всичко опира до концепции и някакви идеи. Не всяка концепция пасва на всеки. Поради една или друга причина. И дори когато нещо не ни пасва, това не означава че концепцията е лоша. Така, че първото нещо по повод концепциите, е че няма нищо лично и не може да има. Няма по-по-най-добра. Смешно е да си ги мерим и т.н.
Хубавото на концепциите е, че често някои идеи могат да се крадат. Особено ако касаят примерно "добра практика", може самият код да не ти върши никаква работа, обаче идеите и начинът по който е написан да се взаимстват. В тоя смисъл и е моето любопитство. Не че ще тръгна да ползвам PlatformIO или зефири и т.н. Практически това няма как да се случи. Но това не означава, че ако има добри идеи не бих се възползвал. Както и обратното, в смисъл с времето аз натрупал разни концепции и идеи, част от които биха могли да свършат работа на някой. Може и да не свършат... знам ли
Във всеки случай мисля, че е добре да се споделят идеи. И като се споделя да се обяснява всъщност каква е идеята. Не като в горното филмче два часа да гледам как някой с copy&paste прави разни неща.

Сега в случая ми интересно това за питона. Гледал съм хиляди проекти и съм се нагледал на всякакви бози на тема организация и компилация на проекти. Така че мога да предположа каква би била целта за по-различна билд система. Но едно е да предполагаш, друго е някой с две изречения да ти го обясни. Какви са тия, скриптове? Какви проблеми решават и как точно?

В замяна аз мога да кажа, какво ползвам аз... и тъй като моето е супер елементарно, то по-скоро какви принципи следват в организацията на проектите и тяхната компилация. А те са следните принципи:
1) Избягвам всячески дублиране на сорс код.
Защо го избягвам, ами защото в моя случай от един и същ сорс генерирам десетки и може би вече наближавам стотици изходни файлове. Не мога да си позволя да има десетки проекти, които са еднакви в едни 90% от кода и само тук-там има някакви разлики. Всяка оптимизация, всеки бъг изобщо всяка промяна би трябвало да я разнасям на 50 места, ако имах отделни копия. И моето решение не е перфектно. В смисъл ако вкарам бъг, то той потенциално заразява всички проекти в които се ползва. Няма пълно щастие, но предпочитам да имам само 1 копие, иначе се получават десетки и почват да се разминават с времето и става боза.

2) Всичко е в прост текстов формат и само в текстов формат.
Защо текстов формат... ами защото когато редактирам даден сорс, той потенциално се ползва от много проекти и често от доста различни хардуери. Постоянно се стига до някакви ситуации от сорта, ако се ползва еди-какво си, то тогава е така, в други ситуации еди как-си. Често самите ситуации се определят от самите проекти, кой какво ползва, как го ползва. Демек организацията на проекта и фактическия сорс за мен е едно и също и неразделно ползване. И както виждам сорса в текст, така и организацията искам да е в текст. Примерно мога да имам #define USE_THIS_SHIT и това нещо да се ползва както в Ц/Ц++ кода, така и в менажирането на проекта. Пускам обикновен search и виждам всички срещания на символа и знам кой как и защо се ползва.
Има и други системи, които генерират така наречените конфигурационни файлове... При това се ползва някакво GUI, в което си избираш, настройваш т.н. Може да се каже, че е по-прегледно, когато имаш джамове. В същото време пак имаш текстови файлове и пак става със search. Но винаги има някакви компромиси, не всичко е в джамове или пък си ограничен само до search, ама няма replace. Абе като си с текст за мен е 100 пъти по-чисто. То ако джамовете бяха улеснение, щяха да ги използват и в езиците за програмиране. Една част щяхме да пишем на код, друга част от алгоритъма щяхме да цъкаме с мишка.
С две думи според мен както програмирането е текстообработка, така и конфигурацията и менажирането трябва да е текстообработка.

Сега на базата на тия 2 принципа използвам различни техники като условна компилация и т.н. Разбира се това е свързано и с организацията, примерно как трябва да се разхвърлят файлове по папки и т.н. Не всичко е универсално. В смисъл ако трябва да ползвам някаква чужда библиотека, често се налага да я преподредя. Не става ей така с магическа пръчка да ползвам моята си организация.
И макар почти всичко да правя с обикновен мейк, понякога се налага да си правя и външни инструменти. Примерно тулчета дето след компилация криптират фърмуера и разни подобни. Очевидно такива неща няма как да станат в мейк, то и не искам. Но мисълта ми е, че ако беше малко по-човешки скрипт като питона щеше да е доста по-гъвкаво както по отношение на външни библиотеки, така и разни операции без да трябва да се пишат външни инструменти. Но това е положението с мейк. Не е най-удобното, но върши работа все пак.

то няма за какво - това дето пишеш се подържа + още много "мързеливи" екстри

така да се каже Make/Makefile "имитация" в PlatformIO ( SCons ) за "всички" MCU ARM M0 ... 2,3,4,5,6,7 в период
Makefile е нящо такова ... с цялата достъпна логика на Python
https://github.com/Wiz-IO/wizio-arm/blo ... SConscript ( част от мимимален пример )

демек е за "специалисти" ... трябва да се пише малко и трябва да знаят как се "вика" GCC

Тук е платформата
https://github.com/Wiz-IO/wizio-arm

за всеки проект трябва да се попълни нещо такова

един "сложен" пример - RPI Pico
бтв: и е само минимум билд за RP2040 ... ARM Cortex M0+
не съм го усложнил аз, а "разбирачите" от Рабери...


https://github.com/Wiz-IO/wizio-arm/blo ... SConscript

"It's built on top of Microsoft's Visual Studio Code"
-M$$$ базирано.
Сега с версия 2 на ардуино иде-то нямам проблеми и съм си слагал и компилирал за почти всичко, което ми трябва. Ардуинота не ползвам от 10г
ПС
За който си работи ежедневно с М$тудиото, вероятно му е добре