Мнението ми за IAR е формирано след като съм опознал кажи-речи ВСИЧКИТЕ му плюсове и минуси. Знам какво и как може да се прави с него. Не съм казвал че ти или вие сте прости, казвам че НЕ познаваш GNU и преценката ти е следствие от това непознаване. Когато (ако) си направиш труда да разучиш всичко, да разбереш защо е конзола, защо е безплатно и т.н. тогава ще имаш далеч по-трезва преценка. Защото в GNU има много неща дето изглеждат "зле" но това "зле" е без алтернатива. Може да не ти харесва, ОК и на мен има неща които не ми харесват, ама НЯМА друго. Не се заблуждавай че IAR, CSS и тем подобни са алтернатива. ТЕ НЕ МОГАТ да свършат същата работа, или НЕ и по-добър начин.



Говориш на изуст! GCC винаги е бил един от компилаторите с най-актуална поддръжка на последните Ц/Ц++ стандарти, включая последния C++0x11 и в момента все още неприетия 0х14. Има и други компилатори, аз пак казвам има и ДОБРИ платени продукти, но IAR НЕ Е сред тях!!!
Освен това GCC е компилатора с НАЙ–МАЛКО нестандартни допълнения. Няма прагми, НЯМА нестандартни ключови думи, няма такива изгъзици като в IAR.
Oсвен това GCC НЯМА или почти няма target specific неща. Както пишеш за х86, така и за АРМ, така и за MIPS и още десетки платформи. Понякога това коства известни усилия, особено ако таргета има шибани адресни пространства, особени инструкции и т.н. Но политаката на GNU е СТАНДАРТЪТ над всичко, включая и удобството. Ако някога си ползвал IAR за повече от една платформа би трябвало да знаеш, че са си съвсем различни версии, демек различни продукти, несъвместими една с друга, не може с едната да отвориш проект на другата и т.н.
А що се отнася до това че на програмиста не трябва да му пука кой точно е компилатора това е вярно за високо ниво програмисти или за hello world. За по-сериозни ембедед неща няма как да не ти пука, защото примерно в един ОС от сорта на Линукс се компилира и кърнела и инструменти от сорта gdb server. В единия случай трябва да могат да се зарежда изпълними файлове, в другия случай да се дебъгват но форматът на тия файлове зависи от определени стандарти или от това как са компилирани и линкнати. Демек това което прави GCC трябва да се прави и от рън тайм код.
Пак казвам, няма лошо ако твоята работа е приложен програмист от високо ниво. И от такива като теб има нужда. Обаче не давай акъл на системните инженери какви инструменти да ползват и как да ги ползват, поне не и докато ти самият не навлезеш в тая област.




Принципно така трябва да бъде. Кодът от високо ниво трябва да преносим. Преносимостта обаче си има цена, различно е дали ще пренасяш от платформа на платформа без да сменяш компилатора (както позволява GCC) или ще пренасяш и през различни компилатори както е при IAR.



Какво закачане, какви 5 лева? Аз ти обяснявам, че един релийз или билд може да е много сложен процес, според изискванията на фирмата и на това което правиш. В единия случай имаш свободата ти да си организираш стъпките в какъвто искаш порядък и то не фиксиран порядък, ами алгоритъм в който проверяваш ако еди какво си е еди как си - правиш това, ако не правиш еди какво си.... В другия случай имаш набит набор от стъпки и тук таме може да настроиш нещо, но като цяло нямаш възможност да зададеш СОБСТВЕН АЛГОРИТЪМ. Правиш ли разлика между алгоритъм и опция??



Какви хукове бе човек, ти разбираш ли че аз мога да сложа SVN операции в СОБСТВЕН АЛГОРИТЪМ и да ги смеся с други операции с други инструменти. А не да чакам някой някъде да кликне, че да се закача и там да мога само един тип неща да правя.



Айде да си говорим за бъдещето като ми покажеш набор от инструменти, чието използване се програмира визуално...


Нашата организация няма нужда да я познаваш, казах ти - не познаваш GNU и от там ти идва проблема. Не можеш да разбереш, че мога да вкарам каквито си искам проверки, каквито си искам файлове от където си искам и да не става инфекция
Мога, защото имам данните кое къде и за какво се ползва имам и възможност да напиша произволна ЛОГИКА.
В конкретния случай се ползват неща обикновено от 2-3 сървъра и когато се направи make release се гарантира, че няма никъде разминаване между локално и някакъв сървър, има автоматична номерация на релийзванията, ако е имало промени на някой от сървърите се тагват и т.н.
В крайна сметка като дойде едно устройство по версията му може да се възстановят и сорсове и всичко, без значение кой колега е правил релийза на тая версия и тоя проект. Не че няма вариант за издънки, но организацията е така направена, че издънките да не стават по случайност. А вече ако някой умишлено иска да заобиколи правилата то от това спасение няма...

Виж сега, погледни го малко по-глобално. Ти можеш да си пишеш алгоритми за каквото ти хрумне, това не значи че са по-смислени.

Hook-овете на SVN-а са event-и в процеса на работа с SVN-а, т.е. това са точките в които е правилно (според разработчиците на SVN теорията) ти да се закачаш. Ако правиш нещо друго значи ти не си разбрал или не искаш да се съобразяваш с идеологията на svn инструмента. Т.е. ако искаш да се закачаш другаде имаш големия риск на следващата версия на svn да умреш прав. Ако искаш можеш да си отвориш .svn файлове и да магариш вътре, но тогава няма да ревеш че на новата версия на SVN-а всичко е в top-level файл и скрипта ти не работи.

Същото е и с билд процеса, и там имаш дефинирани точки - преди билд, преди линк, след билд, etc. Ако нещата ти са разделени коректно на компоненти (обекти, под-проекти) - което ти дава 'event'-и в техния процес, на ниво всеки компонент, нямаш нужда от усложняване на процеса, в смисъл на други евенти.

