Closed GoogleCodeExporter closed 9 years ago
Итак, что предлагалось Антоном:
Есть папка ./projects (нынешняя ./templates), в ней
папки, относящиеся к конкретной
платформе/архитектуре. В них под-папками
цели, содержащие уже конфиги, и еще глубже
патчи к ним.
При конфигурировании указывается проект и
цель. Конфигер накладывает патчи на базовый
конфиг и создает в папке ./conf под-папки,
соответствующие патчам. При сборке
создаются образы для каждого
пропатченного конфига.
Например:
./projects/
sparc-ovk/
release/ // Пример базового конфига без патчей (то, что есть сейчас)
*.conf
simulation/
io_board/
mods-tests.conf // Здесь включен единственный нужный тест
mods.conf // включает mods-tests.conf, который будет взят из патча
*.conf // Базовый конфиг (не считая mods.conf)
microblaze/
debug/
*.conf
compiler/
shift-O0/
mods-tests.conf
*.conf
make config PROJECT=sparc-ovk TARGET=simulation
./conf/
io_board/
*.conf // Пропатченные конфиги
// Вот тут непонятно, а если патчей как таковых нет (например для цели release)?
// И нужно ли делать сборку для базового кофига?
make
./build/
io_board/ // Внутри сегодняшняя структура
bin/
embox
...
obj/
...
// Аналогичный вопрос про сборку базового конфига. Куда его класть?
Поправьте, если я что-то не так понял.
Плюсы:
+ Мало изменений в системе сборки,
дорабатывается только конфигер
+ Наглядные пропатченные конфиги в
подпапках папки ./conf
Минусы:
- На мой взгляд, не самое наглядное
размещение итоговых образов
- Для каждого конфига делается полная
перекомпиляция проекта, что является
необходимым далеко не всегда
Original comment by Eldar.Abusalimov
on 21 Mar 2010 at 1:00
Что предлагал я:
В целесообразности такой глубины
вложенности ./projects меня в целом убедили.
Про структуру ./conf мне нравится
предложенный вариант, но, опять же,
непонятно, как
быть с базовым конфигом и что делать со
скоростью сборки. Я ничего не могу
предложить
на тему того, как избавиться от лишней
пересборки, при условии, что в подпапках
./conf лежат уже пропатченные конфиги (то есть
по сути разные файлы с похожим
содержимым).
Можно перенести процесс наложения патчей
на стадию сборки, а в папке ./conf повторять
структуру ./projects/<project>/<target> (то есть хранить
файлы базового конфига и
под-папки с патчами). В этом случае теряется
наглядность в ./conf, но зато можно
извернуться и обойтись без повторных
перекомпиляций всего и всех.
Папка ./build в моем представлении должна
выглядеть примерно так:
./build/
bin/
embox // Сборка для базового конфига
embox-test_io_board // Для соответствующего патча
...
// + куча файлов с такими же именами и расширениями .dis, .srec и т.д.
obj/
// куча говна, зависящего от подхода к решению задачи минимизации числа
перекомпиляций проекта
По сложности реализации - примерно то же
самое, что и в предыдущем случае + решение
этой самой пресловутой задачи.
Сама задача - свести к минимум наложение
патчей на файлы, от которых зависят все
объектники. В нашем случае это build.conf и
options.conf, а также файлы, включаемые в
них через #include. Если же изменяются lds.conf или
mods.conf, то требуется только
повторная линковка, без перекомпиляции.
Original comment by Eldar.Abusalimov
on 21 Mar 2010 at 1:34
Леха, напиши, что есть сейчас и что остается
доделать.
Original comment by Eldar.Abusalimov
on 21 Mar 2010 at 1:36
Ага собственно со всем согласен.
Мой вариант на мой взгляд было проще
реализовать для человека который не писал
макефайлы.
В будущем то что предлагает хочется то что
предлагает Эльдар, там есть еще один плюс.
Легко делать сохранении цели из рабочей в
темплейты
Original comment by Anton.Bo...@gmail.com
on 21 Mar 2010 at 7:36
Собственно, написано "как хотел Антон" за
исключением того, что сейчас нормально не
разбита папка с template, но это надо аккуратно
сделать + сейчас нет переменной
PROJECT, все запихивается в TARGET ( := sparc/release,
например) Согласен, надо
поправить... Тут, как говорится, надо было,
чтобы работало=)
Так что человек, который не писал
мэйкфайлы, сделал так.
Original comment by Fomin.Al...@gmail.com
on 21 Mar 2010 at 10:26
Да, посмотрел внимательно, что написал
Эльдар. Там на самом деле "то, что есть
сейчас" - это только из-за убогих template'ов... в
конфигурилке уже написано
нормально. Сегодня вопрос решу.
Original comment by Fomin.Al...@gmail.com
on 22 Mar 2010 at 9:52
Мне, кстати, кажется, что лучше mods.conf
хранить в папке с "патчем", чтобы в общей
части включать mods.conf, который у разных
патчей может быть разным... Вдруг,
например, какому-то тесту понадобится
специфичный драйвер.
Original comment by Fomin.Al...@gmail.com
on 22 Mar 2010 at 10:00
Это уже вопросы соглашений, что тоже
немаловажно, но к этому таску они отношения
не
имеют. Механизм наложения патчей будет
работать во всех случаях.
Original comment by Eldar.Abusalimov
on 22 Mar 2010 at 3:27
Если никто не возражает, задачу я закрою -
более крутую (как говорил Эльдар, с
возможностью создавать конфиги и
отслеживанием, где патч, а где - базовая
конфигурация) конфигурилку делать - задача
отдельная, не будем смешивать тут.
Original comment by Fomin.Al...@gmail.com
on 25 Mar 2010 at 8:55
Original issue reported on code.google.com by
Eldar.Abusalimov
on 21 Mar 2010 at 12:24