1) Можно ли в нескольких целях указать одну и ту же зависимость так, чтобы она выполнялась каждый раз для достижения каждой из целей? 2) Можно ли задать команду так, чтобы её параметры зависели от расширения цели? Например. Хотелось бы избавиться от повторяющихся подпоследовательностей команд: Код (Text): project: x.dll y.exe x.dll: x.obj $(LINKER) $(DLLOPTS) $(LINKFLAGS) $(OPTIMIZEFLAGS1) $*.obj echo ^ Linking: $@ del $*.obj $*.exp y.exe: y.obj $(LINKER) $(LINKFLAGS) $(OPTIMIZEFLAGS1) $*.obj echo ^ Linking: $@ del $*.obj *.lib 3) nmake из набора VS 2005 (v8.00.50727.762) не распознаёт правило вывода .obj.dll. Код (Text): all: my.dll .obj.dll: $(LINKER) $(DLLOPTS) $*.obj Консольный вывод: NMAKE : fatal error U1073: don't know how to make 'my.dll' Почему он не видит связи?
leviafan если я правильно понял вопрос, то надо просто объявить эту зависимость как цель без зависимостей, nmake будет всегда считать ее изменившейся и делать действия, связанные с ней. в nmake, скорее всего, нет. а ты точно уверен, что nmake поддерживает цели типа .x.y ?
meduza не совсем то... например, хочется чтобы в задании из двух и более подобных целей (t1, t2): Код (Text): all: t1 t2 t1: PrintNewLine x.exe y.exe some commands t2: PrintNewLine x.dll y.dll some other commands PrintNewLine: echo. PrintNewLine или любая другая нужная зависимость выполнялась каждый, а не один раз (nmake считает, что при достижении цели t1 PrintNewLine была достигнута и в t2 забивает на эту зависимость). ну, во-первых, в MSDN данному типу целей отведён целый блок, описывающий т.н. правила вывода (inference rules), а во-вторых, в nmake уже присутствуют умолчания, которые можно переопределять, а иногда удобнее использовать как есть, среди них, к примеру, .asm.obj, .c.obj, .cpp.exe и др.
leviafan > 2) ... Imho. Для очистки принято делать специальную цель - clean(up) 3) ... Ты где-нибудь описал цель Код (Text): my.dll: от_чего_она_зависит_напрмер_obj'и_def'ы_и_т.д.
q_q да ну?? = ) вроооде бы в обсуждении нигде про очистку не упоминалось... Правила вывода типа .obj.dll как раз и определяют получение любой цели с расширением dll из одноимённой зависимости с расширением obj. Более того (см. выше) умолчания типа .asm.obj работают и переопределяются прекрасно!!
leviafan Просто запихивать команды типа "del $*.obj $*.exp" в обычные цели считается плохим стилем. Лучше для этого делать специальные абстрактные цели типа clean. К тому же если так писать, то пропадает главное достоинство make - не пересобирать файлы, которые не изменились, а у тебя объектники будут удаляться после каждого вызова make и каждый раз все будет собираться по-новому. А теперь понял. Не знаю, как это решается, но возникает один вопрос - зачем такое нужно? (надеюсь пример с "PrintNewLine" был шуткой).
Да, согласен, но это тестовый пример, для отладки, как раз нужно было пересобирать при каждом запуске...
Первое что пришло в голову... хотя я видел такой пример, где nmake формировал целый отчёт в хорошем оформлении, он использовался как инструмент синхронизации двух каталогов с выполнением некоторых дополнительных плановых заданий...
leviafan хоть для отладки, зоть для чего-угодно -- зачем заново пересобирать что-то, если никаких изменений не было!?
leviafan > .obj.dll как раз и определяют получение любой цели с расширением dll из одноимённой > зависимости с расширением obj Спасибо, что объяснил. Гы-гы-гы. > .asm.obj работают и переопределяются прекрасно!! Отличие в том, что когда nmake видит Код (Text): .asm.exe: $(AS) $(AFLAGS) $*.asm asm-файлы существуют, а когда он видит Код (Text): all: my.dll .obj.dll: $(LINKER) $(DLLOPTS) $*.obj obj-файлов еще нет. Создай отдельно объектники, дай их nmake'у и он создаст dll'ку. Imho nmake не умеет делать логическую цепочку от my.asm до my.dll. Ему нужна помощь, вариант #6. > вроооде бы в обсуждении нигде про очистку не упоминалось... это тестовый пример ... > Первое что пришло в голову Imo с просьбами прокомментировать сферического коня в вакууме обращайся в хип, умник. ps учи матчасть.
q_q, не слишком ли высокая у тебя самооценка??! Опустив тезисы, выходящие за рамки данного обсуждения, сделаю акцент на том, что твои аргументы и вывод: абсолютно несостоятельны и показывают лишь то, что ты не знаешь предмета (и не умеешь читать документацию). Моя очередь: Для просмотра макроопределений, правил вывода, целевых объектов, списка .SUFFIXES существует специальная полезная опция - /p. Будем отслеживать с её помощью текущие правила вывода. Если использовать данную опцию без указания make-файла или без переопределения соответствующих правил и списка суффиксов, то в потоке вывода будут присутствовать только стандартные, описанные в документации умолчания. q_q, обрати внимание, что среди них .asm.obj будет иметь более высокий приоритет, чем .asm.exe. Таким образом, чтобы скомпилировать из asm-файла соответствующий exe-шник (dll-ку), можно использовать, например, такой make-файл: Код (Text): M32_PATH = c:\masm32 AS = $(M32_PATH)\bin\ml.exe AFLAGS = /nologo /coff /I$(M32_PATH)\include LINKER = $(M32_PATH)\bin\link.exe DLLOPTS = /dll /noentry LINKFLAGS = /nologo /libpath:$(M32_PATH)\lib /subsystem:console OPTFLAGS = /opt:nowin98 .SILENT: t1.exe: t1.obj $(LINKER) $(LINKFLAGS) $(OPTFLAGS) $** t2.dll: t2.obj $(LINKER) $(DLLOPTS) $(LINKFLAGS) $(OPTFLAGS) $** Используя опцию /p, можно убедиться, что obj-файлы (если они ещё не созданы) будут автоматически компилироваться из соответствующих asm-файлов согласно правилу: Код (Text): .asm.obj:: $(AS) $(AFLAGS) /c $< Естесственно, что мы можем переопределить стандартные правила вывода, а, также, как это утверждается в документации, создавать новые, не забывая вносить соответствующие расширения зависимостей в список суффиксов. Код (Text): # директива .SUFFIXES без параметров очищает список суффиксов. Здесь её использование совсем # необязательно и служит лишь для явного предоставления возможности сравнения обработки правил # вывода по умолчанию с ней и без неё .SUFFIXES: # добавляем в список расширение .asm, задающее некий приоритет и активирующий правило вывода # файлов с расширением .asm в файлы других расширений .SUFFIXES: .asm test: t1.txt t2.txt .asm.txt: copy /b $< $@ Однако, аналогичная запись правила для получения dll-ки: Код (Text): .SUFFIXES: .SUFFIXES: .obj .asm all: my.dll .obj.dll: $(LINKER) $(DLLOPTS) $(LINKFLAGS) $(OPTFLAGS) $@ .asm.obj:: $(AS) $(AFLAGS) /c $< вызывает у nmake "дезориентацию" - опция /p показывает наличие созданных правил, однако выполнение make-файла завершается выводом сообщения об ошибке: NMAKE : fatal error U1073: don't know how to make 'my.dll'
leviafan Код (Text): .SUFFIXES: .SUFFIXES: .dll .obj .asm all: my.dll .obj.dll: $(LINK) $< .asm.obj: $(AS) $< ГНУшный make работает, nmake валится, вероятно это баг. Еще раз предложу перейти на нормальный make (GNU, BSD), nmake - одна из ошибок мелкософта.
meduza, согласен с тобой, собственно и вопрос-то был для того, чтобы разобраться, кто допускает ошибку, я или мелкософтный nmake. GNU Make силён, да и написать свой, родной, не столь трудно, даже приятнее)) Хотелось верить, что они стараются соблюдать соглашения, принятые ими в своей же документации...
leviafan > твои аргументы и вывод ... абсолютно несостоятельны Чем, мой вывод "nmake не умеет ... Ему нужна помощь", отличается от твоего - "вызывает у nmake "дезориентацию""? > ты не знаешь предмета (и не умеешь читать документацию). Спорное утверждение. Например, мне не требуется помощь зала, чтобы, заставить nmake, собрать dll'ку. > Моя очередь ... можно использовать ... t2.dll: t2.obj Именно об этом я писал в #6, ты начал огрызаться и настаивать, что хочешь универсальных правил. ps > не слишком ли высокая у тебя самооценка??! Imo обсуждение этого выходит "за рамки данного обсуждения".
> Чем, мой вывод "nmake не умеет ... Ему нужна помощь", отличается от твоего - "вызывает у nmake "дезориентацию""? Вопрос задан некорректно, происходит подмена контекста... > "nmake не умеет ... Ему нужна помощь" умеет, описано в 13, но при этом глючит для некоторых расширений, например для dll. > Например, мне не требуется помощь зала, чтобы, заставить nmake, собрать dll'ку. И опять же, нигде не утверждалось, что Я не могу собрать dll'ку, речь шла о некорректной или плохо понятой работе правил вывода. > Именно об этом я писал в #6, ты начал огрызаться и настаивать, что хочешь универсальных правил. Так здесь не обсуждаются стандартные правила, т.к. они работают. >> не слишком ли высокая у тебя самооценка??! > Imo обсуждение этого выходит "за рамки данного обсуждения". Вопрос был вполне уместен, Imo не по-профессиональному ты рассуждаешь, нужно уважать собеседника, форум для общения специалистов, а не для того, чтобы показать, кто круче.
leviafan > умеет, описано в 13, но при этом глючит для некоторых расширений, например для dll. Начнем пополнять список "глючных" расширений? "Зашитого" правила .obj.exe нет. Повторяю последний раз: "nmake не умеет строить логические цепочки через цель". Хочешь заставить nmake получать из dll'ку из asm'а? Либо напиши правило .asm.dll, либо опиши зависимость как в #6. PS imho не тебе ссылаться на уважение.