Говориш на вятъра - преди ми казваш че ти трябва скрипт да провериш дали всичко е commit-нато че да си сигурен, сега ми говориш за сървър и версия. Едното е правилното, другото не е. Показах ти къде се дъни подобно локална проверка, което просто значи че не е това начина и готиния ти скрипт е просто ... готин, но не върши предвидената за него работа на 100%. Тоя скрипт нали не го пускаш от cron на всяка минута да чеква ? , нали и той е закачен към някаква последователност (скрипт) на commit или билд или каквото и да е? Къде тогава е разликата, нали програмиста пак трябва да "пусне" нещото, било то с команда от конзола или клик? Какво става ако той не го пусне през твоя уникален скрипт, ами чукне направо svn ... команда? Почти работи, нали?
Като ползваш hook-а си сигурен че няма как да мине svn команда (от конзола, от еклипс, от ...) без да се повика твоя скрипт. И независимо дали има или няма скриптове, програмиста просто трябва да направи svn commit.
Сигурно си много навътре с gcc, но той е една стъпка в целия процес. И ако искаш той да е добре автоматизиран трябва да търсиш начини да няма "вратички" да се направи глупост. Да разчиташ че няма да се случи щото програмистите не би трябвало да правят нещо, рано или късно ще те убоде. Да, можеш да обвиниш после "недоклатения" програмист, но точно твоя работа е (като човек занимаващ се "tooling"-а в този проект) да гарантираш че това няма да се случи. Или просто да приемеш риска като "приемлив", ма тогава не ти трябват скриптове за проверка.


Това са празни приказки, ако имаш нещо конкретно по темата, кажи. CCS-а си работи с makefile проекти като слънце, toolchain-овете му се ползват без проблем от команден ред, досега не ми е попадал feature на gcc който да го няма в техния toolchain (някой неща се появиха в по-късните версии, може и да е поради "крадене" от gnu, не знам, важното е че ги има).
Пак ти казвам, не съди нещо дето не си го ползвал - CCS-а ползва gcc за ARM, и имаш всичко на GCC-то достъпно, имаш makefile базирани проекти като искаш, никой не те ограничава. Независимо как го ползваш имаш удоволствието да работиш с добре интегриран дебъг, имаш дори осцилоскоп за следене на стойности на променливи на trace point. Къде да го сравнявам с конзолно gdb, колко клавиша трябва да натисна за да рефрешна една променлива там?
И, ако не си поглеждал, все още има архитектури, който GCC въобще не поддържа. Някой от тях са на тексас, и те имат техни компилатори за тях, и те работят в CCS.Там какво правим? А, да - според gnu идеологията се хващаш и правиш ти поддръжката за тая архитектура и я споделяш с всички. Много добра идея, нямам нищо против. Но не се случва точно когато за дадената архитектура вече има достъпен инструмент, макар и не gnu.

Не знам защо продължаваш да твърдиш че мразя gcc - не е така, харесвам го, ползвам го. Но и той е инструмент за който не искам да се женя. Ти не искаш среда защото ти налага нейните си ограничения, аз не искам да се ограничавам само до gcc по същата причина. Той е една стъпка от workflow-а и тая стъпка трябва да мога да я сменям когато се наложи.

Имам проекти които ползват различни компилатори за различни таргети, винаги единия от тях е gcc (mingw за PC), другите са разнообразни. Синтаксиса на gcc не върви на другите компилатори, и съответно имам още един слой на абстракция на дефинициите за attribute например, като допълнение на описанието на съответната платформа.

Както ти самият вече каза, проект за cortex-m3 си е проект за всеки cortex-m3 и това не го броя за различна платформа - същия компилатор и същите сеттинги са това! Линкване, стартъп, хардуерна абстракция остават само различни.

Не обичам да споря ей така за спор(т)а, ако имаш конкретен проблем, който смяташ че е добре решен с допълнителен скрипт (различен от pre-build, post-build, svn hook, ...) дай да го видим, ще е полезно. За момента загатнатите от теб стъпки и действия ми се е налагало в някаква степен да ги решавам и аз, и съм приложил друг подход, или имам друго виждане. Ако ги обсъдим може и да има полза за нас, и евентуално за някой друг, ако все още някой друг чете темата де

Ползваш изрази от сорта на:




Вярно, IAR има такива, но и GCC-то си има свои, предполагам говориш за gcc extensions. Много, малко - какво значение има, има ли ги в кода без да са "обвити" в смислен препроцесор правят кода НЕ портируем. А ако някоя дето ти трябва липсва, кода става НЕ работещ.


Кой е казал друго нещо? Само че да ползвам 0х14 и да се надявам на портируемост? Да, за gcc поддържани таргет ще стане, за другите не. Това не минава като вариант при мен. Това е лимитация.

Какво значи "не се отваря от друга версия"? Аз и не го очаквам, имам софтуерни компоненти (чист сорс) които споделям между проектите. Проекта за 8051 ползва .c и .h файлове на дадени компоненти, има си свой таргет проект. Да, би могло workbench-a да е общ и в един проект да имам няколко таргета (различни архитектури). Но пак няма да става за Keil примерно. И колкото и да звучи ценно, не е кой знае какво предимство. Когато работя върху нещо не го пускам едновременно на 3 таргета, разработвам го и тествам (симулирам) на един (обикновено е на PC през mingw) и после вкарвам в таргетите един по един, естествено пак с тестове.

Ако погледнеш назад, говорих за компилатора на IAR-а като добър, и споменах че GUI-то им ми е по-дървено от това не Еклипса примерно. Не че не върши поне същата работа по-добре (по-бързо, по-удобно).

Колкото до графичните програмирания, погледни кой да е UML инструмент, има и безплатни, има и open source. Вси'те са графични. За конкретен ембеддед таргет днес и сега? - погледни на адаша ти нещата - state-machine.com
И ако за теб е далечно бъдеще, за много хора е начин на работа. Нали не мислиш че примерно за automotive хората си чешат пръстите само за парлама? Пишат си MISRA стандарти, правят инструменти и си ги ползват.

