LINUX.ORG.RU

Полностью автоматическая сборка

 , , , ,


0

1

Есть ли в природе система сборки для С которая всё сделает вообще сама

  • 1 - написана на самом С без каких либо зависимостей (в идеале stb_x.c like)
  • 2 - в качестве цели принимает лишь каталог исходников
  • 3 - самостоятельно составляет список зависимостей на основе заголовочных файлов
  • 4 - самостоятельно проверяет наличие нужный функций/констант/макросов сканируя код
  • 5 - может быть ещё какие плюшки

1* - не нашла main собирает библиотеки статическую/динамическую,если нашла то исполняемый файл. Я понимаю что эммм, скорее всего такого не существует, но может кто героически пилит подобное?

Deleted

И программой тоже сама пользуется.

А тебя - на свалку. СЛАВАРОБАТАМ!!!

ЗЫ да, есть - bash называется.

mos ★★☆☆☆
()

Да, хорошая тема, тоже такую ищу.

3 - самостоятельно составляет список зависимостей на основе заголовочных файлов

Если тебя устраивают текущие версии зависимостей библиотек, то имхо не очень то и сложно самому такую написать.

2 - в качестве цели принимает лишь каталог исходников

clang `find src/ -name «*.c» -type f` -o libastral
Ну ты понял...

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

Если тебя устраивают текущие версии зависимостей библиотек, то имхо не очень то и сложно самому такую написать.

Дык я готовое ищу, у меня больше интерес чем необходимость. Для мелочи make, для почти всё само meson есть.

clang `find src/ -name «*c» -type f` -o libastral Ну ты понял...

да понятно, но тут легче make написать нормальный, интересна система сборки которую можно поставлять вместе с исходником и при этом ей нужен лишь компилятор для самой себя, или вкидываем её в любой проект gcc cbuild.c && ./a.out и понеслось оно пытается собрать мне nautilus какойнить. Жирно хочу... но на то и фантазии :D

Deleted
()

Нет такого. Но минимум писанины и максимум удобства ты можешь извлечь из cmake.

Странно, что в тегах ты перечислил deprecated говно вроде автотулзов, но симейк забыл!

anonymous
()

P.S. Если бы была такая супер-пуперская система сборки, в генте никаких ебилдов писать не надо было бы!

Однако, приходится ручками зависимости указывать. И иногда получается проруха: вроде бы везде собирается, а на машине юзера N — нет, т.к. выясняется, что у него какого-нибудь общесистемного пакета, «который должен быть у всех», нет! И приходится это тоже в зависимости добавлять...

anonymous
()
Ответ на: комментарий от anonymous

deprecated говно вроде автотулзов, но симейк забыл!

Я удалил cmake и вставил C что бы кастануть народ

вроде автотулзов

это намёк на функционал, то есть поддержка функций/макросов и прочего

cmake.

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

Deleted
()
Ответ на: комментарий от anonymous

Однако, приходится ручками зависимости указывать.

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

Deleted
()
Ответ на: комментарий от anonymous

И в целом я имею в виду систему сборки поставляемую с самими исходниками так что бы единственной гарантированной зависимостью в системе был компилятор. собирается сама система сборки и пытается собрать остальное, чего то не хватает (например curl) клоним нужные сорцы (или оно само склонит при наличии нужного инструментария в системе), снова запускаем(запускается может даже само) сборку оно само подхватывает и снова пытается. И тут всё становится нетривиально, эта нетривиальность мне по приколу интересна.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 2)
Ответ на: комментарий от Deleted

Пиши лучше ебилды! И так дофига мусора в системе, а ты еще и к каждому пакету предлагаешь локальную систему сборки приаттачить!

anonymous
()
Ответ на: комментарий от anonymous

Пиши лучше ебилды!

Мимо, я дебианщик и пишу control`лы вместо ebuild`дов )

, а ты еще и к каждому пакету предлагаешь локальную систему сборки приаттачить!

Да, это спорно. Можно и в системе держать, а в той системе где нет достаточно вкинуть в каталог исходников 1 файл с системой сборки cc cbuild.c -o build && ./build всё, дальше оно само.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от anonymous

Вот кстати в пакетных бд очень не хватает nm листинга. Так можно было бы просто по .o/elf понимать, какие либы требуются проекту и ставить их при необходимости. Инклуд-пути уже можно по составу файлов определять.

anonymous
()
Ответ на: комментарий от Deleted

И в целом я имею в виду систему сборки поставляемую с самими исходниками так что бы единственной гарантированной зависимостью в системе был компилятор. собирается сама система сборки и пытается собрать остальное, чего то не хватает (например curl) клоним нужные сорцы

Тебе нужен пакетный менеджер и система сборки пакетов.

aureliano15 ★★
()
Ответ на: комментарий от anonymous

очень не хватает nm листинга

Напомни мне что это такое?

Интересно на попытки реализовать подобное посмотреть)) Главное что меня не прорвало самому начинать пилить такое, вот чем доьше думаю тем больше хочется, но сделать это реально по уму и реально «кросс» хотя бы в пределах всех линуксов включая кастомные LFS (иначе смысла нет) не смогу

Deleted
()
Ответ на: комментарий от anonymous

В случае strip не поможет. Это во-первых.

А во-вторых, как узнать, что за библиотека (и особенно - какая версия) нужна? Линкуют-то обычно с libass.so, а не libass.666.0

А вообще, после гентушки я на бинарные дистры не могу смотреть: ну как можно ими пользоваться, когда все собрано с непонятно какими флагами?

anonymous
()
Ответ на: комментарий от aureliano15

Тебе нужен пакетный менеджер и система сборки пакетов.

