Здравствуйте, Евгений Музыченко, Вы писали:

CC>>В винде и в макоси давно всё нормально сделано, есть platform SDK, там всё что тебе надо. Можно поставить их несколько и говорить с какой ты хочешь компилять.

ЕМ>В винде в последнее время тоже доминирует тенденция к неграмотности. Даже многие разработчики драйверов весьма туманно представляют себе, что происходит про сборке, и мыслят категориями "ставим такую-то студию, к ней ставим такой-то WDK, создаем проект, нажимаем кнопку, и крутая магия создает нам бинарники".

Как тебе удаётся в одной теме говорить правильные вещи, и в той же теме самому садиться в ту же лужу?

Ты мыслишь категориями "ставим кросс-систему, и крутая магия создаёт нам бинарник, а если не создаёт, то она кривая".

Кросс-системы для малины прямые. На Дебиане на любой платформе уже много лет из коробки, безо всякого напильника, можно создавать бинарник "Hello, world" под все четыре малиновых процессора.

Но "Hello, world" для малины не нужно кросс-компилировать. Он и на самой малине скомпилируется за секунду.

Кросс-компилировать для малины может понадобится большие штуки, которые на малине будут собираться часами. Это значит мегабайты исходных кодов самого приложения и десятки посторонних библиотек, которых гарантированно не будет в самой прямой кросс-системе. И все эти десятки чужих библиотек, подобранных автором целевого продукта по функционалу, а не по качеству подготовки к кросс-компиляции, нужно допилить и кросс-компилировать. В этом трах.

Да, этой проблемы нет при разработке под микрокалькуляторыконтроллеры.

ЕМ>Но даже при таком подходе сохраняется принцип разделимости. Я SDK/WDK уже много лет не ставлю их собственными установщиками, а тупо распаковываю из MSI нужные подкаталоги в отдельные целевые каталоги, и в каждом проекте указываю соответствующие пути. Немного более громоздко, чем стандартный способ, зато нигде нет неявных зависимостей — все на виду.

Теперь представь, что таких SDK надо поставить тридцать. Потому что сейчас модно не писать руками то, что можно подтянуть из чужой библиотеки, и плевать на качество оформления библиотеки, у меня же собралось.

ЕМ>Вообще, импортировать заголовки/библиотеки тупо по [коротким и невнятным] именам, в расчете на то, что все пути будут свалены в INCLUDE/LIB, допустимо или в сугубо локальных проектах, не предназначенных к распространению, или когда импортируемые файлы имеют давно устоявшиеся, незыблемые имена (stdio.h, libc и т.п.). Но до сих пор ведь встречаются публичные проекты с чем-то вроде #include <util.h>, где util.h — заголовок в одной из нескольких внешних библиотек.

Видишь, одну из самых простых проблем при сборке публичных проектов ты уже знаешь. Главное не копай глубже, там ещё хуже.