Ти си този, който не може да види по-далеко от носа си. Аз прекрасно знам как се работи с комерсиалните среди и МОГА да работя. Но се опитвам да ти обясня че има и друг начин на работа. И той не е възникнал заради мен или защото други са били некадърници или така им е хрумнало. Колкото и да ти е странно понякога хората работят в екип, без значение дали имат някаква физическа, бизнес или друга връзка помежду си.
Типичен пример - Линукс. Състои се от ХИЛЯДИ модули, драйвери и библиотеки, писани от НАЙ–РАЗЛИЧНИ екипи или хора. Няма точно определена формула кое кога и как да се компилира. ИМА БЕЗБРОЙ варианти. НЯМА точки "преди билд" и след билд. Преди билд на какво??? Ти разбираш ли, че се билдват ХИЛЯДИ неща и има много голям обем логика кое да се билдне и как да се билдне. Описването на тази логика е ВИД ПРОГРАМИРАНЕ, целта на тоя процес е да сведе безбройните варианти до някакъв краен брой работещи и прости опции. За да може да се получи нещо като порт/дистрибуция в която ти да кажеш "искам мрежа, искам gui, искам това, искам онова..." и да се справиш и сам.
Важното в случая е, че НЯМА нито един човек/фирма/екип на планетата, който да знае всички линукс дистрибуции и какво съдържат те. Съответно НЕ МОЖЕ логиката по компилиране да бъде скрита или фиксирана в някаква среда. НЕВЪЗМОЖНО Е!
Линукс е твърде краен пример, в моята практика един проект не съдържа хиляди или милиони модули, съдържа няколко или най-много десетки библиотеки, пръснати само на 2-3 сървъра. Но разликата в количеството не променя проблема. Без значение дали са 2 или 200 библиотеките, те са си различни и независими и компилирането на краен продукт от тях е ПРОЦЕС ИЗИСКВАЩ ЛОГИКА.
Така че дори и за не толкова грандиозни проекти има от нужда от ПРОГРАМИРУЕМИ инструменти. Среди от типа на IAR категорично не са такива! Не можеш да компилираш с тях Линукс и то не толквоа заради сорсовете на линукса, не защото компилатора на IAR е по-лош или по-добър, а защото не е програмируем.



тия идеи да бърникаш файлове директно си ги ползвай ти, както и хуковете



без коментар....



Не знам какво не ти стана ясно... Има скрипт, който може да извикаш с "make release" или като кликнеш на чукчето в еклипса. Натискаш и проектът се релийзва. Няма как да се обърка - или натискаш или не натискаш, поне еклипса не позволява "полу-натиснат" бутон
След като се "натисне" се изпълнява скрипт, в който е ЦЕЛИЯТ АЛГОРИТЪМ за правене на релийз на конкретния проект. Скриптът се грижи да провери дали всичко е ОК, включително проверява дали няма разлика между локалното копие и SVN/CVS сървърите. Грижи се за номерации, грижи се да тагне ако е нужно нещо на някой сървър и т.н. Както казах крайният резултат е да ти се генрира фирмъер за дистрибуция или каквото там се генерира от проекта, да гарантира че няма по погрешка да останат некомитнати неща и после някой да се чуди туй устройство с какъв софтуер точно бачка.

Самият релийз скрипт не е толкова важен, споменах го просто като пример как аз се възползвам от възможността да ПРОГРАМИРАМ използването на РАЗЛИЧНИ инструменти. Но явно не успявам да ти обясня какво е то ПРОГРАМИРАНЕ, защото ти май под програмиране разбираш само твоя си код и продължаваш да ми предлагаш разни "заместители", хукове, UML–и и т.н.



Твърдя че НЕ ГО ПОЗНАВАШ. Вече 100 поста ти обяснявам че gcc и останалите гнусарщини имат функционалност, която няма аналог. Ти ползваш gcc само като стандартен компилатор и го оценяваш само в тая му част.


Компилация на линукс или кой да е по-сложен проект - съвсем конкретен проблем




Пак повтарям, особеност на GCC е че те изнасилва да пишеш унифицирано, докато комерсиалните среди предпочитат да те улеснят за конкрентия таргет. Така че намеците ти как за gcc се пишело нестандартен код или как gcc не покрива Ц/Ц++ стандартите са меко казано смешни.
И изобщо не разбирам как може да сравняваш GCC и IAR на тема "портируемост", това е абсурдно! Основната причина да смятам IAR за НЕДОКЛАТЕН е липсата на каквато и да е било идея за портируемост.
Писането на портируем код далеч не се ограничава до самия сорс код. Някои пишем операционни системи, стекове и библиотеки дето се адаптирате в зависимост от това какво друго имаш в проекта. Това значи, че освен run time кодиране има и код за компилира, линкера и т.н., за да може съответния модул да ти пасне на нуждите. Ако ти споделяш само чист код както казваш, ние споделяме решения.




Не може да "отвориш" значи че не може да работиш с различни проекти, различни таргети, различни компилатори и т.н. ЕДНОВРЕМЕННО. Не изхождай от собствения си опит "на мен не ми се налага", "аз не го пускам на 3 таргета". Има хора на които им се налага, примерно това дето правят ronetix - дебъг емулатор, който зарежда флаш агент в десетки различни платформи. Примери колкото щеш!

Виж сега, Миро, не споря с аргументите ти за предимствата на отворената система, но тук специално не си прав. Категорично. Това, че един инструмент не ти пасва, не значи, че е "недоклатен". Постави се на мястото на IAR: имат ли нужда да има портируемост. Ми няма! Какъв ще е ефектът от нея: евентуално може да ти хрумне да преминеш на друга среда. Производителят губи. Това не е изолиран пример в индустрията. Според мен IAR е доста добре направен за това, за което съществува - да се продава и да печели аудитория.
Ако имаш предвид портване от една архитектура към друга, но пак с IAR - да, проектния файл трябва да се създава наново. Ако добавяш файлове в един проект, ще трябва да го направиш във всеки един поотделно. Или поне аз не знам как става
За умерено големи проекти - до 50-100 файла и група от 4-5 човека го намирам добър.
С гнустта почти не съм работил, не останах очарован, но от моята камбанария и с моя поглед: толкова.

нямам много поглед над IAR компилаторите но това което съм чул от колега
1. несъвместимост на проекти направени с различни версии, това е мега тъпо, проект за версия 4 не се отваря с версия 5
2. невъзможност за работа с големи проекти - гичо, бате хайде да ми изкомпилирате един линукс кърнъл с IAR компилатор

Бате, IAR го ползвахме около година покрай msp430 после още толкова време докото прохождахме с арм. Ако тогава ме беше питал и аз щях да ти кажа че мисля като теб сега. Още повече че по него време нямаше безпроблемни тулчейни за гцц, а прохождането с арм не е като разходка по червен килим, та проблемите с развойните средства не бяха най-важните. За щастие тулчейните се оправиха, после къде с жокери от приятели, къде с повече псуване подкарахме и гцц-то. И сега гледката от камбанарията ми се смени
Познавам и хора, които също са минали по тоя път но не са се пристастили като мен. Така че - да, винаги ще има различни гледни точки и ако зависи от нас ще има място за всякакви среди под слънцето. Но точно от гледна точка на производителите нещата не се определят от вкусове, а от възможността им да поддържат актуален продукт на пазара. Поддържането на сбъркан продукт, обаче е като плуване срещу течението. Рано или късно се уморяваш и течението те изхвърля от пазара.
Навремето като излезе Еклипс ви казах че това е бъдещето, но всички гледаха колко тежко вървял, как не бил удобен и т.н. Да, ама днес почти всички зарязват собствените си IDE-та и минават на Еклипс. Не ви питат дали върви бързо, нито дали ви харесва, минават и толкоз, защото не могат да си позволят лукса да плуват срещу течението.
Същото ще се случи и с компилаторите. АРМ се опитват чрез cmsis и някои идеи да държат Кейл над водата но не мисля че ще успеят. IAR не ги броя изобщо, те отдавна са под водата.. Никой по единично няма шанс. Погледни само колко кура има за АРМ само - М0, М1, M3, М4, R4, A5 , A7, А8, А9, А12, А15.... умножи ги по броя на производителите и ще получиш бегла представа за поддръжката.
Да припомня че всичко тръгна от това че някой си предложил среда дето поддържа само 1-2 кура и то само от тоя производител. Няма начин точно с такава среда да не избиеш рибата