Во первых их куча и тех и других и все они как бы сказать... разные, то слабые, то неудобные, то тащат питон то ещё чего я понимаю почти 2k19 на дворе и всё это «не проблема» но если всё было бы идеально где то то не было засилия систем сборки, ну в рамках GNU есть целая экосистема где всё продумано с целью максимальной поддержки и портируемости...в рамках GNU короче везде компромисы. Скажем так я хочу систему сборки которой не нужно н-и-ч-е-г-о для сборки, кроме себя компилятора от c89 и собственно исходников, но при это если в системе есть иные средства вроде pkg-config/git/svn/apt/pkg/emerge/etc оно могло заюзать их для получения больших сведений или автоматического вытягивало нужное (как в каком нибудь termux или железке экзотичной). В случае если ничего нет или нет подходящего вываливало бы не мусор с ошибками как делают все, а структурированный список всего того что не хватает, заголовочные фалы, функции,константы иное. Да эта штука будет/есть/несуществует/не будет, должна сканировать исходники и это не быстро и это не из разряда философии ninja или ещё чего, это железная гарантия атоматической сборки....ето мячты :D

Deleted
()
Ответ на: комментарий от anonymous

ну как можно ими пользоваться, когда все собрано с непонятно какими флагами?

Я вот хоть и читал вики gentoo, но так и не понял как флаги работают, если моя говнософтина линкуется динамически с например с libastral, но я глобально укажу что этого мене не надо то как это разруливается? Я просто буду не иметь возможность поставить себе эту софтину (да я знаю что можно отдельному пакету флаги задать) или гентушники сорцы препарируют адаптируя софт под возможность задавать флаги для них?

Deleted
()
Ответ на: комментарий от anonymous

Вот кстати в пакетных бд очень не хватает nm листинга. Так можно было бы просто по .o/elf понимать, какие либы требуются проекту и ставить их при необходимости

Осиль RPM

annulen ★★★★★
()
Ответ на: комментарий от Deleted

Скажем так я хочу систему сборки которой не нужно н-и-ч-е-г-о для сборки

autotools так и задумывался. Пользователи всяких клонов VMS, конечно же, должны страдать

annulen ★★★★★
()
Последнее исправление: annulen (всего исправлений: 1)
Ответ на: комментарий от Deleted

Так такая сборка уже есть OS 3.0 называется не lite, а смесь de или ты хочешь переизобрести и получить с нее пряники, жди еще создатель голоден. Пока это все там расшифруется что это частично чуть ли не собираемый ии и.т.д. И что это в некоторых местах программирование не стандартное и вышло оно за счет того же сбоя ассоциации приложении.

anonymous
()
Ответ на: комментарий от annulen

autotools так и задумывался

Да и работает.Но оно завязано на GNU окружении и там чёрт ногу сломит, не спортивно...

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

Простой пример есть палка и её модернизировали в лопату для добычи денег и питания, а есть кто сделал лопату более надежнее и универсальнее сделав из нее комбайн который прокормил миллионы (программистов) крестьян которые поняли зачем мне лопата если я могу программировать ии комбайн который не то что бы прокормит всех, но и сможет делать уже другие вещи и фактически превратится в гига фабрику всего и вся на нем можно будет создать. Что проще называется эволюцией.

anonymous
()
Ответ на: комментарий от Deleted

эта штука [skip] должна сканировать исходники

Некоторые исходники и человеку-то без дебагера просканировать сложно. А бывают такие, что и с дебагером ничего не ясно. А ты хочешь, чтобы это делал бот. Если такой бот когда-нибудь появится, то ни программисты, ни все остальные будут уже не нужны. Начнётся новый этап эволюции под названием «искусственный интеллект», а человечество попадёт на свалку истории.

aureliano15 ★★
()

cargo.

Серьезно, ржавые программисты просто зависимости прописывают, а дальше оно само...

anonymous
()
Ответ на: комментарий от anonymous

Я про него думал, да и не только про него npm,gem и прочее из той же оперы. Тут пакетная система и централизованный репозиторий нужен

Deleted
()
Ответ на: комментарий от Deleted

Но оно завязано на GNU окружении

Сам автотулз не завязан на GNU, при правильном подходе все должно работать на любом юниксе, в начале пути даже о нормальной POSIX-совместимости речь не шла, многочисленные костыли позволяли обойти несовместимости тогдашних систем со стандартами. Но таки да, в реальных проектах часто много прибивок к гнутым утилитам есть

annulen ★★★★★
()

Не уверен что есть.

Но я сделал проще. Я просто написал на башике генератор для стандартного консольного утиля, демона и разделяемых библиотек.

Один пень после наполнения кодом файл config.in.h править. А в автотулзах, при сборке можно проверять наличие и файлов и функций в них. Чего ещё-то?

Может, автотулзы правильно научиться готовить? Ну либо на meson переходить?

Moisha_Liberman ★★
()
Ответ на: комментарий от annulen

+1!

Всё так. Автотулзы живут практически везде, где есть следование стандартам POSIX. Хоть в QNX. Хоть в соляре. Другое дело что их готовить надо умеючи.

Moisha_Liberman ★★
()
Ответ на: комментарий от Deleted

Если...

Если не писать ebuild, хотя это и хреновая идея, то можно указывать ключи для configure вида --with/--without. Т.е., если софтина линкуется либо с libpq (для postgres), либо с Berkeley DB (bdb), то так и указывают с чем линковать в конкретном случае. Если вообще ни с чем, то софтину скорее всего не поставить. Ну а нафиг она, если хранить данные в БД должна, а не может?

Moisha_Liberman ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.