Центр информации по операционным системам: Форумы / Разное / Инструментальная инфраструктура для проекта ОС

Центр информации по операционным системам :: Форумы :: Общие :: Разное		<< Предыдущая тема \| Следующая тема >>
Инструментальная инфраструктура для проекта ОС


Модераторы: Roman I Khimov, Wanderer, Dron

Автор

Добавил

Vadim Ushakov

Пятница 07.04.2006 15:43

ID пользователя #409

Зарегистрирован: Четверг 18.08.2005 04:25
Местонахождение: Красноярск
Сообщений: 85

Не придумал адекватного названия для топика... Ладно, и так сойдет.
Дело в следующем. Я сейчас занимаюсь программированием пакета средств для проведения автоматизированных операций над такими вещами, как дерево исходных текстов какого-либо проекта и т.п. Пакет представлет собой совокупность make- и sh-скриптов плюс некоторое количество мелких утилит на Си и perl-кода. Когда я спрашивал гуру по поводу подобных средств, мне показывали пальцем на вещи типа automake, autoconf и т.п. - но это несколько из другой области; automake - это скорее "кирпичи", а мне нужен был "универсальный клей". Отсутствие подобного продукта в обозримом пространстве и побудило сесть и писать самому.
Планируемые возможности такие:
1. Сборка целевых файлов (бинарных файлов, файлов документации, настроечных файлов и т.п.) из исходников с отлеживанием максимального количества зависемостей: по include-файлам, по командам и флагам сборки, по параметрам конфигурации, и т.п. Пока это единственный пункт, который реализован и доведен до стадии беты.
2. Развитые средства конфигурирования, включающие в себя отслеживание зависимостей между опциями конфигурации и удобное графическое представление дерева опций. В этих двух пунктах многие узнают набор скриптов из /usr/src/linux/scripts. На самом деле именно они и послужили идеей. Пока в качестве конфигуратора приспособлен код из /usr/src/linux/scripts (библиотека парсера + графический frontend).
3. Интеграция с средствами для извлечения документации непосредственно из исходных текстов.
4. Интеграция с средствами для извлечения и компиляции других видов документации. Под этим я понимаю в первую очередь набор соответствующих sgml-описаний.
5. Взаимодействие с cvs.
Тот код, который готов сейчас, работает в GNU/Linux, а также Винде из-под MinGW/MSYS. (За исключением графического конфигуратора, которому нужен QT.) Сегодня я тестировал пакет в FreeBSD, в принципе проблем не возникло, за исключением нескольких команд, которые требуют BSD-подобный синтаксис вызова.
В итоге конечная цель - написать удобную и мощную инфраструктуру для использования в таких серьезных вещах, как проекты трансляторов, ядер, или целых операционных систем; такое особое инструментальное средство, которое склеивает собой много прочих инструментальных средств.

У меня такие вопросы:

1. Если кто имел большой опыт по написанию скриптов, переносимых между GNU и BSD, то просьба поделиться идеями. Имеет ли смысл вообще браться за такое занятие, учитывая довольно сильное различие между системами и тот объем работ, который планируется выполнить? Или проще сразу забить на BSD? Забить на GNU мы не можем, поскольку совместимость с MinGW - одно из ключевых требований. Тем не менее, поддерживать совместимость с BSD тоже очень хочется.

2. Сейчас я планирую сделать пакет доступным по GPL, однако тут такая заковыка: в проекте, использующем мой пакет, будут тесно переплетены конфигурационные файлы моего пакета и собственно исходный код этого проекта. Возможна неоднозначная трактовка GPL, которая "заражает" этот проект своей опенсорсностью. Это главный вопрос, который меня сейчас терзает. Стоит ли выбрать более "слабую" лицензию, например лицензию BSD?

3. Ну и последнее. Если кому-то интересен подобный пакет программ, то любая помощь приветствуется.

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

Падает тот, кто бежит; тот, кто лежит – уже не падает.

Наверх

Roman I Khimov

Суббота 08.04.2006 14:48

ID пользователя #1

Зарегистрирован: Воскресенье 27.06.2004 12:37
Местонахождение: Санкт-Петербург
Сообщений: 601

Встречный вопрос - чем это будет лучше Kbuild, используемого Linux? С зависимостями, думаю, все понятно, про конфигурирование, опять-таки, думаю, что тоже. Третье описано в Documentation/kernel-doc-nano-HOWTO.txt, тоже есть. Четвертое запросто дописывается в тех же Makefile'ах. А вот пятое мне не совсем понятно.

