Да, така е никой не може да предположи кой ще ползва един модул/компонент в бъдещето. Но това по-принцип е нерешима задача. Или поне нерешима в настоящето и още по-малко автоматизируема.
Да, така е различните репозиторита имат различни собственици. Възможно е да нямаш достъп до репо-то на проекта. Но пък обикновено собственика на проекта решава дали да интегрира нова версия на твоя модул(както си избрал за пример RTC).
Т.е. тръгва се от другия край - откъм балтона, а не откъм копчето.
И когато някой реши да ползва твоя модул, той естествено ще се запознае с това какво представлява модула, с различните му версии и ако няма версия подходяща за него, може да вдигне един телефон, да ти драсне един мейл или да ти дойде на крака за да договорите промените които иска да бъдат направени. Ако това е невъзможно, примерно сте от различни светове или пък собственика на репото на модула е напуснал. То някой друг може да вземе ownership върху репото на модула и да направи необходимите промени.
Ако пък тръгнеш откъм копчето и си направил нов таг на версия, просто драсваш едно съобщение на всички за които знаеш, че го ползват. Ако не знаеш, кой го ползва - не драсваш. Интеграторите на проекти първо имат обикновено достъп до репотата на модулите, второ следят развитието на модулите и появата на нови версии. И сами може да се задействат.

Но ти се увлече май по твоите търсения за CI. Е, и без CI се върши работа. И без пълна автоматизация на процесите също.
В конкретния пример, човека каза че е за негови лични проекти. Т.е. проблема с липсата на ownership няма да съществува. CI също ще е overengineering за него.
Не е нужно да въведе при себе си пълния workflow, който познаваш ти. Идеята с референсване към друго репо е подсказка как може да си реши терзанията.
Но разбира се не е задължително. Може например да реши просто да референсва в проектите си папка от файловата си система, където "живее" модула.
Докато узрее за идеята или бъде принуден да мине на по-добър вариант.

За по-прости проекти е така - няма нужда от твърде много автоматизация. За тия цели github.com или gitlab.com предлагат достатъчно добра услуга и, според мен, напълно приемливо ниво на сигурност че няма да го ползва друг.
Ако все пак човекът иска нещата да си стоят при него, пак може лесно да ги пусне - например под докер, или на евтина машина - аз затова ползвах известно време gitea - щото върви с малко рам, докато гитлаб-а яде здраво.
Предимството пред това да пуска всичко на ръка, от командния ред, е че ще става лесно и всичко е изведено после на удобен web интерфейс - нов проект, репозиторита, разглеждане и т.н.
А за CI - зависи доколко са добри инструментите. Ние почнахме с дженкис, щото е безплатен. Ама никак не е евтин - откъм загубено време. Като ударих на няколко нерешими, т.е. неподдържани функции и се загледах настрани - пробвах няколко други и, за мой късмет, намерих тиймсити-то. Твърдя, че с него CI изобщо не сложен и срещу малка инвестиция като заучаване, връща много. Ползвам и го за лични проекти - просто ми е удобен интерфейса му.
Гитлаб-ът е добро нещо също, и също има вграден CI - не е лош, но не е на нивото на CI. Бонусът е че всичко е в едно и не се налага да твориш hook-ове между етапите. Но има още сол да изядат, преди да стигнат jetbrains-а. Затова ми се налага да крепя и двете и да слагам hook-ове от gitlab към TC. В гитлаб-а има настройка на проект, в която да зададеш адрес и връзка към TC и така се закачат hook-овете - не е като да слагат в гит-а директно, но все си иска на всеки проект да минеш и да попълниш 4 полета. Само че се сетих че тая интеграция са я писали авторите на гитлаб-а - запитах се дали от TC не са написали тяхна - за интегриране на гитлаб в ТС. И се оказа че има, и, както и очаквах, е много по-добре измислена и еднократна - т.е. в ТС доста по-смислено са хванали и закачили web service APIто на гитлаб.

Ако трябва да дефинирам идеалния вариант, то това би било цялото нещо да е направено с тулове на jetbrains - но все още нямат репозитори сървър. Поне не и release-нат - имат от няколко месеца тестово jetbrains SPACE, което е точно това, и много повече - целия процес в един продукт. Обаче още е само тестов, само онлайн (хостван при тях) и няма всички екстри. Предполагам до края на годината ще е killer продукт, и ако може да се мигрира лесно няма да има конкуренция.

