Go to the first, previous, next, last section, table of contents.


·ê ÀÛ¼ºÇϱâ

·êÀº ¸ÞÀÌÅ©ÆÄÀÏ¿¡ ³ªÅ¸³ª°í, ÀÌ°ÍÀº ¾ðÁ¦ ¾î¶»°Ô ÆÄÀÏÀ» ´Ù½Ã ¸¸µé °ÍÀΰ¡¿¡ °üÇØ ÀûÇô ÀÖ´Ù. ÀÌ ¸¸µå´Â ÆÄÀÏÀ» ±× ·êÀÇ Å¸°ÙÀ̶ó°í ÇÑ´Ù (´ëºÎºÐ ÇÑ °³ÀÇ ·ê¿¡ Ÿ°ÙÀº ÇÑ °³»ÓÀÌ´Ù). ·ê¿¡´Â ±× Ÿ°ÙÀÇ ÀÇÁ¸¼ºÀÎ ¶Ç´Ù¸¥ ÆÄÀϵéÀÌ ÀûÇô ÀÖ°í, ±× ·êÀÇ Å¸°ÙÀ» »õ·Î ¸¸µé°Å³ª ¾÷µ¥ÀÌÆ®ÇÒ ¶§ ¾²´Â ¸í·É¾î°¡ ÀûÇô ÀÖ´Ù.