Еще же есть всякие чудовищные scons, cmake, smake, unsermake... Я, к сожалению, плохо знаком с этими проблемами (kbuild все-таки работает еще

, однако, рассматривались ли эти варианты?

Греби и улыбайся!

Наверх

Vadim Ushakov

Суббота 08.04.2006 16:06

ID пользователя #409

Зарегистрирован: Четверг 18.08.2005 04:25
Местонахождение: Красноярск
Сообщений: 85

Roman I Khimov написал(а) ...
Встречный вопрос - чем это будет лучше Kbuild, используемого Linux?

На самом деле всё началось как попытка адаптировать Kbuild под свои нужды. Но очень быстро я понял, что Kbuild во многом расходится с предъявляемыми требованиями. Всё-таки он заточен на сборку ОДНОГО результирующего объекта, да и в коде довольно много мест, которые проще написать заново, чем пытаться понять, что имел здесь ввиду автор. Так что я потратил около недели на пристальное изучение исходных кодов Kbuild, а потом, проникнувшись идеей, сел и написал с нуля. Считаю, что реализация многих вещей у мне удалась лучше, чем авторам Kbuild. Хотя вот я сплагиатил у них библиотеку парсера, но видно придется ее написать самому с нуля - что-то не хочется связываться с GPL. Не то что бы я был против GPL вообще, но думаю, что здесь она будет неуместна.

Roman I Khimov написал(а) ...
Третье описано в documentation/kernel-doc-nano-HOWTO.txt, тоже есть. Четвертое запросто дописывается в тех же Makefile'ах.

Ну что за вредная привычка тыкать носом в какой-нибудь HOWTO?

Между прочим, под Mandrake sgml-документация не собрается даже с бубном (во всяком случае, я не нашел подходящей величины бубен), а под SUSE по умолчанию невозможна работа ни xconfig, ни gconfig. Однако это так, к слову.
Мне не надо "в HOWTO" и "в тех же Makefile'ах". В Makefile'ах одной программы, в Makefile'ах другой программы, в Makefile'ах сто сорок шестой программы... Мне нужно написать один раз код - и использовать; и забыть навсегда вообще, как он там внутри работает. Предполагается, что все виды документации (спецификации, SDK, мануалы...) храняться в однообразном виде и привязаны к "своему" контексту: SDK - к конкретным h-файлам, ман-ы - к определенной целевой программе, и т.п. (Вполне логично, что описания функциий и структур лежат в самом h-файле, а, например, описание синтаксиса конфигурационного файла - в исходнике модуля, который этот файл будет интерпретировать.) Вся документация должна извлекаться, форматироваться и компилироваться АВТОМАТИЧЕСКИ. Т.е. средствами системы сборки.

Roman I Khimov написал(а) ...
А вот пятое мне не совсем понятно.

Мне и самому пока не очень понятно...

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

Будем реалистами.

Roman I Khimov написал(а) ...
Еще же есть всякие чудовищные scons, cmake, smake, unsermake... Я, к сожалению, плохо знаком с этими проблемами (kbuild все-таки работает еще , однако, рассматривались ли эти варианты?

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

И к тому же, я сильно сомневаюсь, что перечисленные "чудовищные" средства работают под MinGW - он сам-то по себе не особо работает... А мне НУЖНА совместимость с MinGW - не столько ради любви к файловому менеджеру Total Commander, сколько оттого, что я леею планы "перетащить" на свой сборочный пакет систему UzhOS. Те средства сборки, которые там есть сейчас лично меня не устраивают - они Uzhасны.

Падает тот, кто бежит; тот, кто лежит – уже не падает.

Наверх

Dron

Воскресенье 09.04.2006 12:22

ID пользователя #13

Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651

есть еще jam но это тоже просто альтернатива мейка...

Насчет документации - мне не кажется хорошой идеей вносить документацию в файлы инклюдов...

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

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

Что же касается документауции - программисты не любят писать документацию Ж) хотя надо... а писателей в исходный код пускать нельзя. Ж)

Было бы хорошо при сборке проверять актуальность документации, которая конечно хранится в другом файле.

И варнинги выдавать. Ж)
а инклюды вообще давить. Ж)

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

Андрей Валяев

Наверх

Vadim Ushakov

Воскресенье 09.04.2006 14:31

ID пользователя #409

Зарегистрирован: Четверг 18.08.2005 04:25
Местонахождение: Красноярск
Сообщений: 85

Два и более раз писать одно и тоже приходится, когда ты сначала пишешь спецификацию на модуль, потом пишешь к нему заголовочные файлы, потом пишешь по заголовочным файлам SDK, потом... Короче, ясно. doxygen еще никто не отменял, слава богу. И никакого излишнего дублирования, поскольку SDK извлекается непосредственно из коментариев к функциям, классам, аргументам, шаблонам и т.п. А спецификацией на заголовочный модуль является он сам.

Программисты ОБЯЗАНЫ писать документацию на свой код. При чем, сначала - документацию, а потом - код. Личные пристрастия отдельных индивидумов меня не трогают. А "писателям" в исходном коде делать нечего. Технические писатели будут всякие "юзверь мануал" писать, это уже по другому ведомству проходит.

Dron написал(а) ...
Было бы хорошо при сборке проверять актуальность документации, которая конечно хранится в другом файле.

Отлично. Каким АЛГОРИТМОМ мне удостовериться, что ИСХОДНИК ДОКУМЕНТАЦИИ корректно соответсвует ИСХОДНИКУ КОДА? Программист сначала изменяет функцию в интерфейсе, потом лезет в другой файл за тридевять земель, ищет там описание этой функции и вносит поправки... Утопия. А если все спецификации будут перед глазами непосредственно в исходнике, тогда это будет гораздо проще.

Падает тот, кто бежит; тот, кто лежит – уже не падает.

Наверх

Dron

Воскресенье 09.04.2006 15:37

ID пользователя #13

Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651

Ну знаю как кому, а мне многостраничные описания в коде изрядно мешают.

Документацию можно хранить в определенном формате.
актуальность естественно проверяется по прототипам...

А как ты обеспечишь идентичность описания функции и ее исходного кода в том случае когда описание идет в исходном тексте? описание легко может устареть.

Документацию для программистов - программисты писать должны. я знаю Ж) но лень.

Так же как пользователи никогда не читают документацию - так же и программисты никогда ее не пишут... ибо им и без нее хорошо. Это конечно шутка. Много чего надо делать но много чего не делается.

Андрей Валяев

Наверх


Перейти: Наверх