Back to the roots:

Посочих ти CCS, CW на Freescale и IAR.

Да караме поред:
1. CCS - поддържа toolchain-ове (+ ДЕБЪГ!) на:
- ARM7, ARM9, ARM11, Cortex-Mx, Cortex-Rx(поне R4F), Cortex-Ах - това през gcc
- MSP430
- C28x, C5x, C6x ... - техен компилатор
- с по-старите версии и c24x, c3x, ....
Под поддържа разбирам теглиш инсталация, инсталираш и ... почваш да работиш. Няма libusb, няма openocd, няма yagarto, няма пътища с/без интервали (при все дълбокото ми уважение към всички тези проекти и техните автори). Няма четене на man, има описание кое ка се прави в самата среда и/или help-а и, няма избиране на конфигурационни файлови, има тип на jtag (сканиране на закачени), тип на процесора е от проекта, debug, reset CPU като искаш и всички нормални неща, присъщи на нормална среда. Избор на версия на toolchain-a от инсталираните - през GUI-то, ... няма път, няма "ама то ся кое arm-none-eabi-gcc се викна, аз съм го имал N-пъти на пътя".
Това е удобство - понякога можеш да нямаш нужда от това удобство, но наличието му е бонус.

2. CW - пак кортекси, ARM9, 11, powerpc, coldfire, ...., пак УДОБНО.

3. IAR - тука си ги знаеш, да споменем няколко дето gcc "не мое да ги клати" - 8051, STM8. Удобство - да, всичко което ти трябва го има УДОБНО и ИНТЕГРИРАНО.

Ще го кажа за N-ти път, пък дано ме чуеш - CCS МОЖЕШ ДА ГО ИНСТАЛИРАШ КАТО НАБОР ОТ ПЛЪГИНИ В КОЯ ДА Е ТВОЯ СИ ЕКЛИПС ИНСТАЛАЦИЯ, в която вече си сложил gcc, sdcc, keil, make, fake, ...

И какъв е проблема с компилирането на линукс кърнела с IAR? Освен че са много файлове, и има много конфигурационни опции (дето са извън обхвата на действие на компилатора, и са pre-built step), друго страшно няма. Да не е писан на македонско C-- че да не става?
Аз виждам причини да не се прави:
- хората са приели че ще работят с гцц и си ползват неговите разширения
- никой не е направил проектни файлове
Аз мога да попитам същото - с гцц ще компилираш ли проект от IAR?
Ако някои има мотивацията да го направи, кое ще го спре? Примерно:
- gcc extensions, дето са "най-добрите изгъзици от всички изгъзици", ама пак са извън стандарта (няма лошо, без тях не може, ама не ми ги хвалете като по-по-най от другите) - т.е. пак същото, дето ви пречи да ползвате IAR код под gcc? И къде е разликата?
- липсата на проектни файлове? - едва ли, make май ще успее да повика и друг компилатор освен gcc, как мислите? а, с други опции? ми да, на gcc-то са си толкова уникални, колкото и на iar, тъй че хвани единия - удари другия; пак не е голям проблем, технически въпрос за решаване

Ако искаш да кажеш пък, че IAR не позволява да направиш код, който е използваем паралелно и в други среди, помисли пак и си свери часовника Въпрос на качествено писане на C кода. Ако не го направиш (можеш) прибягваш да външни помощни инструменти от 3-ти вид, накратко наречени "уникални скриптове" ...

Концепцията на софтуерни модули не значи непременно autotools и мейк. От 15 години CCS си има концепцията за "под-проекти", които представляват капсулирани модули (библиотеки), с тях се правят йерархични структури от модули и се преизползва кода. Има си и генериране и ползване на мейк като искаш. Същото го има и в еклипса.

А, имате си псевдо-графичен инструмент за редактиране на конфигурации (тире menuconfig)? Ба, махайте го, само текст! Долу всички улеснения които имат наклонност да приличат на нещо повече. Универсален, да, ама ръчното ровене в config файл-а е 10-пъти по-бързо (имам предвид за гурутата с многогодишен опит, ма ние другите не ги броим).

Явно не познавате други начини за организиране на проекти освен make (и примерно autohell щуротиите, дето търпят бая критика). А алтернативи има доста.
Нека не отваряме темата за makefile, всеки сам си избира. Оферта е ако няма друг начин. Иначе ....
То е същото и за gdb конзолно дебъгване - за спорта съм го пробвал, сигурно бих повторил ... ако няма друг начин обаче. За няколко месеца може и да задобрея и да стигна ефективността на някой дето е щракал 2 часа в университета на VS. После ще съм увреден за цял живот.

Колкото за "захвърлят собствените и минават на еклипс" може да е вярно някъде, ама вземи погледни кои фирми са отделили време и хора да пишат за еклипс, пък тогава решавай. Ако мислиш че тексас примерно си мислят да лежат на това което им напишат другите, си в грешка. Пишат, разработват, качват. Приели са че лиценза на еклипса ги устройва и го подпомагат. Същото е с green hills, intel, freescale. Разгледай сорса на еклипса (особено в частта на CDT-то и ще видиш кой е писал нещата).

Не те разбирам обаче - да не би да очакваш че някоя фирма, производител на контролери, ще тръгне изрично да разработва нещо да помага на конкуренцията? Какво неестествено има в това - фирмен инструмент (теглиш/купуваш от конкретната фирма, от доста години тексасците не правят проблеми за лицензи на инструменти ако купуваш малко над любителси количества техни чипове).
Улеснява ти живота (освен когато го класифицираш като "недоклатен" и решиш да си го усложниш сам).

