2014-10-29 2 views
0

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

По сути то, что я хотел бы сделать, это:

if somedir/build does NOT has RPMs: 
    somedir/build.sh 

cp -R somedir/build/* destination 

Я играл с использованием $(shell if [[ -d somedir/build ]] ....), но не имея много удачи.

+0

Если этот каталог не имеет * любой * RPM? Можете ли вы создать отдельные RPM с помощью make или просто запустить один скрипт «gotta build» em all? Какая цель или предварительное условие касаются ваших RPM на данный момент? Есть ли это? –

+0

Если вы используете make, почему бы не сделать часть rpms цепочки зависимостей? Как вы определяете, какие rpms необходимо построить в сценарии оболочки? – user657267

+0

@EtanReisner, так что «somedir/build.sh» создает RPM. В данный момент у меня нет цели. – codecraig

ответ

0

Это работает:

someproject_rpms: 
    @if [[ -d somedir/build ]] ; then \ 
     count=$$(find somedir/build -name "*.rpm" -type f | wc -l); \ 
     if [[ $$count -eq 0 ]]; then \ 
      $$(cd somedir && ./build.sh); \ 
     fi \ 
    else \ 
     $$(cd somedir && ./build.sh); \ 
    fi; \ 
    find somedir/build -name "*.rpm" -type f -exec cp {} somedestination \; 

не самый красивый, но это работает.

+0

Вы хотите скопировать структуру каталогов в пункт назначения или плоскую копию .rpms. Ваш вопрос делает первый. Ваш ответ делает последнее. Поэтому ваш ответ не является технически правильным. Что вам нужно? –

+0

Вопрос показывает, что мне нужно скопировать RPM в пункт назначения (cp -R somedir/build/* destination), что я также показываю в ответе, правильно? – codecraig

+0

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

0

Вы должны использовать так называемые «дозорные» файлы. Это пустые файлы, которые используются только для их метки времени, а временная метка означает завершение какого-либо действия, обычно создавая кучу других файлов, имена которых мы можем или не можем знать. Эти два файла с именем rpms являются дозорные файлы, а вот ваше решение Makefile:

destination/rpms: somedir/build/rpms Makefile 
    find $(<D) -name *.rpm -exec cp {} $(@D) \; 
    touch [email protected] 

somedir/build/rpms: $(PACKEES) Makefile 
    somedir/build.sh 
    touch [email protected] 

PACKEES прямо сейчас пусто, но вы должны установить, что это будет все файлы, которые вы хотите быть упакованы в любую из ваших оборотов в минуту , другими словами, все файлы, которые build.sh читает. Если вы настаиваете на использовании одного build.sh скрипт для создания всех RPMs сразу (что это не очень хорошая идея), выше является лучшее, что вы собираетесь получить :)

+0

Хотя я полностью согласен с этой концепцией * как лучшей концепцией, чем то, что я дал в своих комментариях. Я думаю, что эта реализация на самом деле не лучше. Он не восстанавливает RPMS, если RPM удаляются, но исходные файлы не изменяются (если вы не включите их в '$ (PACKEES)', которые вы, безусловно, можете сделать). Он также требует ручного ведения списка, который, если он будет несовместим, не будет построен, когда вы ожидаете, что это может быть (режим отказа, который отсутствует в простейшем методе build-if-missing). Есть причина, по которой я потратил немало времени на создание сценариев для извлечения файлов требований из моих файлов спецификаций. =) –

+0

@ Этан, хорошо, поэтому мы вежливо не согласны с философией здесь. Я не разрешаю произвольные удаления в моей системе сборки. Для меня система сборки - это конечная машина, где допускаются только определенные действия: трогание источников и создание целей, в том числе чистых. Но не удалять вручную. Если пользователь делает это, они сами по себе. Это то, что я говорю в своих руководствах. Во-вторых, я считаю, что «ручное ведение списков» как плюс на самом деле, а не минус. IMHO, все списки файлов, должны быть явно объявлены пользователем, если это возможно, не найдены с помощью подстановочных знаков или некоторых таких. Конечно, декларируется только в одном месте, не повторяется. –

+0

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

Смежные вопросы