Regression testing scripts

[GoogleCodeExporter]

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

Original issue reported on code.google.com by Eldar.Abusalimov on 21 Mar 2010 at 12:24

[GoogleCodeExporter]

Итак, что предлагалось Антоном:

Есть папка ./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

[GoogleCodeExporter]

Что предлагал я:

В целесообразности такой глубины 
вложенности ./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

[GoogleCodeExporter]

Леха, напиши, что есть сейчас и что остается 
доделать.

Original comment by Eldar.Abusalimov on 21 Mar 2010 at 1:36

[GoogleCodeExporter]

Ага собственно со всем согласен.
Мой вариант на мой взгляд было проще 
реализовать для человека который не писал 
макефайлы.
В будущем то что предлагает хочется то что 
предлагает Эльдар, там есть еще один плюс.
Легко делать сохранении цели из рабочей в 
темплейты

Original comment by Anton.Bo...@gmail.com on 21 Mar 2010 at 7:36

[GoogleCodeExporter]

Собственно, написано "как хотел Антон" за 
исключением того, что сейчас нормально не 
разбита папка с template, но это надо аккуратно 
сделать + сейчас нет переменной 
PROJECT, все запихивается в TARGET ( := sparc/release, 
например) Согласен, надо 
поправить... Тут, как говорится, надо было, 
чтобы работало=)
Так что человек, который не писал 
мэйкфайлы, сделал так.

Original comment by Fomin.Al...@gmail.com on 21 Mar 2010 at 10:26

[GoogleCodeExporter]

Да, посмотрел внимательно, что написал 
Эльдар. Там на самом деле "то, что есть
сейчас" - это только из-за убогих template'ов... в 
конфигурилке уже написано
нормально. Сегодня вопрос решу.

Original comment by Fomin.Al...@gmail.com on 22 Mar 2010 at 9:52

[GoogleCodeExporter]

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

Original comment by Fomin.Al...@gmail.com on 22 Mar 2010 at 10:00

[GoogleCodeExporter]

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

Original comment by Eldar.Abusalimov on 22 Mar 2010 at 3:27

[GoogleCodeExporter]

Если никто не возражает, задачу я закрою - 
более крутую (как говорил Эльдар, с
возможностью создавать конфиги и 
отслеживанием, где патч, а где - базовая
конфигурация) конфигурилку делать - задача 
отдельная, не будем смешивать тут.

Original comment by Fomin.Al...@gmail.com on 25 Mar 2010 at 8:55

• Changed state: Fixed