Доколкото си спомням, преди 6-7 години codesourcery бяха основния двигател на поддръжката на arm в gcc, като се издържаха от комерсиалните опции, и от това че реално feature-ите излизаха със закъснение в други gcc дистрибуции. Предполагам че вече не е точно така, но онова си беше значим етап от детството на гцц за арм. Това, че кодът е отворен отдавна не значи че някой го пише без пари, за чест и слава.

Колегите ми ореваха света като натисках да минем на еклипс, и сигурно си бяха прави - от ръководството допуснаха фаталната грешка да им дадат възможност да видят дебъг точно с Lauterbach за малко. Всеки си сметна колко време е загубил да подкарва "недоклатени"/"евтини"/"безплатни" инструменти и убедително сметките показваха че 2000 евра на калпак са нищо. Пуста и криза (тогава), размина им (ни) се.

Издръжката на един инженер в нормална евро държава е към/над 10000 евра месечно (толкова трябва да си предвиди фирмата ако иска да разкрие ново място и да вземе човек - цитирам по памет от проучване за Германия от преди няколко години). Т.е. 500 евра на работен ден излиза. CCS-а често е на промо на 500 долара. CodeWаrrior-a е по-скъп, но пак 2 дена в месеца ги спестява за закуска. Да, за целта ще трябва да ползваш TI/Freescale чип.
Ако вземеш STM нямаш много оферти (IAR-а беше последно 6000 без допълненията, Atollic беше към 1000 ако не бъркам?). Искаш, не искаш, ползваш каквото има в интернет. Да, и това е оправдано в момента, защото STM-ите излизат на много добра цена. Иначе трудно щяха да се харчат толкова де.

Затова има смисъл да се ползват и такива "недоклатени" среди понякога - може на мен/теб/него да ни се обърне гьона да го подкараме за да могат после останалите да работят УДОБНО, но за екипа е по-добре един да стане разноглед (да губи време в проучване и проби), отколкото всички да псуват в хор. Може да ти харесва да ползваш makefile, ама ако екипа каже примерно "искам смяна на оптимизация на ниво файл, или изключване от билда, или добавяне на файл към проекта, да стане на десен бутон в еклипса" правиш managed проект и стискаш зъби. Да не говорим какви по-екзотични желания съм чувал, получени от увреждания от инструменти, които се опитват да налагат собствена, нестандартна логика и workflow, вместо да ти позволят да ги ползваш.
Това е инструментариум, твоите скриптове са също инструменти. Има нужда от такива, и колкото са по-добри, толкова по-лесно се работи, по-малко възможности за грешки има. Може и без тях (или на по-ниско ниво да останат), това си зависи от ресурса / мениджмънта на фирмата дали ще го прецени за удачно да се инвестира. Важно е да паснат на начина на работа на екипа / клиента. Ако това са линукс кърнел хардкор девелопери, ясно че ще се включиш по подобаващия начин. Ако клиента пита - "нямаш ли проект за mplab, или за средата на тексас, нали ползваме техни чипове?" е хубаво да си подготвен. А ако си решил проблема с този инструмент, за какво ти е друго, по-неудобно решение?

Не съм социолог, но може би това е една от причините nuttx-а да не получава подобаващото му внимание - заради по-стръмната крива на заучаване и подкарване? Документацията по стартиране в много на ниво, но има нужда от още малко tooling. Не е приятно при първия си сблъсък с ОС-а да ти се налага да правиш полу-ръчно, многостъпково конвертиране на формата на конфигурацията преди да почнеш още.
Къде по-сладко е чибито - предварително настроена среда с toolchain, примерни проекти, openocd, конфигурации и едно семпло readme да не се объркаш случайно.

Както и да е, заключението ми е че за всеки влак си има пътници и нито едното, нито другото могат да покрият 100% от случаите на използване. Но това значи че има случаи в които gnu не е най-доброто решение. Минаване от едното към другото е по-ценното и там пак е хубаво да има инструментариум (примерно - cmake).

Edit: сигурно в един по-добър свят тексас, стм, freescale, nxp, silabs, етц. ще направят общ суперконтролер и ще го подаряват срещу like в сурата. А дано, ама ...

Гичо, аз съм упорит човек и уважавам това качество, но не и когато се използва само и само да НЕ научиш нещо ново за ТЕБ.
Прекрасно разбирам аргументите ти за това колко са удобни някои среди. Не те карат да мислиш и това е удобство понякога (дори и за мен). Концепцията на гну (всъщнот тя датира от unix) е друга. Налага се да МИСЛИШ, защото няма предварително зададен тертип на работа. Трябва да си измислиш собствен или да взаимстваш някой който е подходящ за теб. Това може да ти изглежда страшно неудобно ама това е ЦЕНАТА, ако искаш да можеш правиш ПОВЕЧЕ, отколкото някой предварително е измислил вместо теб.
Така че разликата не е между удобно и неудобно само ами и във ВЪЗМОЖНОСТИТЕ. Гнусните неща дават ПОВЕЧЕ възможности и това е основната причина да се използват. Забележи че не става дума за качество, примерно гцц никога не се е славил като най-бърз компилатор, или че генерира най-малко код или че е супер лесен и т.н. Верно от година на година става все по-добър и в тия неща, НО НЕ ТОВА Е най-важното за него.
Линукс е един ексремем пример за възможностите на ГНУ. Твърдението ти че може да се компилира с IAR само доказва че нямаш дори НАЙ-ЕЛЕМЕНТАРНА представа за какво ти говоря. Както и обяснението че видите ли така били свикали или нямало кой да направи проектните файлове...
Как да ти обясня, че линукс не е само сорс файлове? Че за различните модули има и най-различни скриптове които УПРАВЛЯВАТ процеса на билдване. Кажи ми как да ти обясня че в тях има АЛГОРИТМИ? Вече те питах - ПРАВИШ ЛИ РАЗЛИКА МЕЖДУ АЛГОРИТЪМ И ДАННИ?
Защото ти ако можеш да разкараш алгоритмите от билдването сигурно ще можеш да разкараш и алгоритмите от сорсовете.. Теоретично може да вземеш таблицата с оп-кодовете на конкретния процесор и даже и IAR няма да ти трябва. Един хекс редактор и си готов...

Когато и ако някога ти опре задника до проблеми изискващи повече възможности от IAR обади се, ще помагам. Сега да ти обяснявам защо разни логики се изнасят извън сорсове и т.н. няма смисъл. Свиркай си и си вярвай, че ползваш най-удобните инструменти

