Ночную сборку можно производить автоматически, или полуавтоматически, с помощью fasm. Сборка занимает 1-2 сек. Пример или альфа версию кода я сбросил майку (Mike.dld), так что ждем от него решения.

А можно посмотреть решение? И что мешает делать автоматически?
Еще меня интересует вопрос, как ядро сжать под linux-ом

turbanoff wrote:Еще меня интересует вопрос, как ядро сжать под linux-ом

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

turbanoff wrote:А можно посмотреть решение? И что мешает делать автоматически?

Ссылку сбросил через PM. При добавлении нового файла нужно модифицировать скрипт.
Желательно kpack'ом предварительно сжать все программы, скрипт собирает образ floppy 1.44 из готовых, собранных программ.

От Майка получен положительный отзыв о моей работе. Я надеюсь, в ближайшее время ночные сборки в формате дискеты восстановятся.

Я не понимаю, в чём сложности настройки, которые до сих пор мешают сделать автоматическую сборку образов дискет на сервере. Судя по 404-й странице, отдаваемой сервером kolibrios.org, там стоит Linux. fasm под Linux давно существует, kpack не столь давно, но тоже работает, образ вообще можно собирать встроенными средствами - через mount - а если не устраивает требование прав рута для mount, то есть mtools. Я вчера из интереса посидела пару часов, составила makefile полуавтоматически из содержимого kolibri.img из последней ночной сборки и build_all.bat из исходников её же, ничего сложного не заметила. На случай, если кого-нибудь заинтересует, я выложила результаты в http://ftp.kolibrios.org/users/CleverMouse/imgbuild/ - файл data.7z содержит Makefile и данные, не собираемые из исходников на svn; сборка осуществляется командой make в предположении, что в PATH есть fasm,kpack,mtools, в папке ../repos есть локальная копия репозитория, файл macros.inc также скопирован как MACROS.INC в папке с данными и в ../repos/programs; kolibri.img - результат сборки. Я обращаю внимание, что Makefile - скорее proof-of-concept, он НЕ собирает ядро, он собирает только те программы, исходники которых написаны на fasm и есть на svn - соответственно, в kolibri.img старое ядро и обновлены только указанные программы, - в нём не указаны зависимости. Я просто не хотела тратить слишком много времени на, возможно, ненужную вещь.

Если причиной является нехватка времени, я могу заняться настройкой, если меня пустят на сервер - в смысле выдачи ssh-аккаунта, у которого есть права на запись в какой-нибудь скрипт, вызываемый из post-commit хука svn, и права на запись в какую-нибудь область сайта для выкладывания результатов, в предположении, что на сервере стоит набор gcc/g++/make - тогда остальное из нужного я смогу собрать там сама.

Независимо от вышесказанного я предлагаю обсудить вопрос данных, необходимых для сборки образов. Я считаю разумным, чтобы дополнительные данные мог изменять достаточно широкий круг людей, как и исходные тексты программ. Поэтому я выношу на обсуждение предложение вынести упомянутые данные - конфиги, бинарники, которые сложно собрать автоматически, сборочную программу, будь она makefile'ом, скриптом или специальной программой, - завести на svn либо четвёртой папкой с именем типа data или extra или build в корне основного репозитория, либо завести рядом второй репозиторий на параллельном порту. Что скажете?

CleverMouse wrote:Независимо от вышесказанного я предлагаю обсудить вопрос данных, необходимых для сборки образов. Я считаю разумным, чтобы дополнительные данные мог изменять достаточно широкий круг людей, как и исходные тексты программ. Поэтому я выношу на обсуждение предложение вынести упомянутые данные - конфиги, бинарники, которые сложно собрать автоматически, сборочную программу, будь она makefile'ом, скриптом или специальной программой, - завести на svn либо четвёртой папкой с именем типа data или extra или build в корне основного репозитория, либо завести рядом второй репозиторий на параллельном порту. Что скажете?

Идею считаю разумной. В качестве примера предлагаю вариант с libre.fm: Т.е. код - в одном месте, не_код - в другом. Тем более, что у нас кроме сборочных скриптов есть и такие вещи как скины, обои, шрифты, иконки, в поисках которых приходится лазить по форуму (не всегда успешно, кстати).

В общем, я был бы рад видеть отдельный репозиторий.

Я тоже за отдельный репозиторий для бинарников. Некоторые вещи сложно собрать не разработчику.

CleverMouse wrote:Если причиной является нехватка времени, я могу заняться настройкой, если меня пустят на сервер - в смысле выдачи ssh-аккаунта, у которого есть права на запись в какой-нибудь скрипт, вызываемый из post-commit хука svn, и права на запись в какую-нибудь область сайта для выкладывания результатов, в предположении, что на сервере стоит набор gcc/g++/make - тогда остальное из нужного я смогу собрать там сама.

имхо дело не в нехватке времени, и не в сложности задачи. Просто эти ночные сборки (как и составление дистрибутивов), увы!- часто оказываются и причиной каких-то мелочных склок и глубоких обид.
Хочу напомнить, что одного очень толкового парня эта очень нужная работа довела до черной мизантропии и нервного срыва. Очень жаль.

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

И призываю всех к понижению градуса неконструктивной критики в Новом году.

С наступающим!

Ночная сборка, образ дискеты собирается с помощью fasm. Но решение не допилено, существуют ошибки в образе дискеты. В ближайшее время не могу заняться этой проблемой т.к. загружен на работе.

Архив 550 кб http://filesurf.ru/211766

<Lrz>, я посмотрела твой архив. Во-первых, там нет поддержки длинных имён файлов. Во-вторых, он занимается только сборкой образа дискеты из готовых файлов, а это только последняя операция в цепочке полной сборки.
art_zh, я не могу сказать, что внимательно изучала историю вопроса, но насколько я поняла, под твоё описание подходят минимум двое - с поправкой на то, что в первом случае речь идёт только о дистрибутивах, ночные сборки появились позже. Именно поэтому я предлагаю вынести все данные, нужные для сборки, куда-нибудь, где их смогут править большое количество людей, чтобы не сваливать всё на кого-то одного, - это вторая часть моего поста, первая касается технических вопросов о том, как из "данных, нужных для сборки", сделать сборку.

troll mode on Разве основной причиной ухода diamond'а были ночные сборки, а не тенденции "просто почесать языками" и "пописать в нуль-кольце на сях" (c) diamond.kolibrios.org? Интересно, что он сказал бы про оболочку на Delphi над своими ассемблерными mtldr_install и usb_boot...