То е просто

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

Общо взето идеята е в проекта ти да има код, който е специфичен само за конкретния проект. Всичко останало в общия кюп. В зависимост какво условно компилиране си харесаш по един или друг начин от общия кюп се компилира една част, която ти трябва за конретния проект.
Когато редактираш код от кюпа, няма нужда да разнасяш промени, а само да прекомпилораш всички проекти, които ти трябват.

Те общите файлове са в един кюп, но проектите които го ползват и те ли са в "общия кюп". Не вярвам. Така, че пак стигаме до това проектите да референсват общи файлове. Това че всичко общо си обединил "на едно място", еми... така смяташ за по-удобно щото работиш или сам или в малка група в която вероятно ти определяш как ще се случват тези неща.
Това е пак моето скромно мнение и го казвам без критика. Казвам го за да пресека евентуални спорове и защитни реакции.
Факт е че понеже git няма концепция за папки и структури от папки, при git всички сорсове от едно репозитори също "отиват" в "общ кюп". Ползването на референции към други репозиторита е препратка към други "общи кюпове".

Това е така.
Всъщност не размера има значение, а доколко може да се приложи сходна организация на различните проекти. В тоя смисъл е важен факта, че ползваме един и същ компилатор (gcc), един и същ ОС, сходен мейк процес и т.н.
Това са нещата, които позволяват от едно общо дърво с директории и сорсове да се компилират стотици проекти. Всичко това без излишни чудесии. За отделните проекти има само прости конфигурационни файлчета, които изброяват какво им е нужно и толкоз. Съвсем елементарно.

Ако трябва да се поддържат различни компилатори и изобщо различни организации, то тогава става малко по-сложно. Даже не е малко, защото изисква добавяне на отделно ниво за портване. Такова ниво се прави трудно и много малко фирми го правят изобщо, а още по-малко го правят качествено. Основно се ползва като силно специализирани библиотеки, примерно като lwIP. Досега не съм срещал подобен подход за не-специализиран код. А съм виждал доста фирми и почти всички ползват най-разнообразен код. Нито една обаче не съм видял да събира на едно място "тюрлю гювеч" и да го поддържа мултиплатформен и универсален. Ако ми покажете нещо такова, ще ми е интересно

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

Да, Миро един от проблемите в софтуера днес е сложността другия е хетерогенността.
Ако сорсовете ти са в един колектив, който работи в един домейн, всички да гребат там с лъжицата в гювеча.
Но аз пък последните години работя във фирми при които сглобяването на проекта преди компилация се интегрира от парчета от различни домейни. Разбирай има цял отдел(домейн) 30-50 души които работят в Matlab среда - дизайн, развой, тест, валидация, тунинговане. От тях идва генериран от модели С сорс. Други бичат ANSI С и на интегратора му дават една гора от конфигурационни файлове, които също участват в генериране на код и данни преди билд-а. Трети си копат AUTOSAR компоненти.
Така че "турлю гювеча" преди да попадне в общия кюп има доста работа. И всеки колектив има нужда от свои репозиторита които да бъдат изолирани от "общия кюп".
И всичко това при един компилатор, една хардуерна платформа. Но хетерогенноста идва от транжирането на слона на части. Които после трябва да се сглобят обратно в един Слон-Франкенщайн.
Този тертип на работа може да се скалира и надолу за фирми, които нямат тези терзания. Но разбира се ако искат, ако са узрели за това или ако ги принудят.
имхо. Ще ми бъде интересно да чуя какво правят други колеги. Аз нямам самочувствието да съм видял всичко, което се прави по широкия Свят.

Както казах стигне ли се до това единия отдел да не знае какво прави другия, задачата става нерешима. Да, ти ще успееш някак си да ги свържеш. Но всичко е един постоянен процес. Не се транжира един слон, много са. И дори да си разпределил един да транжира задни бутове, друг предните това не е еднократно нещо. Не може отдела със задните бутове да продължи да работи само със задни бутове и останалите части от слона да седят и да чакат, докато другите отдели транжират прасета примерно. Месото се разваля.
Със софтуера това е много честа ситуация. Примерно един отдел пише някаква част (библиотечка), която се ползва от други. По един или друг начин сглобявате проекта и го пускате на полето. Но покрай друг проект се налага библиотечката да се пипне. Естествено хората дето са я писали могат и го правят, само че не винаги е практично старите проекти да се променят. Не можеш да си позволиш наново тестване, наново сертифициране и узаконяване и т.н.. И така, ако няма добра организация почват да се появяват 2-3-4-5 версии на една и съща библиотечка, което създава нови проблеми, а те старите са ти достатъчно.
Пак ще повторя, за такива сложни организации няма читаво решение. Или поне аз не съм видял такова.

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