Смесваш нещата и говориш общи приказки. Работата със C сорс си е фиксирана, има си ЕТАПИ на билдването. Липсата на такива естествено проваля концепцията, но моята теза е че CCS/CW/IAR/Keil не те ограничават.

Аз ги разделям така:
- pre-build - (конфигуриране) - подготвяне на сорса за билдване, т.е. в общия генериране конфигурационен хедър/c/ld файл за дадения компонент (програма, библиотека) - въртиш, сучиш, накрая излиза това (независимо дали го редактираш през autoconf, питонски скрипт); общо взето алтернативата при "недоклатените" инструменти му викат билд конфигурация, но ти си свободен да го направиш както желаеш - скриптове, web service-и, изкуствен интелект...
- компилиране - да не обяснявам ... какви междинни стъпки, скриптове и тем подобни искаш да слагаш тук?
- линк-ване - и тука така - входни обекти, опции и команден файл, водят до изход ...
- пост-процесинг (пост-билд стъпки) - тука правиш каквото искаш, и няма нужда да се ограничаваш, това не е част от работата на "недоклатените", точно толкова колкото и ти не знаеш какво ще се наложи да се прави с резултата от билда ти; като искаш слагай скриптове, магически думи, ... качвай и на луната ако трябва

С две думи, всеки инструмент който е отворен за точки pre-build и post-build е достатъчно отворен за всеки сценарий, който ти се вижда решим само с твоите скриптове. Ако си мислиш че ти трябва друго, значи не си намерил правилното разделение на сорса в компоненти. Всяко по-нататъчно усложняване на процеса е за спорта и води до зависимости.

Не забравяй че говорим за подчинени (зависими) проекти, които изграждат йерархично целия проект. Т.е. първия проект има пре-билд, после пост-билд, и излиза нещо което може и да е обработено. Тогава започва и втория компоненти, пак с неговите пре/пост стъпки, после N-тия и накрая тия под-проекти (компоненти) се свързват в едно от главния (интеграционния) проект/проекти (или междинно в по-големи, логически свързани библиотеки).

Представи си го така (бегъл спомен от openembedded и bitbake) - URL на сорса, команда за билд. URL-а е ясен, командата за билд може да е make, uv4 xxx, iar.exe xxx, ..., няма значение, тя се дава (експортира) от компонента, теб не ти пука кой е, всичките са възможни и за това ниво няма значение. Но не пречи и да е друго освен gnu. Стига да има интерфейс от командния ред. И да е инсталирано (то това важи пак за всички).

Самата концепция на C за транслиране първо до обектен код, и после линкване, ти отваря пределно гъвкави механизми за работа с кода. Добави правилна организация на сорса и си готов. Резултата от компонентите (object файловете) се свързват накрая в крайния изход (програма или библиотека).

Това е, средата не ме ограничава в нищо, това че на някого му пречи не е голям критерии. ГНУ не искат да се обвързват с не-свободен код и по тази причина решават всички възникнали проблеми с подходящи (отворени) средства. Това по никакъв начин на омаловажава работата с по-удобни такива.

Като говориш за билдване на линукс, говорих за кърнела, или за дистрибуция? При IAR и Keil съм ползвал една "недоклатена" възможност - от командния ред да пускам Keil-а примерно с подадено име на проект и име на билд конфигурация. Резултатът е не по-лош от make. После искаш да пакетираш нещо? Управлението на зависимостите е отделна задача, която обаче нека обсъждаме когато почнем да ползваме динамично линкване в нашите проекти (дано упоритостта ми не свърши преди да подкарам nuttx-а). Не че не можеш да си играеш с подобни идеи в едни монолитен проект (без зареждаеми библиотеки), но е лишено от смисъл.

Прекалената свобода да кажеш "ей тука ще го модна в мейкфайла" те прави зависим от обкръжението. Затова и билд-ване на иначе елементарен проект от 10-тина файла под друг OS (примерно win) често води до брадясване, инсталиране на cygwin/msys и тем подобни. Което за теб е естествено и нормално предполагам, но не е единствения вариант.

Нормалните недоклатени среди си имат механизми за организиране на тези неща. Непознаването им не значи че трябва да ги отхвърлиш. (познавам среди които не са мислени в тази насока, но това са изключения).


Не мога да се съглася, autoconf, menuconfig и дори циркулиращите из нета make файлове са точно тертип. Кой мисли как да реогранизира билда на нещо готово, дърпате сорса и карате по "тертипа" който идва с него.
Има много начини да си генерираш хедърите за проектите (конфигурирането), но се ползва един типичен - това е 'тертип". Защо билдването на кърнела не е направено по различни 'тертипи" в различните дистрибуции примерно? Дали не е защото наложения тертип е удобен и върши работа?
Това, което гну са направили като workflow и организация заслужава само дълбоко уважение, много ум е хвърлен там. Само че не мисли че те са единствените които мислят. Има и други "vendor"-и на инструменти за разработка. Всеки си има и +, -.


да, затова е хубаво да не ги смесваш, т.е. да ги прилагаш тия алгоритми където им е мястото. Пак учтиво ще помоля, посочи ми един алгоритъм от твоите, който не е на ниво пре- или пост-билд? Ще можеш ли?

И ако можеш да се върнеш на "дребния" проблем какво ще стане в твоята система ако новия програмист, понеже е свикнал с недоклатени среди, вземе че щракне commit от костернурката или еклипса? (изхождай(ки се) от идеята че не приемаш svn hook механизма? дето е гну, пък ти го омазваш с един "недоклатен" скрипт?) Както казваш ти, не познаваш идеологията и не се опитваш да я разбереш!
Като схванеш идеята тук, ще разбереш защо са сложени тези hook-ове. И ако разбираш толкова от алгоритми, ще ти светне аналогията с процеса билдване и pre/post билд действията

Не ме учи къде трябва да се ползват алгоритми и къде не! Аз те питам ПРАВИШ ЛИ РАЗЛИКА МЕЖДУ АЛГОРИТЪМ И ДАННИ?