±âº» °ñÀÌ °áÁ¤µÈ´Ù´Â Á¡À» Á¦¿ÜÇϸé, ·êÀÌ ¾²¿©Áø ¼ø¼­´Â ¾Æ¹«·± Àǹ̰¡ ¾ø´Ù: ±âº» °ñÀº °ñÀ» µû·Î ÁöÁ¤ÇÏÁö ¾Ê¾ÒÀ» °æ¿ì¿¡, make°¡ °í·ÁÇÏ°Ô µÇ´Â Ÿ°ÙÀÌ´Ù. ±âº» °ñÀº ù¹ø° ¸ÞÀÌÅ©ÆÄÀÏÀÇ Ã¹¹ø° ·ê¿¡ Àִ Ÿ°ÙÀÌ´Ù. ¸¸¾à ù¹ø° ·ê¿¡ ¿©·¯°³ÀÇ Å¸°ÙÀÌ ÀÖÀ¸¸é, ù¹ø° Ÿ°Ù¸¸ÀÌ ±âº»À¸·Î Ãë±ÞµÈ´Ù. ¿©±â¿¡ µÎ°¡Áö ¿¹¿Ü°¡ ÀÖ´Ù: Á¡À¸·Î ½ÃÀÛÇϴ Ÿ°ÙÀº ±× ¾È¿¡ ÇÑ°³ ÀÌ»óÀÇ ½½·¡½¬(`/')°¡ µé¾î ÀÖÁö ¾Ê´Â ÇÑ ±âº» °ñÀÌ ¾Æ´Ï´Ù; ¶Ç, ÆÐÅÏ ·êÀ» Á¤ÀÇÇϴ Ÿ°ÙÀº ±âº» °ñ¿¡ ¿µÇâÀ» ÁÖÁö ¸øÇÑ´Ù. (See section Defining and Redefining Pattern Rules.)

±×·¯¹Ç·Î, ¿ì¸®´Â º¸Åë ù¹ø° ·êÀÌ Àüü ÇÁ·Î±×·¥, ȤÀº ±× ¸ÞÀÌÅ©ÆÄÀÏ¿¡ ¾²¿©Áø ¸ðµç ÇÁ·Î±×·¥À» ÄÄÆÄÀÏÇϵµ·Ï ÀÛ¼ºÇÑ´Ù (´ëºÎºÐ `all'À̶ó°í Çϴ Ÿ°Ù). See section Arguments to Specify the Goals.

·ê ¹®¹ý

ÀϹÝÀûÀ¸·Î, ·êÀº ´ÙÀ½°ú °°Àº ¸ð¾çÀÌ´Ù:

Ÿ°Ùµé : ÀÇÁ¸¼ºµé
        ¸í·É¾î
        ...

ȤÀº ´ÙÀ½°ú °°Àº ¸ð¾çÀÌ´Ù:

Ÿ°Ùµé : ÀÇÁ¸¼ºµé ; ¸í·É¾î
        ¸í·É¾î
        ...

Ÿ°ÙµéÀº °ø¹éÀ¸·Î ±¸ºÐµÈ ÆÄÀÏ À̸§µéÀÌ´Ù. ¿ÍÀϵåÄ«µå ¹®ÀÚµµ »ç¿ëµÉ ¼ö ÀÖ°í (see section ÆÄÀÏÀ̸§À¸·Î ¿ÍÀϵåÄ«µå ¹®ÀÚ »ç¿ëÇϱâ) `a(m)'Àº ¾ÆÄ«À̺ê ÆÄÀÏ a ¾ÈÀÇ ¸â¹ö m¸¦ ¶æÇÑ´Ù (see section Archive Members as Targets). º¸Åë ·ê¿¡´Â ÇÑ°³ÀÇ Å¸°Ù¸¸ÀÌ ÀÖÁö¸¸, µÎ°³ ÀÌ»óÀÇ Å¸°ÙÀ» ½á¾ß ÇÒ ÇÊ¿äµµ »ý±ä´Ù (see section Multiple Targets in a Rule).

¸í·É¾î ÁÙÀº ÅÇ ¹®ÀÚ·Î ½ÃÀÛÇÑ´Ù. ù¹ø° ¸í·É¾î°¡ ÀÇÁ¸¼º ´ÙÀ½¿¡ ¿À´Â ÁÙ¿¡ ÅÇ ¹®ÀÚ¿Í ÇÔ²² ³ªÅ¸³¯ ¼ö ÀÖ°í, ȤÀº °°Àº ÁÙ¿¡ ¼¼¹ÌÄÝ·Ð ´ÙÀ½¿¡ ³ªÅ¸³¯ ¼ö ÀÖ´Ù. µÑ Áß¿¡ ¾î¶² ¹æ¹ýÀÌµç °£¿¡, ±× È¿°ú´Â µ¿ÀÏÇÏ´Ù. See section Writing the Commands in Rules.

´Þ·¯ Ç¥½Ã´Â º¯¼ö ÂüÁ¶¸¦ ½ÃÀÛÇÒ ¶§ ¾²À̱⠶§¹®¿¡, Á¤¸»·Î ·ê¿¡ ´Þ·¯ Ç¥½Ã¸¦ ¾²·Á¸é `$$'ó·³ ´Þ·¯ ¹®ÀÚ¸¦ µÎ°³ ½á¾ß ÇÑ´Ù (see section How to Use Variables). ¹é½½·¡½¬ ´ÙÀ½¿¡ ÁÙÀ» ¹Ù²Ù´Â ¹æ¹ýÀ¸·Î ±ä ÁÙÀ» ¿©·¯°³·Î ÂÉ°¶ ¼ö ÀÖÁö¸¸, ±×·² ÇÊ¿ä´Â ¾ø´Ù. make´Â ¸ÞÀÌÅ© ÆÄÀÏ¿¡ ÀÖ´Â ÁÙÀÇ ±æÀÌ¿¡ Á¦ÇÑÀ» µÎÁö ¾Ê±â ¶§¹®ÀÌ´Ù.

·êÀº make¿¡°Ô µÎ°¡Áö »ç½ÇÀ» ¾Ë·ÁÁØ´Ù: ¾ðÁ¦ Ÿ°ÙÀ» ¾÷µ¥ÀÌÆ®ÇØ¾ß Çϴ°¡, ±×¸®°í ¾÷µ¥ÀÌÆ®ÇØ¾ß ÇÒ ¶§ ¾î¶»°Ô ±× Ÿ°ÙÀ» ¾÷µ¥ÀÌÆ®ÇØ¾ß Çϴ°¡ÀÌ´Ù.

¾÷µ¥ÀÌÆ®ÇØ¾ß µÈ´Ù´Â °É ÆÇ´ÜÇÏ´Â ±âÁ¸Àº ÀÇÁ¸¼º¿¡¼­ ÁöÁ¤µÇ´Âµ¥, ÀÇÁ¸¼ºÀº °ø¹éÀ¸·Î ±¸ºÐµÈ ÆÄÀÏ À̸§À¸·Î ÀÌ·ç¾îÁ® ÀÖ´Ù. (¿ÍÀϵåÄ«µå¿Í ¾ÆÄ«ÀÌºê ¸â¹ö¸¦ (see section Using make to Update Archive Files) ¿©±â¿¡µµ ¾µ ¼ö ÀÖ´Ù.) Ÿ°ÙÀº Á¸ÀçÇÏÁö ¾Ê°Å³ª ÀÇÁ¸¼ºÁßÀÇ ¾î´À Çϳªº¸´Ùµµ Ÿ°ÙÀÌ ´õ ¿À·¡µÈ °æ¿ì¿¡ (ÃÖ±Ù¿¡ ¼öÁ¤µÈ ½Ã°¢À» ºñ±³Çؼ­) ±× Ÿ°ÙÀ» ¾÷µ¥ÀÌÆ®ÇØ¾ß ÇÑ´Ù. Ÿ°Ù ÆÄÀÏÀÇ ³»¿ëÀº ÀÇÁ¸¼º¿¡ µé¾î ÀÖ´Â Á¤º¸¿¡ ±âÃÊÇؼ­ ¸¸µé¾î Áø´Ù´Â »ç½Ç¿¡ ±âÃÊÇÑ °ÍÀ̹ǷÎ, ÀÇÁ¸¼ºÁß¿¡ Çϳª¶óµµ ¹Ù²î¸é ±âÁ¸ÀÇ Å¸°Ù ÆÄÀÏÀÇ ³»¿ëÀº ´õ ÀÌ»ó ¿Ã¹Ù¸¥ ³»¿ëÀÌ ¾Æ´Ï´Ù.

¾÷µ¥ÀÌÆ®ÇÏ´Â ¹æ¹ýÀº ¸í·É¾î¿¡ ÁöÁ¤µÇ¾î ÀÖ´Ù. ÀÌ ¸í·É¾î ÁÙÀº ¼Ð¿¡ ÀÇÇØ (º¸Åë `sh') ½ÇÇàµÇÁö¸¸, ¸î°¡Áö Ãß°¡ÀûÀÎ ±â´ÉÀÌ ÀÖ´Ù (see section Writing the Commands in Rules).

ÆÄÀÏÀ̸§À¸·Î ¿ÍÀϵåÄ«µå ¹®ÀÚ »ç¿ëÇϱâ

ÇÑ°³ÀÇ ÆÄÀÏ À̸§Àº ¿ÍÀϵåÄ«µå ¹®ÀÚ¸¦ »ç¿ëÇؼ­ ¿©·¯°³ÀÇ ÆÄÀÏÀ» ÁöÁ¤ÇÒ ¼ö ÀÖ´Ù. makeÀÇ ¿ÍÀϵåÄ«µå ¹®ÀÚ´Â `*', `?' ±×¸®°í `[...]'ÀÌ°í, º» ¼Ð(Bourne shell)ÀÇ ¿ÍÀϵå Ä«µå¿Í µ¿ÀÏÇÏ´Ù. ¿¹¸¦ µé¾î, `*.c'´Â ÆÄÀÏ À̸§ÀÌ `.c'·Î ³¡³ª´Â (ÇöÀç µð·ºÅ丮 ¾ÈÀÇ) ¸ðµç ÆÄÀϵéÀ» ³ªÅ¸³½´Ù.

ÆÄÀÏÀ̸§ ¸Ç ¾ÕÀÇ `~' ¹®ÀÚµµ Ưº°ÇÑ Àǹ̸¦ °®°í ÀÖ´Ù. ´Üµ¶À¸·Î ¾²À̰ųª, `~' ´ÙÀ½¿¡ ½½·¡½¬°¡ ¿À¸é Ȩ µð·ºÅ丮¸¦ ³ªÅ¸³½´Ù. ¿¹¸¦ µé¾î `~/bin'Àº `/home/you/bin'À¸·Î È®ÀåµÈ´Ù. `~' ´ÙÀ½¿¡ ´Ü¾î°¡ ¿À¸é, ±× ¹®ÀÚ¿­Àº ±× ´Ü¾î¿Í °°Àº À̸§ÀÇ »ç¿ëÀÚÀÇ È¨ µð·ºÅ丮¸¦ ¶æÇÑ´Ù. ¿¹¸¦ µé¾î `~john/bin'Àº `/home/john/bin'À¸·Î È®ÀåµÈ´Ù. °¢ »ç¿ëÀÚ¿¡ ´ëÇÑ È¨ µð·ºÅ丮°¡ ¾ø´Â ½Ã½ºÅÛ¿¡¼­´Â (MS-DOS³ª MS-Windows¿Í °°ÀÌ), ÀÌ ±â´ÉÀº HOME ȯ°æ º¯¼ö °ªÀ» ÅëÇØ °¡»óÀûÀ¸·Î µ¿ÀÛÇÑ´Ù.

¿ÍÀϵåÄ«µå È®ÀåÀº Ÿ°Ù, ÀÇÁ¸¼º, ±×¸®°í ¸í·É¾î¿¡¼­ ÀÚµ¿À¸·Î ÀϾ´Ù (¸í·É¾î¿¡¼­´Â ¼ÐÀÌ È®ÀåÇÑ´Ù). ´Ù¸¥ ºÎºÐ¿¡¼­´Â, ¿ÍÀϵåÄ«µå È®ÀåÀº ¸í½ÃÀûÀ¸·Î wildcard ÇÔ¼ö¸¦ »ç¿ëÇÑ °æ¿ì¿¡¸¸ ÀϾ´Ù.

¿ÍÀϵå Ä«µåÀÇ Æ¯º°ÇÑ ±â´ÉÀº ¿ÍÀϵåÄ«µå ¹®ÀÚ ¾Õ¿¡ ¹é½½·¡½¬¸¦ ¾²¸é »ç¿ëÇÏÁö ¾ÊÀ» ¼ö ÀÖ´Ù. Áï, `foo\*bar'´Â `foo', º°Ç¥, ±×¸®°í `bar'¶ó´Â À̸§ÀÇ ÆÄÀÏÀ» ¶æÇÑ´Ù.

¿ÍÀϵåÄ«µå ¿¹Á¦

¿ÍÀϵåÄ«µå´Â ·êÀÇ ¸í·É¾î¿¡¼­ »ç¿ëµÉ ¼ö Àִµ¥, ¿©±â¼­´Â ¼Ð¿¡ ÀÇÇؼ­ È®ÀåµÈ´Ù. ¿¹¸¦ µé¾î, ´ÙÀ½Àº ¸ðµç ¿ÀºêÁ§Æ® ÆÄÀÏÀ» Áö¿ì´Â ·êÀÌ´Ù:

clean:
        rm -f *.o

¿ÍÀϵåÄ«µå´Â ·êÀÇ ÀÇÁ¸¼º¿¡¼­µµ À¯¿ëÇÏ´Ù. ¸ÞÀÌÅ© ÆÄÀÏ¿¡ ´ÙÀ½ ·êÀ» ¾²¸é, `make print'´Â ¸¶Áö¸·¿¡ ÇÁ¸°Æ®ÇÑ ÀÌÈÄ·Î ¹Ù²ï ¸ðµç `.c' ÆÄÀÏÀ» ÀμâÇÑ´Ù.

print: *.c
        lpr -p $?
        touch print

ÀÌ ·êÀº `print'¸¦ ºñ¾î Àִ Ÿ°Ù ÆÄÀÏ·Î »ç¿ëÇÑ´Ù; section Empty Target Files to Record Events. (ÀÚµ¿ º¯¼ö `$?'´Â ¹Ù²ï ÆÄÀϵ鸸À» ÀμâÇÏ´Â µ¥ »ç¿ëµÈ´Ù; section Automatic Variables.)

¿ÍÀϵåÄ«µå È®ÀåÀº º¯¼ö¸¦ Á¤ÀÇÇÒ ¶§´Â ÀϾÁö ¾Ê´Â´Ù. Áï, ´ÙÀ½°ú °°ÀÌ ¾²¸é:

objects = *.o

º¯¼ö objectsÀÇ °ªÀº ½ÇÁ¦ `*.o'¶ó´Â ¹®ÀÚ¿­ÀÌ´Ù. ÇÏÁö¸¸, objectsÀÇ °ªÀ» Ÿ°Ù, ÀÇÁ¸¼º, ȤÀº ¸í·É¾î¿¡¼­ »ç¿ëÇϸé, ¿ÍÀϵåÄ«µå È®ÀåÀÌ ±× ¶§ ÀϾ´Ù. objectsÀÇ °ªÀ¸·Î È®ÀåµÈ °ªÀ» ³ÖÀ¸·Á¸é, ´ÙÀ½°ú °°ÀÌ »ç¿ëÇÑ´Ù:

objects := $(wildcard *.o)

See section wildcard ÇÔ¼ö.

¿ÍÀϵåÄ«µå¸¦ »ç¿ëÇÒ ¶§ ÇÔÁ¤

´ÙÀ½Àº ¿ÍÀϵåÄ«µå È®ÀåÀ» »ç¿ëÇÏ´Â ´Ü¼øÇÑ ¹æ¹ýÀ¸·Î, ÀǵµÇÑ ´ë·Î µ¿ÀÛÇÏÁö ¾Ê´Â´Ù. ½ÇÇà ÆÄÀÏ `foo'°¡ µð·ºÅ丮 ¾ÈÀÇ ¸ðµç ¿ÀºêÁ§Æ® ÆÄÀÏ¿¡¼­ºÎÅÍ ¸¸µé¾î Áø´Ù°í °¡Á¤ÇÏ°í, ´ÙÀ½°ú °°ÀÌ ¾´´Ù:

objects = *.o

foo : $(objects)
        cc -o foo $(CFLAGS) $(objects)

objectsÀÇ °ªÀº `*.o'¶ó´Â ½ÇÁ¦ ¹®ÀÚ¿­ÀÌ´Ù. ¿ÍÀϵå Ä«µå È®ÀåÀº `foo'¸¦ À§ÇÑ ·ê¿¡¼­ ÀϾ¹Ç·Î, Á¸ÀçÇÏ´Â ¸ðµç `.o' ÆÄÀÏÀÌ `foo'ÀÇ ÀÇÁ¸¼ºÀÌ µÇ°í, ÇÊ¿äÇÑ °æ¿ì ÀçÄÄÆÄÀÏÇØ¾ß ÇÑ´Ù.

ÇÏÁö¸¸ ¸ðµç `.o' ÆÄÀÏÀ» Áö¿ö¹ö·È´Ù¸é ¾î¶»°Ô µÇ´Â°¡? ¿ÍÀϵåÄ«µå°¡ ¾Æ¹«·± ÆÄÀÏ°úµµ ¸ÂÁö ¾Ê´Â´Ù¸é, ±×´ë·Î ³²¾Æ ÀÖ°Ô µÇ°í, `foo'´Â `*.o'¶ó´Â À߸øµÈ À̸§ÀÇ ÆÄÀÏ¿¡ ÀÇÁ¸ÇÏ°Ô µÈ´Ù. ±×·± ÆÄÀÏÀº ¾øÀ» °ÍÀ̹ǷÎ, make´Â ¾î¶»°Ô `*.o' ÆÄÀÏÀ» ¸¸µéÁö ¸ð¸£°Ú´Ù´Â ¸»À» Çϸ鼭 ¿À·ù¸¦ ³¾ °ÍÀÌ´Ù. ÀÌ°ÍÀº ¿øÇÏ´ø ¹Ù°¡ ¾Æ´Ï´Ù!

½ÇÁ¦·Î ¿ÍÀϵåÄ«µå È®Àå¿¡¼­ ¿øÇÏ´Â °á°ú¸¦ ¾òÀ» ¼öµµ ÀÖÁö¸¸, wildcard ÇÔ¼ö¿Í ¹®ÀÚ¿­ ġȯ°ú °°Àº Á»´õ ¶È¶ÈÇÑ Å×Å©´ÐÀÌ ÇÊ¿äÇÏ´Ù. ÀÌ Å×Å©´ÐµéÀº ´ÙÀ½ Àý¿¡ ¼³¸íµÈ´Ù.

Microsoft ¿î¿µ üÁ¦´Â (MS-DOS¿Í MS-Windows) ´ÙÀ½°ú °°ÀÌ °æ·Î¸í¿¡¼­ µð·ºÅ丮¸¦ ±¸ºÐÇÏ´Â µ¥ ¹é½½·¡½¬¸¦ »ç¿ëÇÑ´Ù:

  c:\foo\bar\baz.c

ÀÌ°ÍÀº À¯´Ð½º ½ºÅ¸ÀÏ·Î `c:/foo/bar/baz.c'¿Í °°´Ù (`c:'¶ó´Â ºÎºÐÀº ¼ÒÀ§ ¸»ÇÏ´Â µå¶óÀÌºê ¹®ÀÚÀÌ´Ù). make°¡ ÀÌ·¯ÇÑ ½Ã½ºÅÛ¿¡¼­ µ¿ÀÛÇÒ ¶§, °æ·Î ¸í¿¡¼­ À¯´Ð½º ½ºÅ¸ÀÏÀÇ ½½·¡½¬ ¹®ÀÚ´Â ¹°·Ð ¹é½½·¡½¬ ¹®ÀÚµµ Áö¿øÇÑ´Ù. ÇÏÁö¸¸, ¿ÍÀϵåÄ«µå¿¡¼­´Â Áö¿øÇÏÁö ¾Ê´Â´Ù. ¿ÍÀϵåÄ«µå¿¡¼­ ¹é½½·¡½¬´Â ¾î¶² ¹®ÀÚ¸¦ ³ªÅ¸³»´Â À̽ºÄÉÀÌÇÁ ¹®ÀÚÀÌ´Ù. Áï, ÀÌ·¯ÇÑ °æ¿ì¿¡´Â À¯´Ð½º ½ºÅ¸ÀÏÀÇ ½½·¡½¬¸¦ »ç¿ëÇؾ߸¸ ÇÑ´Ù.

wildcard ÇÔ¼ö

¿ÍÀϵåÄ«µå È®ÀåÀº ·ê¿¡¼­ ÀÚµ¿À¸·Î ÀϾ´Ù. ÇÏÁö¸¸ ¿ÍÀϵåÄ«µå È®ÀåÀº º¯¼ö °ªÀ» °áÁ¤ÇÏ´Â °÷À̳ª, ÇÔ¼öÀÇ ÀÎÀÚ ¾È¿¡¼­´Â ÀϾÁö ¾Ê´Â´Ù. ÀÌ·¯ÇÑ Àå¼Ò¿¡¼­ ¿ÍÀϵåÄ«µå È®ÀåÀ» ÇÏ°í ½ÍÀ¸¸é, wildcard ÇÔ¼ö¸¦ ´ÙÀ½°ú °°ÀÌ »ç¿ëÇØ¾ß ÇÑ´Ù:

$(wildcard ÆÐÅÏ...)

¸ÞÀÌÅ©ÆÄÀÏÀÇ ¾îµð¿¡¼­³ª »ç¿ëµÉ ¼ö ÀÖ´Â, ÀÌ ¹®ÀÚ¿­Àº ÁÖ¾îÁø ÆÄÀÏÀ̸§ ÆÐÅÏ¿¡ ¸Â´Â Á¸ÀçÇÏ´Â ÆÄÀϵéÀÇ À̸§µéÀ» °ø¹éÀ¸·Î ±¸ºÐÇÑ ¸®½ºÆ®·Î ¹Ù²Ù´Ï´Ù. ¾î¶² Á¸ÀçÇÏ´Â ÆÄÀÏ À̸§µµ ±× ÆÐÅÏ°ú ¸ÂÁö ¾ÊÀ¸¸é, ±× ±× ÆÐÅÏÀº wildcard ÇÔ¼öÀÇ °á°ú¿¡¼­ Á¦¿ÜµÈ´Ù. ÀÌ°ÍÀº ·ê¿¡¼­ ¿ÍÀϵåÄ«µå°¡ ¸ÂÁö ¾Ê¾ÒÀ» °æ¿ìÀÇ µ¿ÀÛ°ú´Â ´Ù¸£´Ù´Â Á¡¿¡ ÁÖÀÇÇÑ´Ù. ·ê¿¡¼­´Â ¸ÂÁö ¾Ê´Â ¿ÍÀϵåÄ«µå´Â ¹«½ÃµÇÁö ¾Ê°í, ±× ÆÐÅÏÀÌ ±×´ë·Î »ç¿ëµÈ´Ù (see section ¿ÍÀϵåÄ«µå¸¦ »ç¿ëÇÒ ¶§ ÇÔÁ¤).

wildcard ÇÔ¼öÀÇ ÇÑ°¡Áö »ç¿ë¿¹´Â µð·ºÅ丮 ³»ÀÇ ¸ðµç C ¼Ò½º ÆÄÀÏÀÇ ¸®½ºÆ®¸¦ ¾ò´Â °ÍÀÌ´Ù. ´ÙÀ½°ú °°ÀÌ ÇÑ´Ù:

$(wildcard *.c)

±× °á°ú¿¡¼­ `.c' Á¢¹Ì¾î¸¦ `.o'·Î ¹Ù²Ù¸é, C ¼Ò½º ÆÄÀÏÀÇ ¸®½ºÆ®¸¦ ¿ÀºêÁ§Æ® ÆÄÀÏÀÇ ¸®½ºÆ®·Î ¹Ù²Ü ¼ö ÀÖ´Ù. ´ÙÀ½°ú °°ÀÌ ÇÑ´Ù:

$(patsubst %.c,%.o,$(wildcard *.c))

(¿©±â¼­ patsubst¶ó´Â ¶Ç´Ù¸¥ ÇÔ¼ö¸¦ »ç¿ëÇß´Ù. See section Functions for String Substitution and Analysis.)

Áï, µð·ºÅ丮 ³»ÀÇ C ¼Ò½º ÆÄÀÏÀ» ÄÄÆÄÀÏÇؼ­ ¸µÅ©ÇÏ´Â ¸ÞÀÌÅ© ÆÄÀÏÀº ´ÙÀ½°ú °°´Ù:

objects := $(patsubst %.c,%.o,$(wildcard *.c))

foo : $(objects)
        cc -o foo $(objects)

(À§ÀÇ ¸ÞÀÌÅ© ÆÄÀÏÀº C ÇÁ·Î±×·¥À» ÄÄÆÄÀÏÇÏ´Â ¾Ï¹¬ÀûÀÎ ·êÀ» ÀÌ¿ëÇÏ°í ÀÖÀ¸¹Ç·Î, ÀÌ C ÆÄÀϵéÀ» ÄÄÆÄÀÏÇÏ´Â ¸í½ÃÀûÀÎ ·êÀ» ÀÛ¼ºÇÒ ÇÊ¿ä´Â ¾ø´Ù. `='ÀÇ º¯ÇüÀÎ `:='¿¡ ´ëÇÑ ¼³¸íÀº See section The Two Flavors of Variables.)

ÀÇÁ¸¼ºÀÌ µé¾î ÀÖ´Â µð·ºÅ丮 ã±â

Å« ½Ã½ºÅÛ¿¡¼­´Â, ¼Ò½º ÆÄÀϵéÀ» ¹ÙÀ̳ʸ®¿Í´Â º°µµÀÇ µð·ºÅ丮¿¡ ³Ö´ÂÂÊÀÌ ÁÁ´Ù. makeÀÇ µð·ºÅ丮 ã±â(directory search) ±â´ÉÀº ÀÇÁ¸¼ºÀ» ãÀ» ¶§ ÀÚµ¿À¸·Î ¿©·¯°³ÀÇ µð·ºÅ丮¸¦ »ìÆ캸´Â ¹æ¹ýÀ¸·Î ÀÌ·¯ÇÑ ±â´ÉÀ» ±¸ÇöÇÑ´Ù. ¿©·¯ °³ÀÇ µð·ºÅ丮¿¡ ÆÄÀϵéÀ» ºÐ»êÇÒ ¶§, °¢ ·êÀ» ¹Ù²Ü ÇÊ¿ä¾øÀÌ, ã±â °æ·Î¸¸ ¹Ù²Ù¸é µÈ´Ù.

VPATH: ¸ðµç ÀÇÁ¸¼º¿¡ ´ëÇÑ Ã£±â °æ·Î

make º¯¼ö VPATHÀÇ °ªÀº make°¡ ã¾Æ¾ß ÇÒ µð·ºÅ丮µéÀÇ ¸®½ºÆ®¸¦ ÁöÁ¤ÇÑ´Ù. °¡Àå ¸¹ÀÌ ¾²ÀÌ´Â °ÍÀ¸·Î, ¿©±â¿¡ ÀÖ´Â µð·ºÅ丮µéÀº ÇöÀç µð·ºÅ丮¿¡ ¾ø´Â ÀÇÁ¸¼º ÆÄÀÏÀÌ µé¾î ÀÖÀ» ¼ö ÀÖ´Ù; ÇÏÁö¸¸, VPATH´Â ·êÀÇ Å¸°ÙÀº ¹°·ÐÀÌ°í make°¡ Ãë±ÞÇÏ´Â ¸ðµç ÆÄÀϵéÀ» ã´Â µ¥ ¾²ÀδÙ.

Áï, Ÿ°ÙÀ̳ª ÀÇÁ¸¼ºÀ¸·Î ¾²¿© ÀÖ´Â ÆÄÀÏÀÌ ÇöÀç µð·ºÅ丮¿¡ ¾øÀ¸¸é, make´Â VPATH¿¡ ¾²ÀÎ µð·ºÅ丮¿¡¼­ ±× À̸§ÀÇ ÆÄÀÏÀ» ã´Â´Ù. ÆÄÀÏÀÌ ÀÌ µð·ºÅ丮µé Áß Çϳª¿¡¼­ ¹ß°ßµÇ¸é, ±× ÆÄÀÏÀÌ ±× ÀÇÁ¸¼ºÀÌ µÈ´Ù (¾Æ·¡ ÂüÁ¶). ±×·¯¸é ·ê¿¡¼­ ¸¶Ä¡ ÇöÀç µð·ºÅ丮¿¡ ÀÖ´Â ÆÄÀÏó·³ ÆÄÀÏ À̸§À» ÀÇÁ¸¼ºÀ¸·Î ¾µ ¼ö ÀÖ´Ù. See section µð·ºÅ丮 ã±â¿Í ÇÔ²² ¼Ð ¸í·É »ç¿ëÇϱâ.

VPATH º¯¼ö¿¡¼­, µð·ºÅ丮 À̸§Àº ÄÝ·ÐÀ̳ª °ø¹éÀ¸·Î ±¸ºÐÇÑ´Ù. µð·ºÅ丮°¡ ¿­°ÅµÈ ¼ø¼­´ë·Î make´Â ÆÄÀÏÀ» ã´Â´Ù. (MS-DOS¿Í MS-Windows¿¡¼­, VPATH¿¡¼­ µð·ºÅ丮 À̸§À» ±¸ºÐÇÏ´Â µ¥ ¼¼¹Ì ÄÝ·ÐÀÌ ¾²ÀδÙ. ¿Ö³ÄÇϸé ÀÌ ½Ã½ºÅÛ¿¡¼­´Â °æ·Î¸í ³»¿¡¼­ µå¶óÀÌºê ¹®ÀÚ ´ÙÀ½¿¡ ÄÝ·ÐÀÌ »ç¿ëµÇ±â ¶§¹®ÀÌ´Ù.)

¿¹¸¦ µé¾î,

VPATH = src:../headers

´Â `src'¿Í `../headers', µÎ°³ÀÇ µð·ºÅ丮¸¦ ÁöÁ¤ÇÏ°í, make´Â ÀÌ ¼ø¼­´ë·Î ÆÄÀÏÀ» ã´Â´Ù.

VPATHÀÇ °ª¿¡ µû¶ó, ´ÙÀ½ ·ê,

foo.o : foo.c

Àº ´ÙÀ½°ú °°ÀÌ ¾²¿©Áø °Í°ú °°´Ù:

foo.o : src/foo.c

À̶§ `foo.c'°¡ ÇöÀç µð·ºÅ丮¿¡ ¾ø°í, `src' µð·ºÅ丮¿¡ ÀÖ´Ù°í °¡Á¤ÇÑ´Ù

The vpath Directive

VPATH º¯¼ö¿Í ºñ½ÁÇÏÁö¸¸, º¸´Ù ´õ ¼±ÅÃÀûÀÎ °ÍÃ÷·Î vpath Áö½Ã¾î°¡ ÀÖ´Ù (¼Ò¹®ÀÚ¿¡ ÁÖÀÇ). vpath´Â ¾î¶² ƯÁ¤ Á¾·ùÀÇ ÆÄÀÏ À̸§µé(¾î¶² ÆÐÅÏ¿¡ ¸Â´Â ÆÄÀÏ À̸§)¿¡ ´ëÇؼ­ ãÀ» °æ·Î¸¦ ÁöÁ¤ÇÑ´Ù. Áï, ¾î¶² Á¾·ùÀÇ ÆÄÀÏ À̸§¿¡ ´ëÇؼ­ ã±â °æ·Î¸¦ ÁöÁ¤ÇÏ°í, ¶Ç ´Ù¸¥ ÆÄÀÏ À̸§Àº ¶Ç ´Ù¸¥ ã±â µð·ºÅ丮¸¦ ÁöÁ¤ÇÒ ¼ö ÀÖ´Ù.

vpath Áö½Ã¾î´Â ¼¼°¡Áö ÇüÅ°¡ ÀÖ´Ù:

vpath ÆÐÅÏ µð·ºÅ丮µé
ÆÐÅÏ¿¡ ¸Â´Â ÆÄÀÏ À̸§µé¿¡ ´ëÇؼ­ µð·ºÅ丮µé ã±â °æ·Î¸¦ ÁöÁ¤ÇÑ´Ù. ã±â °æ·ÎÀÎ µð·ºÅ丮µéÀº ãÀ» µð·ºÅ丮µéÀÇ ¸®½ºÆ®·Î, VPATH º¯¼ö¿Í ¸¶Âù°¡Áö·Î ÄÝ·Ð(MS-DOS¿Í MS-Windows¿¡¼±´À ¼¼¹ÌÄÝ·Ð)À̳ª °ø¹éÀ¸·Î ±¸ºÐÇÑ´Ù.
vpath ÆÐÅÏ
ÆÐÅÏ°ú °ü·ÃµÈ ã±â °æ·Î¸¦ Áö¿î´Ù.
vpath
vpath Áö½Ã¾î·Î Àü¿¡ ÁöÁ¤µÈ ¸ðµç ã±â °æ·Î¸¦ Áö¿î´Ù.

vpathÀÇ ÆÐÅÏÀº `%' ¹®ÀÚ°¡ µé¾î ÀÖ´Â ¹®ÀÚ¿­ÀÌ´Ù. ÀÌ ¹®ÀÚ¿­Àº ã°íÀÚ ÇÏ´Â ÀÇÁ¸¼ºÀÇ ÆÄÀÏ À̸§°ú ¸Â¾Æ¾ß ÇÏ°í, `%' ¹®ÀÚ´Â ºó ¹®ÀÚ¿­, ȤÀº ¸ðµç Á¾·ùÀÇ ¹®ÀÚ¿­¿¡ ÇØ´çµÈ´Ù (ÆÐÅÏ ·ê°ú ¸¶Âù°¡ÁöÀÌ´Ù; see section Defining and Redefining Pattern Rules). ¿¹¸¦ µé¾î, %.h´Â .h·Î ³¡³ª´Â ¸ðµç ÆÄÀÏ¿¡ ÇØ´çµÈ´Ù. (`%'°¡ ¾øÀ¸¸é, ÆÐÅÏÀº Á¤È®È÷ °°Àº ÀÇÁ¸¼º¿¡ ÇØ´çµÇ´Âµ¥, ÀÌ°Ç ´ëºÎºÐÀÇ °æ¿ì ¾µ¸ð°¡ ¾ø´Ù.)

vpath Áö½Ã¾î ÆÐÅÏÀÇ `%' ¹®ÀÚ´Â ¾Õ¿¡ ¹é½½·¡½¬(`\')¸¦ ºÙ¿©¼­ Á÷Á¢ `%' ¹®ÀÚ¸¦ ¾µ ¼ö ÀÖ´Ù. `%' ¹®ÀÚ¸¦ ¾µ ¶§ »ç¿ëÇÏ´Â ¹é½½·¡½¬´Â ¹é½½·¡½¬¸¦ ¿©·¯°³ ½á¼­ Á÷Á¢ ¹é½½·¡½¬ ¹®ÀÚ¸¦ ¾µ ¼ö ÀÖ´Ù. `%' ¹®ÀÚ¸¦ ¾²´Â ¹é½½·¡½¬³ª ±× ¿ÜÀǹ齽·¡½¬´Â ÆÄÀÏ À̸§°ú ºñ±³µÇ±â Àü¿¡ »ç¶óÁø´Ù. `%' ¹®ÀÚ¸¦ Á÷Á¢ ¾²´Âµ¥ ¾²ÀÏ À§ÇèÀÌ ¾ø´Â ¹é½½·¡½¬´Â Æò¿ÂÇÑ »óÅ·Π³²°ÜµÐ´Ù.

¾î¶² ÀÇÁ¸¼ºÀÌ ÇöÀç µð·ºÅ丮¿¡ ¾ø°í, vpath Áö½Ã¾î ³»ÀÇ ÆÐÅÏÀÌ ±× ÀÇÁ¸¼º ÆÄÀÏÀÇ À̸§°ú ÀÏÄ¡ÇÑ´Ù¸é, VPATH º¯¼ö¿Í ¸¶Âù°¡Áö·Î vpath Áö½Ã¾î ³»ÀÇ µð·ºÅ丮µé¿¡¼­ ÆÄÀÏÀ» ã´Â´Ù.

¿¹¸¦ µé¾î,

vpath %.h ../headers

¶ó°í ¾²¸é make´Â `.h'·Î ³¡³ª´Â ¸ðµç ÀÇÁ¸¼º¿¡ ´ëÇØ, ÇöÀç µð·ºÅ丮 ¾øÀ¸¸é `../headers' µð·ºÅ丮¿¡¼­ ã´Â´Ù.

¿©·¯°³ÀÇ vpath ÆÐÅÏÀÌ ÇØ´ç ÀÇÁ¸¼º ÆÄÀÏÀ̸§°ú ÀÏÄ¡ÇÑ´Ù¸é, make´Â °¢°¢ÀÇ ÀÏÄ¡ÇÏ´Â vpath Áö½Ã¾î¸¦ Çϳª¾¿ Çϳª¾¿ ó¸®Çؼ­, °¢ Áö½Ã¾î¿¡ ¾²¿© ÀÖ´Â ¸ðµç µð·ºÅ丮¿¡¼­ ±× ÆÄÀÏÀ» ã´Â´Ù. make´Â ¿©·¯°³ÀÇ vpath Áö½Ã¾î°¡ ÀÖÀ» ¶§ ¸ÞÀÌÅ©ÆÄÀÏ¿¡ ³ªÅ¸³­ ¼ø¼­·Î ó¸®ÇÑ´Ù; °°Àº ÆÐÅÏ¿¡ ´ëÇØ ¿©·¯°³ÀÇ Áö½Ã¾î¸¦ ½áµµ ±× Áö½Ã¾îµéÀº ¼­·Î µ¶¸³ÀûÀÌ´Ù.

Áï,

vpath %.c foo
vpath %   blish
vpath %.c bar

¶ó°í ¾²¸é `.c'·Î ³¡³ª´Â ÆÄÀÏÀ», `foo', `blish', ±×¸®°í `bar'ÀÇ ¼ø¼­´ë·Î ã´Â´Ù. ÇÑÆí,

vpath %.c foo:bar
vpath %   blish

´Â `.c'·Î ³¡³ª´Â ÆÄÀÏÀ» `foo', `bar', ±×¸®°í `blish'ÀÇ ¼ø¼­´ë·Î ã´Â´Ù.

How Directory Searches are Performed

¾î¶² ÀÇÁ¸¼ºÀÌ µð·ºÅ丮 ã±â¸¦ ÅëÇØ ¹ß°ßµÇ¾úÀ» ¶§, ±× ã±â ¹æ¹ý¿¡ °ü°è¾øÀÌ (ÀϹÝÀûÀÎ ¹æ¹ýÀÌµç ¼±ÅÃÀûÀÎ ¹æ¹ýÀ̵ç), ãÀº °æ·Î¸íÀº make°¡ ½ÇÁ¦·Î ÀÇÁ¸¼º ¸®½ºÆ®¿¡ Á¦°øÇØ ÁÖ´Â °æ·Î¸íÀÌ ¾Æ´Ò ¼öµµ ÀÖ´Ù. ¾î¶² °æ¿ì¿¡´Â µð·ºÅ丮 ã±â¸¦ ÅëÇØ ¹ß°ßµÈ °æ·Î°¡ ¾ø¾îÁú ¼öµµ ÀÖ´Ù.

make°¡ µð·ºÅ丮 ã±â¿¡¼­ ¾î¶² °æ·Î¸¦ °è¼Ó °¡Áö°í ÀÖÀ» °ÍÀΰ¡, ¹ö¸± °ÍÀΰ¡¸¦ °áÁ¤ÇÏ´Â ¾Ë°í¸®ÁòÀº ´ÙÀ½°ú °°´Ù:

  1. Ÿ°Ù ÆÄÀÏÀÌ ¸ÞÀÌÅ©ÆÄÀÏ¿¡ ÁöÁ¤µÈ °æ·Î¿¡ µé¾î ÀÖÁö ¾ÊÀ¸¸é, µð·ºÅ丮 ã±â°¡ ½ÃÀ۵ȴÙ.
  2. µð·ºÅ丮 ã±â°¡ ¼º°øÇϸé, ±× °æ·Î°¡ À¯ÁöµÇ¸é¼­ ÀÌ ÆÄÀÏÀº ½ÃÇè»ï¾Æ Ÿ°ÙÀ¸·Î ÀúÀåµÈ´Ù.
  3. ÀÌ Å¸°ÙÀÇ ¸ðµç ÀÇÁ¸¼ºÀº °°Àº ¹æ¹ýÀ» »ç¿ëÇØ °Ë»çµÈ´Ù.
  4. ÀÇÁ¸¼ºµéÀ» ¸ðµÎ ó¸®ÇÑ ´ÙÀ½, Ÿ°ÙÀÌ ´Ù½Ã ¸¸µé¾îÁ®¾ß ÇÒÁö ¾Æ´ÒÁö °áÁ¤µÈ´Ù:
    1. Ÿ°ÙÀ» ´Ù½Ã ¸¸µé¾î¾ß ÇÒ ÇÊ¿ä°¡ ¾øÀ¸¸é, µð·ºÅ丮 ã±â¿¡¼­ ã¾Æ³½ ÆÄÀÏÀÇ °æ·Î°¡ ±× Ÿ°Ù¿¡ µû¶ó¿À´Â ÀÇÁ¸¼º ¸®½ºÆ®¿¡ »ç¿ëµÈ´Ù. ´Ù½Ã ¸»ÇØ, make´Â Ÿ°ÙÀ» ´Ù½Ã ºôµåÇÒ ÇÊ¿ä°¡ ¾øÀ¸¹Ç·Î µð·ºÅ丮 ã±â¿¡¼­ ¹ß°ßµÈ °æ·Î¸¦ »ç¿ëÇÑ´Ù.
    2. ±× Ÿ°ÙÀ» ´Ù½Ã ¸¸µé¾î¾ß ÇÒ °æ¿ì, µð·ºÅ丮 ã±â¿¡¼­ ãÀº °æ·Î À̸§Àº ¹ö·ÁÁö°í, ÀÌ Å¸°ÙÀº ¸ÞÀÌÅ©ÆÄÀÏ¿¡ ÁöÁ¤µÈ ÆÄÀÏÀ̸§À» »ç¿ëÇØ ´Ù½Ã ¸¸µé¾î Áø´Ù. °£´ÜÈ÷ ¸»ÇØ, make°¡ ´Ù½Ã ºôµåÇØ¾ß ÇÏ´Â °æ¿ì, ±× Ÿ°ÙÀº ÇöÀç µð·ºÅ丮¿¡¼­ ¸¸µé¾î Áö°í, µð·ºÅ丮 ã±â¿¡¼­ ã¾Æ³½ µð·ºÅ丮¿¡¼­ ¸¸µé¾î ÁöÁö ¾Ê´Â´Ù.

ÀÌ ¾Ë°í¸®ÁòÀº º¹ÀâÇØ º¸ÀÌÁö¸¸, ½ÇÁ¦ ´ëºÎºÐÀÇ °æ¿ì ÀÌ°ÍÀÌ »ç¿ëÀÚ°¡ ¿øÇÏ´Â µ¿ÀÛÀÌ´Ù.

´Ù¸¥ ¹öÀüÀÇ make´Â À̺¸´Ù °£´ÜÇÑ ¾Ë°í¸®ÁòÀ» »ç¿ëÇÑ´Ù: ÆÄÀÏÀÌ ¾ø°í, µð·ºÅ丮 ã±â¿¡¼­ ±× ÆÄÀÏÀ» ãÀ¸¸é, Ÿ°ÙÀ» ´Ù½Ã ºôµåÇØ¾ß ÇÏ´ÂÁö ¾Æ´ÑÁö¿¡ °ü°è¾øÀÌ ¾ðÁ¦³ª ±× °æ·Î¸íÀÌ »ç¿ëµÈ´Ù. Áï, Ÿ°ÙÀ» ´Ù½Ã ¸¸µé °æ¿ì¿¡ µð·ºÅ丮 ã±â¿¡¼­ ¹ß°ßµÈ °æ·Î¿¡¼­ ±× Ÿ°ÙÀÌ ¸¸µé¾î Áø´Ù.

»ç½Ç»ó ÀÌ·¸°Ô µ¿ÀÛÇÏ´Â ÆíÀÌ »ç¿ëÀÚ°¡ ¿øÇÏ´Â ¹ÙÀÏ ¼öµµ ÀÖ´Ù, ÀÌ °æ¿ì¿¡ GPATH º¯¼ö¸¦ »ç¿ëÇؼ­ make°¡ ÀÌ·¸°Ô µ¿ÀÛÇϵµ·Ï ÇÒ ¼ö ÀÖ´Ù.

GPATH´Â VPATH¿Í ¹®¹ý°ú Çü½ÄÀÌ °°´Ù(Áï °æ·Î À̸§À» °ø¹éÀ̳ª ÄÝ·ÐÀ¸·Î ±¸ºÐÇؼ­ ¾´´Ù). ´Ù½Ã ºôµåÇØ¾ß Çϴ Ÿ°ÙÀÌ µð·ºÅ丮 ã±â¿¡¼­ ¹ß°ßµÇ°í, ±× µð·ºÅ丮°¡ GPATH¿¡ ÀÖ´Â °æ¿ì, ±× °æ·Î¸íÀÌ ¹ö·ÁÁöÁö ¾Ê´Â´Ù. Ÿ°ÙÀº µð·ºÅ丮 ã±â¿¡¼­ ¹ß°ßµÈ °æ·Î¿¡¼­ ´Ù½Ã ºôµåµÈ´Ù.

µð·ºÅ丮 ã±â¿Í ÇÔ²² ¼Ð ¸í·É »ç¿ëÇϱâ

¾î¶² µðÆæ´ø½Ã°¡ µð·ºÅ丮 ã±â¸¦ ÅëÇØ Ã£Àº µð·ºÅ丮 ³»¿¡ ÀÖÀ» ¶§, ÀÌ µðÆæ´ø½Ã´Â ·êÀÇ ¸í·É¾î¸¦ ¹Ù²Ü ¼ö ¾ø´Ù; ´Ù½Ã ¸»Çؼ­ ¾²¿©Áø ±×´ë·Î ½ÇÇàµÈ´Ù. Áï, ¸í·É¾î¸¦ ¾µ ¶§ ÁÖÀǸ¦ ±â¿ï¿© ÀÛ¼ºÇؾ߸¸ make°¡ ±× ã¾Æ³½ µð·ºÅ丮 ¾È¿¡ ÀÖ´Â µðÆæ´ø½Ã¸¦ ¸í·É¾î¿¡ ¾µ ¼ö ÀÖ´Ù.

ÀÌ·± ¸ñÀûÀ» À§ÇØ `$^'¿Í °°Àº ÀÚµ¿ º¯¼ö°¡ ÀÖ´Ù (see section Automatic Variables). ¿¹¸¦ µé¸é, `$^'ÀÇ °ªÀº ·êÀÇ ¸ðµç µðÆæ´ø½ÃÀÇ ¸®½ºÆ®·Î, °¢°¢ÀÇ µðÆæ´ø½Ã´Â µð·ºÅ丮 ã±â¸¦ ÅëÇØ Ã£¾ÆÁø µð·ºÅ丮ÀÇ À̸§µµ Æ÷ÇÔÇÑ´Ù. ¶Ç ÇÑ°¡Áö ¿¹·Î, ÀÚµ¿ º¯¼ö `$@'ÀÇ °ªÀº Ÿ°ÙÀÌ´Ù. Áï:

foo.o : foo.c
        cc -c $(CFLAGS) $^ -o $@

(CFLAGS º¯¼ö´Â ³»Æ÷ÀûÀÎ ·ê¿¡¼­ C ÄÄÆÄÀÏ¿¡ »ç¿ëÇÒ Ç÷¡±×µéÀ» ÁöÁ¤ÇÏ´Â º¯¼öÀÌ´Ù; ¿ì¸®´Â ¸ðµç C ÄÄÆÄÀÏ°úÁ¤¿¡ Àû¿ëµÉ ¼ö ÀÖµµ·Ï ¿©±â¼­ ÀÌ º¯¼ö¸¦ »ç¿ëÇß´Ù; see section Variables Used by Implicit Rules.)

¾î¶² °æ¿ì¿¡´Â µðÆæ´ø½Ã¿¡´Â Çì´õ ÆÄÀϵµ Æ÷ÇԵǾî ÀÖ°í, ÀÌ Çì´õ ÆÄÀÏÀº À§ ¸í·É¿¡¼­ ¾²¸é ¾È µÈ´Ù. ÀÚµ¿ º¯¼ö `$<'´Â ù¹ø° µðÆæ´ø½Ã¸¦ °¡¸®Å²´Ù:

VPATH = src:../headers
foo.o : foo.c defs.h hack.h
        cc -c $(CFLAGS) $< -o $@

Directory Search and Implicit Rules

The search through the directories specified in VPATH or with vpath also happens during consideration of implicit rules (see section ¾Ï¹¬ÀûÀÎ ·ê »ç¿ëÇϱâ).

For example, when a file `foo.o' has no explicit rule, make considers implicit rules, such as the built-in rule to compile `foo.c' if that file exists. If such a file is lacking in the current directory, the appropriate directories are searched for it. If `foo.c' exists (or is mentioned in the makefile) in any of the directories, the implicit rule for C compilation is applied.

The commands of implicit rules normally use automatic variables as a matter of necessity; consequently they will use the file names found by directory search with no extra effort.

Directory Search for Link Libraries

Directory search applies in a special way to libraries used with the linker. This special feature comes into play when you write a dependency whose name is of the form `-lname'. (You can tell something strange is going on here because the dependency is normally the name of a file, and the file name of the library looks like `libname.a', not like `-lname'.)

When a dependency's name has the form `-lname', make handles it specially by searching for the file `libname.a' in the current directory, in directories specified by matching vpath search paths and the VPATH search path, and then in the directories `/lib', `/usr/lib', and `prefix/lib' (normally `/usr/local/lib', but MS-DOS/MS-Windows versions of make behave as if prefix is defined to be the root of the DJGPP installation tree).

For example,

foo : foo.c -lcurses
        cc $^ -o $@

would cause the command `cc foo.c /usr/lib/libcurses.a -o foo' to be executed when `foo' is older than `foo.c' or than `/usr/lib/libcurses.a'.

Æ÷´Ï Ÿ°Ù

Æ÷´Ï Ÿ°ÙÀº ÆÄÀÏ À̸§ÀÌ ¾Æ´Ñ Ÿ°ÙÀÌ´Ù.

A phony target is one that is not really the name of a file. It is just a name for some commands to be executed when you make an explicit request. There are two reasons to use a phony target: to avoid a conflict with a file of the same name, and to improve performance.

If you write a rule whose commands will not create the target file, the commands will be executed every time the target comes up for remaking. Here is an example:

clean:
        rm *.o temp

Because the rm command does not create a file named `clean', probably no such file will ever exist. Therefore, the rm command will be executed every time you say `make clean'.

The phony target will cease to work if anything ever does create a file named `clean' in this directory. Since it has no dependencies, the file `clean' would inevitably be considered up to date, and its commands would not be executed. To avoid this problem, you can explicitly declare the target to be phony, using the special target .PHONY (see section Special Built-in Target Names) as follows:

.PHONY : clean

Once this is done, `make clean' will run the commands regardless of whether there is a file named `clean'.

Since it knows that phony targets do not name actual files that could be remade from other files, make skips the implicit rule search for phony targets (see section ¾Ï¹¬ÀûÀÎ ·ê »ç¿ëÇϱâ). This is why declaring a target phony is good for performance, even if you are not worried about the actual file existing.

Thus, you first write the line that states that clean is a phony target, then you write the rule, like this:

.PHONY: clean
clean:
        rm *.o temp

A phony target should not be a dependency of a real target file; if it is, its commands are run every time make goes to update that file. As long as a phony target is never a dependency of a real target, the phony target commands will be executed only when the phony target is a specified goal (see section Arguments to Specify the Goals).

Phony targets can have dependencies. When one directory contains multiple programs, it is most convenient to describe all of the programs in one makefile `./Makefile'. Since the target remade by default will be the first one in the makefile, it is common to make this a phony target named `all' and give it, as dependencies, all the individual programs. For example:

all : prog1 prog2 prog3
.PHONY : all

prog1 : prog1.o utils.o
        cc -o prog1 prog1.o utils.o

prog2 : prog2.o
        cc -o prog2 prog2.o

prog3 : prog3.o sort.o utils.o
        cc -o prog3 prog3.o sort.o utils.o

Now you can say just `make' to remake all three programs, or specify as arguments the ones to remake (as in `make prog1 prog3').

When one phony target is a dependency of another, it serves as a subroutine of the other. For example, here `make cleanall' will delete the object files, the difference files, and the file `program':

.PHONY: cleanall cleanobj cleandiff

cleanall : cleanobj cleandiff
        rm program

cleanobj :
        rm *.o

cleandiff :
        rm *.diff

Rules without Commands or Dependencies

If a rule has no dependencies or commands, and the target of the rule is a nonexistent file, then make imagines this target to have been updated whenever its rule is run. This implies that all targets depending on this one will always have their commands run.

An example will illustrate this:

clean: FORCE
        rm $(objects)
FORCE:

Here the target `FORCE' satisfies the special conditions, so the target `clean' that depends on it is forced to run its commands. There is nothing special about the name `FORCE', but that is one name commonly used this way.

As you can see, using `FORCE' this way has the same results as using `.PHONY: clean'.

Using `.PHONY' is more explicit and more efficient. However, other versions of make do not support `.PHONY'; thus `FORCE' appears in many makefiles. See section Æ÷´Ï Ÿ°Ù.

Empty Target Files to Record Events

The empty target is a variant of the phony target; it is used to hold commands for an action that you request explicitly from time to time. Unlike a phony target, this target file can really exist; but the file's contents do not matter, and usually are empty.

The purpose of the empty target file is to record, with its last-modification time, when the rule's commands were last executed. It does so because one of the commands is a touch command to update the target file.

The empty target file must have some dependencies. When you ask to remake the empty target, the commands are executed if any dependency is more recent than the target; in other words, if a dependency has changed since the last time you remade the target. Here is an example:

print: foo.c bar.c
        lpr -p $?
        touch print

With this rule, `make print' will execute the lpr command if either source file has changed since the last `make print'. The automatic variable `$?' is used to print only those files that have changed (see section Automatic Variables).

Special Built-in Target Names

Certain names have special meanings if they appear as targets.

.PHONY
The dependencies of the special target .PHONY are considered to be phony targets. When it is time to consider such a target, make will run its commands unconditionally, regardless of whether a file with that name exists or what its last-modification time is. See section Æ÷´Ï Ÿ°Ù.
.SUFFIXES
The dependencies of the special target .SUFFIXES are the list of suffixes to be used in checking for suffix rules. See section Old-Fashioned Suffix Rules.
.DEFAULT
The commands specified for .DEFAULT are used for any target for which no rules are found (either explicit rules or implicit rules). See section Defining Last-Resort Default Rules. If .DEFAULT commands are specified, every file mentioned as a dependency, but not as a target in a rule, will have these commands executed on its behalf. See section Implicit Rule Search Algorithm.
.PRECIOUS
The targets which .PRECIOUS depends on are given the following special treatment: if make is killed or interrupted during the execution of their commands, the target is not deleted. See section Interrupting or Killing make. Also, if the target is an intermediate file, it will not be deleted after it is no longer needed, as is normally done. See section Chains of Implicit Rules. You can also list the target pattern of an implicit rule (such as `%.o') as a dependency file of the special target .PRECIOUS to preserve intermediate files created by rules whose target patterns match that file's name.
.INTERMEDIATE
The targets which .INTERMEDIATE depends on are treated as intermediate files. See section Chains of Implicit Rules. .INTERMEDIATE with no dependencies marks all file targets mentioned in the makefile as intermediate.
.SECONDARY
The targets which .SECONDARY depends on are treated as intermediate files, except that they are never automatically deleted. See section Chains of Implicit Rules. .SECONDARY with no dependencies marks all file targets mentioned in the makefile as secondary.
.IGNORE
If you specify dependencies for .IGNORE, then make will ignore errors in execution of the commands run for those particular files. The commands for .IGNORE are not meaningful. If mentioned as a target with no dependencies, .IGNORE says to ignore errors in execution of commands for all files. This usage of `.IGNORE' is supported only for historical compatibility. Since this affects every command in the makefile, it is not very useful; we recommend you use the more selective ways to ignore errors in specific commands. See section Errors in Commands.
.SILENT
If you specify dependencies for .SILENT, then make will not the print commands to remake those particular files before executing them. The commands for .SILENT are not meaningful. If mentioned as a target with no dependencies, .SILENT says not to print any commands before executing them. This usage of `.SILENT' is supported only for historical compatibility. We recommend you use the more selective ways to silence specific commands. See section Command Echoing. If you want to silence all commands for a particular run of make, use the `-s' or `--silent' option (see section Summary of Options).
.EXPORT_ALL_VARIABLES
Simply by being mentioned as a target, this tells make to export all variables to child processes by default. See section Communicating Variables to a Sub-make.

Any defined implicit rule suffix also counts as a special target if it appears as a target, and so does the concatenation of two suffixes, such as `.c.o'. These targets are suffix rules, an obsolete way of defining implicit rules (but a way still widely used). In principle, any target name could be special in this way if you break it in two and add both pieces to the suffix list. In practice, suffixes normally begin with `.', so these special target names also begin with `.'. See section Old-Fashioned Suffix Rules.

Multiple Targets in a Rule

A rule with multiple targets is equivalent to writing many rules, each with one target, and all identical aside from that. The same commands apply to all the targets, but their effects may vary because you can substitute the actual target name into the command using `$@'. The rule contributes the same dependencies to all the targets also.

This is useful in two cases.

Suppose you would like to vary the dependencies according to the target, much as the variable `$@' allows you to vary the commands. You cannot do this with multiple targets in an ordinary rule, but you can do it with a static pattern rule. See section Static Pattern Rules.

Multiple Rules for One Target

One file can be the target of several rules. All the dependencies mentioned in all the rules are merged into one list of dependencies for the target. If the target is older than any dependency from any rule, the commands are executed.

There can only be one set of commands to be executed for a file. If more than one rule gives commands for the same file, make uses the last set given and prints an error message. (As a special case, if the file's name begins with a dot, no error message is printed. This odd behavior is only for compatibility with other implementations of make.) There is no reason to write your makefiles this way; that is why make gives you an error message.

An extra rule with just dependencies can be used to give a few extra dependencies to many files at once. For example, one usually has a variable named objects containing a list of all the compiler output files in the system being made. An easy way to say that all of them must be recompiled if `config.h' changes is to write the following:

objects = foo.o bar.o
foo.o : defs.h
bar.o : defs.h test.h
$(objects) : config.h

This could be inserted or taken out without changing the rules that really specify how to make the object files, making it a convenient form to use if you wish to add the additional dependency intermittently.

Another wrinkle is that the additional dependencies could be specified with a variable that you set with a command argument to make (see section Overriding Variables). For example,

extradeps=
$(objects) : $(extradeps)

means that the command `make extradeps=foo.h' will consider `foo.h' as a dependency of each object file, but plain `make' will not.

If none of the explicit rules for a target has commands, then make searches for an applicable implicit rule to find some commands see section ¾Ï¹¬ÀûÀÎ ·ê »ç¿ëÇϱâ).

Static Pattern Rules

Static pattern rules are rules which specify multiple targets and construct the dependency names for each target based on the target name. They are more general than ordinary rules with multiple targets because the targets do not have to have identical dependencies. Their dependencies must be analogous, but not necessarily identical.

Syntax of Static Pattern Rules

Here is the syntax of a static pattern rule:

targets ...: target-pattern: dep-patterns ...
        ¸í·É¾î
        ...

The targets list specifies the targets that the rule applies to. The targets can contain wildcard characters, just like the targets of ordinary rules (see section ÆÄÀÏÀ̸§À¸·Î ¿ÍÀϵåÄ«µå ¹®ÀÚ »ç¿ëÇϱâ).

The target-pattern and dep-patterns say how to compute the dependencies of each target. Each target is matched against the target-pattern to extract a part of the target name, called the stem. This stem is substituted into each of the dep-patterns to make the dependency names (one from each dep-pattern).

Each pattern normally contains the character `%' just once. When the target-pattern matches a target, the `%' can match any part of the target name; this part is called the stem. The rest of the pattern must match exactly. For example, the target `foo.o' matches the pattern `%.o', with `foo' as the stem. The targets `foo.c' and `foo.out' do not match that pattern.

The dependency names for each target are made by substituting the stem for the `%' in each dependency pattern. For example, if one dependency pattern is `%.c', then substitution of the stem `foo' gives the dependency name `foo.c'. It is legitimate to write a dependency pattern that does not contain `%'; then this dependency is the same for all targets.

`%' characters in pattern rules can be quoted with preceding backslashes (`\'). Backslashes that would otherwise quote `%' characters can be quoted with more backslashes. Backslashes that quote `%' characters or other backslashes are removed from the pattern before it is compared to file names or has a stem substituted into it. Backslashes that are not in danger of quoting `%' characters go unmolested. For example, the pattern `the\%weird\\%pattern\\' has `the%weird\' preceding the operative `%' character, and `pattern\\' following it. The final two backslashes are left alone because they cannot affect any `%' character.

Here is an example, which compiles each of `foo.o' and `bar.o' from the corresponding `.c' file:

objects = foo.o bar.o

all: $(objects)

$(objects): %.o: %.c
        $(CC) -c $(CFLAGS) $< -o $@

Here `$<' is the automatic variable that holds the name of the dependency and `$@' is the automatic variable that holds the name of the target; see section Automatic Variables.

Each target specified must match the target pattern; a warning is issued for each target that does not. If you have a list of files, only some of which will match the pattern, you can use the filter function to remove nonmatching file names (see section Functions for String Substitution and Analysis):

files = foo.elc bar.o lose.o

$(filter %.o,$(files)): %.o: %.c
        $(CC) -c $(CFLAGS) $< -o $@
$(filter %.elc,$(files)): %.elc: %.el
        emacs -f batch-byte-compile $<

In this example the result of `$(filter %.o,$(files))' is `bar.o lose.o', and the first static pattern rule causes each of these object files to be updated by compiling the corresponding C source file. The result of `$(filter %.elc,$(files))' is `foo.elc', so that file is made from `foo.el'.

Another example shows how to use $* in static pattern rules:

bigoutput littleoutput : %output : text.g
        generate text.g -$* > $@

When the generate command is run, $* will expand to the stem, either `big' or `little'.

Static Pattern Rules versus Implicit Rules

A static pattern rule has much in common with an implicit rule defined as a pattern rule (see section Defining and Redefining Pattern Rules). Both have a pattern for the target and patterns for constructing the names of dependencies. The difference is in how make decides when the rule applies.

An implicit rule can apply to any target that matches its pattern, but it does apply only when the target has no commands otherwise specified, and only when the dependencies can be found. If more than one implicit rule appears applicable, only one applies; the choice depends on the order of rules.

By contrast, a static pattern rule applies to the precise list of targets that you specify in the rule. It cannot apply to any other target and it invariably does apply to each of the targets specified. If two conflicting rules apply, and both have commands, that's an error.

The static pattern rule can be better than an implicit rule for these reasons:

Double-Colon Rules

Double-colon rules are rules written with `::' instead of `:' after the target names. They are handled differently from ordinary rules when the same target appears in more than one rule.

When a target appears in multiple rules, all the rules must be the same type: all ordinary, or all double-colon. If they are double-colon, each of them is independent of the others. Each double-colon rule's commands are executed if the target is older than any dependencies of that rule. This can result in executing none, any, or all of the double-colon rules.

Double-colon rules with the same target are in fact completely separate from one another. Each double-colon rule is processed individually, just as rules with different targets are processed.

The double-colon rules for a target are executed in the order they appear in the makefile. However, the cases where double-colon rules really make sense are those where the order of executing the commands would not matter.

Double-colon rules are somewhat obscure and not often very useful; they provide a mechanism for cases in which the method used to update a target differs depending on which dependency files caused the update, and such cases are rare.

Each double-colon rule should specify commands; if it does not, an implicit rule will be used if one applies. See section ¾Ï¹¬ÀûÀÎ ·ê »ç¿ëÇϱâ.

Generating Dependencies Automatically

In the makefile for a program, many of the rules you need to write often say only that some object file depends on some header file. For example, if `main.c' uses `defs.h' via an #include, you would write:

main.o: defs.h

You need this rule so that make knows that it must remake `main.o' whenever `defs.h' changes. You can see that for a large program you would have to write dozens of such rules in your makefile. And, you must always be very careful to update the makefile every time you add or remove an #include.

To avoid this hassle, most modern C compilers can write these rules for you, by looking at the #include lines in the source files. Usually this is done with the `-M' option to the compiler. For example, the command:

cc -M main.c

generates the output:

main.o : main.c defs.h

Thus you no longer have to write all those rules yourself. The compiler will do it for you.

Note that such a dependency constitutes mentioning `main.o' in a makefile, so it can never be considered an intermediate file by implicit rule search. This means that make won't ever remove the file after using it; see section Chains of Implicit Rules.

With old make programs, it was traditional practice to use this compiler feature to generate dependencies on demand with a command like `make depend'. That command would create a file `depend' containing all the automatically-generated dependencies; then the makefile could use include to read them in (see section ´Ù¸¥ ¸ÞÀÌÅ©ÆÄÀÏ Æ÷ÇÔÇϱâ).

In GNU make, the feature of remaking makefiles makes this practice obsolete--you need never tell make explicitly to regenerate the dependencies, because it always regenerates any makefile that is out of date. See section ¸ÞÀÌÅ©ÆÄÀÏ ´Ù½Ã ¸¸µå´Â ¹ý.

The practice we recommend for automatic dependency generation is to have one makefile corresponding to each source file. For each source file `name.c' there is a makefile `name.d' which lists what files the object file `name.o' depends on. That way only the source files that have changed need to be rescanned to produce the new dependencies.

Here is the pattern rule to generate a file of dependencies (i.e., a makefile) called `name.d' from a C source file called `name.c':

%.d: %.c
        $(SHELL) -ec '$(CC) -M $(CPPFLAGS) $< \
                      | sed '\''s/\($*\)\.o[ :]*/\1.o $@ : /g'\'' > $@; \
                      [ -s $@ ] || rm -f $@'

See section Defining and Redefining Pattern Rules, for information on defining pattern rules. The `-e' flag to the shell makes it exit immediately if the $(CC) command fails (exits with a nonzero status). Normally the shell exits with the status of the last command in the pipeline (sed in this case), so make would not notice a nonzero status from the compiler.

With the GNU C compiler, you may wish to use the `-MM' flag instead of `-M'. This omits dependencies on system header files. See section `Options Controlling the Preprocessor' in Using GNU CC, for details.

The purpose of the sed command is to translate (for example):

main.o : main.c defs.h

into:

main.o main.d : main.c defs.h

This makes each `.d' file depend on all the source and header files that the corresponding `.o' file depends on. make then knows it must regenerate the dependencies whenever any of the source or header files changes.

Once you've defined the rule to remake the `.d' files, you then use the include directive to read them all in. See section ´Ù¸¥ ¸ÞÀÌÅ©ÆÄÀÏ Æ÷ÇÔÇϱâ. For example:

sources = foo.c bar.c

include $(sources:.c=.d)

(This example uses a substitution variable reference to translate the list of source files `foo.c bar.c' into a list of dependency makefiles, `foo.d bar.d'. See section Substitution References, for full information on substitution references.) Since the `.d' files are makefiles like any others, make will remake them as necessary with no further work from you. See section ¸ÞÀÌÅ©ÆÄÀÏ ´Ù½Ã ¸¸µå´Â ¹ý.


Go to the first, previous, next, last section, table of contents.