Замислих че дали правилно съм разбрал, какво имаш предвид под "общ кюп" и какво под "турлю гювеч". И това което пишеш би имало смисъл ако модулите в общия кюп имат връзки помежду си вътре в кюпа и не са просто механична смес от блокчета ширпотреба. Ако е така това не са отделно обособени, ортогонални един спрямо друг модули. Ако са добре обособени, тогава е лесно да пуснеш по тях да работят клетъчно отглеждани инженери. Да си имат отделни репозиторита и т.н. А после някоя свободна кокошка(cross domain) да ги тропосва.
Това че вързваш двата края с условна компилация, ми говори, че дори вътре в самите отделни файлове има смесени бутове, рога и копита. Т.е.дори на ниво файл няма добра обособеност. Тогава и вершън контрол системите стават неефективни за подържане на такива сорсове.
О, Анатема

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

Целта е да не се налага дублиране на един и същ код - примерно стара/нова версия. Или версия за хардуер 1, версия за хардуер 2, версия за проект А, версия за проект Б и т.н. Втората цел е да е на едно място, няма проблем да имаш код за едно ядро и код за съвсем различно ядро. Ако примерно кодът е за едно и също нещо - примерно оптимизирано смятане на CRC на асемблер. Автоматично ще се компилира версията, която ти трябва, защото условието дали да се компилира е какво ядро ползваш.
То вече е въпрос на организация, но ние специално сме си харесали такава имплементация на условното компилиране, така че всякакви настройки и глупости да са изведени от основното дърво със сорсове. Това позволява и безпроблемната работа с вершъм контрол. Общата част си е обща и еднаква за всички. Няма конфликти...

Миро, това което казваш, се нарича "конфигуриране" на билда на някакъв компонент (библиотека) - нещо, което искаш да настройш по време на билда (а не рънтайм), не искаш да "хардкодваш" в сорса, и заради това ти трябват "варианти" на библиотеката, т.е. на артифакта от билда и - "libmiro.a". При определено състояние на сорса, т.е. ако нещо е качено и не качваме в момента други версии, то в простия случай (без конфигуриране) ще се избилдва една libmiro.a и тя няма да сменя докато някой не смени нещо в сорса.
При твоя вариант, а всъщност това е общовалидния, има други фактори, които ще накарат да излезе друго съдържание в libmiro.a (без промяна на кода). Такива са например компилатор, конфигурационни данни - предефинирани символи, дето правят условното ти - "#define ENABLE_DMA XXX".
Обменът на информация е в две посоки - от една страна интегриращия проект (екзето) подава обкръжението, т.е. тия настройки на тулчейн, символи, инклуд пътища и каквото там има да доуточнява. В другата посока, след като се случи билда, тръгва съдържанието на файла 'libmiro.a' и той се линква в следващите стъпки/етапи.
Това се вика build chain, като идеята е сорсовете на тая библиотека да си останат само там, където е билда на libmiro проекта и да не се налага да пътуват по други машини (с *.a трябва да върви и хедър, разбира се, поне на ц/ц++).
Ако го погледнем от друга посока, имайки сорса на libmiro не можем да извадим коректна библиотека - не и преди някой да каже "да, тоя сорс, ама с еди кой си компилатор, е еди коя си версия на някоя зависима библиотека, с разрешено/забранено ДМА" и т.н. Оттук има една логика, че билд чейновете възникват когато възникне екзе, или него вариант. Сорса на компонентите си е там, но докато някой клиент не поръча "тоя електромер с стм32" ние не можем да изградим билд процеса.
Аз гоня това да се случва максимално автоматизирано и репродуцируемо (повтаряемо, независимо дали билдваме в понеделник или в петък). Затова нищо ръчно не може да остане в процеса (тъй дe, CI / devops). За да може да става автоматично трябва да се изолират тия фактори, които влияят върху компонентите и екзето - конфигурация, компилатор, ... Когато те са изолирани и нагласени, т.е. описани във файл, спокойно мога да пусна билд на процеса, задавайки тия неща като параметри.
Тия обкръжения много елегантно се описват в контейнери - има текстов формат (dockerfile) и процес на "билдване" на тоя текстов файл до контейнер. Има подобно и за виртуална машина (vagrant), но те са излишно тежки за нуждите на билда. Така този докерфайл, наречен примерно stm32_build_env стои пак на git/svn и е нагласен проект в CI система да го "билдне" ако някой качи нов код в това репо. Следващите стъпки ползват тоя контейнер, и така работят в известен, вече подготвен, проследим и преизползваем environment.
Това се поддържа много елегантно от добрите CI инструменти (минута за реклама - TeamCity) и е удоволствие да го виждаш как цъка без да пипаш.

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