Ако твоите сорсове вървят с НАСТРОЙКИ как да се компилират, моите вървят с АЛГОРИТМИ за компилиране. Повечето ГНУ неща се разпространяват така. Може би никога да не ти е направило впечатление, но обикновено се разпространяват САМО в сорс + скриптове. ТОВА НЕ Е СЛУЧАЙНО!!! И няма нищо общо с това че е безплатно или че искат да те сгърчат. Просто това е ОСНОВНАТА форма и това НЕ Е НЕДОСТАТЪК, това е ПРЕДИМСТВО. Примерно ако вземеш GCC и ако утре си измислиш нов супер бърз процесор и нов компютър имаш да портнеш една малка част от бакенд-а на компилатора и евентуално някоя библиотека и след това на новия си компютър ще може да прехвърлиш компилатора и да продължиш да работиш от него. С комерсиалките като IAR няма как да направиш тоя номер, най-малкото заради лицензите. Като купуваш си купуваш за точно определен хост/ос и за точно определен таргет. И дори да си измислиш супер компютър ще останеш да си работиш на стартия... Въпросът не е само до лицензи, просто ИДЕОЛОГИЯТА на нещата са различни. Единият инструмент е направен с мисълта да бъде НЕЗАВИСИМ от платформата, независим от начина на ползване (затова не е една среда а разцепен на МНОГО и отделни тулове дето ти си решаваш кога и как да ползваш).
Дори в моя скапан ОС ползвам същата концепция. САМО сорсове и скриптове. Нямам ограничения за КАКВО ще ползваш моя ОС, дали ще го търкаляш на АРМ7 или на куртекс. Нямам ограничения дали ще ползват драйвери и кои драйвери и дали ще са за ST, Luminary или Атмел или нещо друго. Нямам идея дали ще се ползва GUI дали ще ползва мрежов стек или дали ще се ползва USB стек, дали той ще е хост/otg или прост девайс и т.н.
Не знам каквo ще е крайното приложение и НЕ ИСКАМ да се обвързвам с някакви конкретни настройки и стъпки на билдване. Но все пак моят ОС не може да се компилира с хептен произволно избран и безобразен начин. Има си зависимости. Като избереш някакъв процесор, най-вероятно ще ти трябват драйвери за него, а не за друг чип, най-вероятно ще и за съответното ядро. Затова съм извел определени комбинации и съм ги вкарал в алгоритъм от сорта - ако се ползва това, компилирай това и т.н. Но това са АЛГОРИТМИ САМО, не е казано какво точно ще се компилира, дали директно от ОС-а ми ще правиш нещо, дали ще го ползваш като библеотеки или по някакъв друг си начин. Оставил съм нещата ОТВОРЕНИ.

Както и да е... безнадеждно е! В предния си пост казах, че ако ти се наложи да правиш нещо подобно бих ти помогнал... Честно казано малко съм се надценил. Не мога да ти обясня съвсем елементарни неща, а кво остана за нещо по-сложно...

Ето на, стигнахме до нещо конкретно! Така е по добре. Може и да стане.
Това, на което му викаш драйвер, стек, ..., аз му казвам софтуерен компонент. Някой му викат библиотека, което ме устройва също.


Комбинацията от файлове са данни, не са алгоритъм, списък с имена на файлове, можеш да имаш милиони такива списъци. Обработката на списъка вече е алгоритъм, но както и да го гледам, алгоритъмът е един и същ - стандартно билдване на списъка и нищо повече. Сменянето на "комбинацията" не променя нищо в алгоритъма. Тука си се объркал.
Изборът на комбинация в зависимост от някаква входна променлива (платформа?) може и да е алгоритъм, но по-скоро като гледам си е директна 1:1 зависимост.
Виждам че имаш в зависимост от променлива да добавиш примерно някакви допълнителни компоненти (драйвери). Този условност е алгоритъм, не споря, но същото може да се постигне с описателен файл на дадената платформа или платка.
Независимо от всичко това, това пак е pre-build стъпка. Прави се преди билда на компонента. Отделно тая твоя логика "ако е Ф2 добави това и това" е лимитация - ми аз на F2 може да не ги искам тия драйвери? Това е хардкодната логика, която в определени ситуации трябва да може да се override-не (пример - не ми стига ресурс и не ги искам тия драйвери защото и без това не ги ползвам). Че подобна проверка е полезна не споря, но тя е по-нагоре според мен (на по-късен етап), и е трябва да има повече свобода да се направи.

Между другото, в момента говорим за build management и това е извън точката на компилиране и линкване. Някой среди нямат поддръжка на такива неща, други имат (макар и по друга концепция). Има системи с които да си закачиш билда през средата и в нея да си направиш останалата логика.

Както и да е, въпросът е доколко CCS/CW/IAR/Keil ти пречат да работиш на компоненти? Ако някоя (друга) среда и да няма концепция за "подпроекти" и зависими компоненти, то винаги можеш да го постигнеш с проекти за библиотеки и горни нива (проекти) които ги свързват в приложение.

От беглите ми познания по тия среди, и четирите ти позволяват да създаваш проект тип "библиотека", и отделно да им викаш билдването от командния ред. Отделно в еклипс базираните имаш зависими проекти и предаване на променливи между тях, заедно с билд конфигурации. Т.е. ако има ограничение, то не е в средите, а в ползвателите

Едит: сега погледнах TMOS-а ти, всичко вътре изглежда ОК, къде са тия сложни скриптове, за които говориш? Ако си поглеждал, еклипса при генериране на мейкфайл от managed проект спазва подобен pattern. Много хубаво (класически non-recursive make) си е организирано, евала за това, но кое те кара да мислиш че с CCS примерно не можеш да покриеш същите изисквания? Да, само за TI ще е, но средата няма да те спре да го направиш по същия логически pattern. Искаш го по-генерално за ARM?. Тогава трябва да започнеш с избор на не-фирмена среда - Atollic, IAR, Keil, CodeBench, MULTI.

Сигурно съм се объркал
Айде пак погледни и ми кажи каква е моята "комбинация от файлове"?



Списъците от файловете се генерират по време на мейкването. Има различни списъци за различни цели. Всеки се генерира според някакви условия, дали условието ще е параметър подаден на мейка, дали ще е параметър от конфигурационен файл или друга логика няма значение. Пример за друга логика е дали има промени, защото има и списък, който се изгражда на база кой файл от кои други зависи.
Аз описвам ЛОГИКАТА, защото аз знам дали и върху какви файлове ползва предпроцесор и това НЕ са само Ц/Ц++ файлове, така че няма как компилатор да знае тия неща. Аз решавам как и къде да са организирани изходните или временните файлове. Аз си избирам такава организация че хем да не работя с пътища, хем да няма конфликт когато има два файла с едно и също име. Изобщо нещата са много по-сложни отколкото ти си мислиш и НЕ - НЯМА как да стане САМО с описателни файлове. Действително аз също си правя описателни мк-файлове, защото така е по-прегледно и по-лесно...