gicho, аз избягвам да давам точна дефиниция на това що е то условна компилация. Варира от фирма на фирма и като възможности и като функции и като инструменти. Мога да кажа какво на мен ми харесва, както и ти можеш да кажеш какво на теб и явно ще се различаваме. Но идеята не е да сравняваме кой какви пишки харесва, а да помогнем на човека...
Вече ако той каже какво по-точно му трябва тогава да. Но в момента аз мога да кажа само, че проблемът му е в липсата на това ниво от менажирането, което обикновено се прави чрез условна компилация. Човекът пита как да си заформи някакъв кюп с библиотечен код, който да ползва в различни проекти без това да създава проблеми с репозиторита и т.н. И моят отговор е - условна компилация...

Постигнах успех. Благодаря на колегата Zdrav за жокерите.

Добавих че това го правят чрез "конфигуриране", защото е широко прието да се вика така - и в cmake, и в autotools, и на много други места. И който иска да прочете повече лесно знае какво да търси.
Съвсем простата дефиниция, която идва от името дето му даваш, е че компилирането се влияе от някакво условие. За пълнота аз твърдя че трябва да се гони изолиране и дефиниране на всички условия, които влияят върху компилирането. Това позволява да се открият дупки, да се реализират нови начини за "условност" в това компилиране и т.н. Това помага за по-добро разбиране на проблема, а не просто следване на определен инструментариум и неговата идея (или липса на такава).
Не знам колегата-питащ в какъв контекст пита и докъде ще стигне - повечето от нас са минавали по тоя път и са стигнали донякъде. Може да споделяме на час по лъжичка, но пък аз си мисля че е хубаво да има малко по-далечен поглед, или пък да ползваме въпросът му за дискусия (както и се случва).

Това е спорно - на гит можеш да сложиш и папка, и файл, и цяло дърво. По-скоро проблемите ни в тая насока са, че ц/ц++ все още нямат концепция за модули. В другите езици си има правила за структуриране, които после рънтаймите ги изискват и целия инструментариум (python, java, rust, ....). Те си имат концепция и затова няма проблем - имам предвид че не е работа на гит-а да налагат структура за всички.
Интересно е дали тая година ще успеят да го вкарат (модулите) в c++20, в предишните две версии не успя да мине - и за сега се съмнявам - много засегнати ще има по пътя (компилатори, библиотеки, среди, инструменти) и е съмнително.
Другото ниво, на което това може да се случва, са package manager-ите, които напоследък успяват да се интегрират и с гит добре и да приравнят репозитори и пакет/модул, всъщност репо-то го ползват по специфичен начин (организация, метаданни) и така става симбиозата.

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

Относно изолирането... когато е възможно се излолира. Даже това е една от целите - да не разводняваш сорса с безброй #ifdef/else... и вместо препроцесора да се ползва мейк за логиката. Разбира не всичко може да се изнесе, пак си остава някой друг #if.
От друга страна, това че част от логиката се вади от сорсовете, това не означава че се крие някъде. Напротив, тя си остава видима. И не, абсолютно не ме вълнува кой щял да търси някакви нови условности. Да търси каквото си иска. Аз имам на главата си над 100 проекта, базирани върху общи сорсове. На мен ми трябва да виждам лесно кое къде и защо се ползва, защото аз такива подробности не помня и не искам да помня.