Логика на компилацията определя само какво ще се компилира. Направил съм го по подразбиране да се компилират всички възможни драйвери за съответния чип. Само една част са опционални като GUI, USB, Ethernet защото тях няма смисъл да компилираш ако не ползваш съответния стек. Не съм сложил опции за обикновените драйвери защото нищо не ти пречи да ги компилираш. Самото компилиране ти дава възможност да ги инсталираш. Ако ги инсталираш ще ти ядат ресурси, но ако не ги инсталираш линкера ще ги разкара. Така че ако добавя опции ще спестя 1-2 секунди от компилацията най-много, с което едва ли ще улесня живота на потребителя. По-скоро ще го усложня като го накарам да се грижи за още опции...





Да позволяват проекти тип "библиотека" и вероятно е много "удобно" в твоя фиксиран свят, където знаеш кое е библиотека, кое не. В моя свят не се знае дали проекта е библиотека или не. TMOS може да го компилираш като библиотека, може да го компилираш до hex, bin или друго нещо.



Скрил съм ги да не ми ги откраднеш



Мисля че познавам еклипса, познавам и managed и autmake и т.н. Препоръчвам ползването на Еклипс, но не и шерването на еклипс проекти, защото съдържат локални пътища, имат различен формат според версията и според инсталираните плъгини. А и няма голям смисъл от шерване, защото си вкарваш репозиторито, чекоутваш и конвертираш до Ц/Ц++ проект и готово. Остават специфични настройки примерно за дебъга, ама аз ползвам PEEDI, ти може да ползваш JLINK или оцд или нещо друго...
Колкото до варианта друга среда, ако ще е пак еклипс базирана ми ползвай си я, какъв е проблема. Ако искаш карай на notepad, не мисля че ще имаш проблем. Каквото смяташ за най-добро него ползвай.
Колкото до мейкването ами аз съм си направил собствен мейк, което ми отне доста време... а както казва колегата ми "достатъчно мързеливи сме, че да не правим излишни работи".
Има много неща които не съм направил по най-добрия начин, поради липса на време или защото после ми е дошъл акъла как да станат. С времето оправям стари неща или добавям нови, но що се отнася до инструментите нямам НИКАКВИ оплаквания и НИКАКВИ намерения да ги сменям. Както казах има ПО–ДОБРИ като да кажем MULTI, но не са ми по джоба. А такива като IAR просто забрави. Ползвай си ги ти със здраве, аз не ща даже и да ги чувам па камо ли да се връщам на тях...

Като чета последната страница ми се струва че не съм показал идеята както трябва, затова ще ползвам докъде сме стигнали и се надявам да стане кристално ясна сега. (т.е. ако и сега не стане, се отказвам )

Разликата в твоя и моя подход е в посоката на описване - top to bottom или bottom to top.

Да разгледаме точката в мейкфайла, в която ти избираш на база на тип на процесора дали да вкараш още два драйвера (мисля при STMF2 ако е зададено беше?).
Значи, ти имаш мейкфайл, което обслужва както F1, така и F2. Подаваш на този мейкфайл входна променлива "тип на чипа"=F2 и той ти включва по тази причина 2-та драйвера горница. Това е твоя подход, нали така?

АЛТЕРНАТИВАТА: имаш мейкфайл в който се обслужва само F2, т.е. е входната точка за мейк на F2, не че има всичко разписано за Ф2 в себе си (примерно stm32f2.mk). Ти също би трябвало да имаш такъв файл в който си обявил променливата по която другия прави избора, нали? А типа на процесора обикновено идва от мейкфайл за платформа, нещо като stm32F2_discovery.mk? Над него пък е по-общия на проекта примерно, които добавя реалните файлове на специфичния проект (примерно uart_test.mk)?
Така, аз казвам че алтернативния вариант е stm32f2.mk просто да "include"-ва общия за F1 и F2 "stm32F1F2common.mk", и да добавя (безусловно) двата специфични драйвера. Резултатът е 1:1 същият, както и да го погледнеш. Няма повече писане, няма дублиране на описание. Добавянето на F4 не налага промяна в общия файл (ако приемем че Ф4 e F1 или Ф2 + още няколко драйвера, хипотетично). При теб трябва да слагаш "ако типа е f4 добави еди какво си".

Понеже не ме разбра за библиотеките, представи си че stm32F1F2common.mk ти изкарва библиотека (няма как да изкара друго, защото в НЕГОВИТЕ сорсове main() няма). Представи си сега че stm32f2.mk също изкарва библиотека, която е получена като ar на stm32F1F2common.a + drvF2_A.o + drvF2_B.o.

На това отгоре сложи следващия по веригата мейкфайл - този на платката - stm32f2_discovery.mk. Този мейкфайл също вади изход библиотека - по същата логика тя е stm32f2.a + stm32f2_oled.o + stm32f2_joystick.o + stm32f2_button.o. Дотук излезе една голяма библиотека на име stm32f2_discovery.a.

Нагоре (назад по веригата и хронологията на викането на мейкфайловете) се връщаме там, откъдето тръгнахме - до конкретен проект, които е за платката, казахме го uart_test_f2disc.mk. Този проект има един main.c (примерно) и се линква с горната stm32f2_discovery.a, т.е. стигаме до изпълнимия uart_test_f2disc.elf, който е получен от main.o + stm32f2_discovery.a (по съответния линкер скрипт).

Дано съм го описал добре, идеята е че потребителя пуска конкретния проект и нещата се разплитат автоматично:
> make uart_test_f2disc [enter]
(stm32f2_discovery.mk)
(stm32f2.mk)
(stm32F1F2common.mk)
Какви са предимствата на алтернатива ми? Първо, слизайки надолу в мейковете имаш вече представа какво от компонентите ще ти трябва. Другото е че лесно се проследява какво се случва, без да се налага да се разплита логиката на условните операции в мейкфайла. Третото, и ЕДИНСТВЕНО ВАЖНО ЗА МОЯТА ТЕЗА е че този pattern лесно се изпълнява като множество (йерархия) от библиотечни проекти ВЪВ ВСЯКА СРЕДА.
Недостатъци бол - следенето за модификации при мейкфайл проект по този pattern май е по-проблемно (не съм специалист, затова не мога да кажа).
Като C програмист това ми е близко до акъла и до логиката на организиране на сорс и затова ми е близко до сърцето и за организация на проекти. Отделно явно толкова години все е работило без да го спират IDE-тата с който съм се блъскал (а някой от тях наистина са били недоклатени).

Рек, що не цепнеш темата и да преместиш дискусиите за програмните среди в друга тема?

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