InglesPransesEspanyol

Ad


OnWorks favicon

makepp_rules - Online sa Cloud

Patakbuhin ang makepp_rules sa OnWorks na libreng hosting provider sa Ubuntu Online, Fedora Online, Windows online emulator o MAC OS online emulator

Ito ang command makepp_rules na maaaring patakbuhin sa OnWorks na libreng hosting provider gamit ang isa sa aming maramihang libreng online na workstation gaya ng Ubuntu Online, Fedora Online, Windows online emulator o MAC OS online emulator

PROGRAMA:

NAME


makepp_rules -- Paano sasabihin sa makepp na bumuo ng isang bagay

DESCRIPTION


?: &,
-,
@, B: :build_cache,
:build_check, D: : pagpapadala, E: :env, I: "ignore_error",
: isama, L: :huling pagkakataon, M: makeperl, N: "noecho", P: :parser,
"perl", S: :pirma

Ang isang panuntunan ay kung ano ang nagsasabi sa makepp kung paano bumuo ng isang file o isang klase ng mga file. Sinusuportahan ng Makepp ang
parehong syntax ng panuntunan tulad ng iba pang mga pagpapatupad ng make, kasama ang ilang mga karagdagan sa sarili nito.

Ang isang panuntunan ay may pangkalahatang format

target_expression : dependency_expression [ : mga opsyonal na argumento]
pagkilos

Ang listahan ng mga target ay maaaring walang anumang mga awtomatikong variable (maliban sa "$(foreach)"). Ang
Ang listahan ng dependency ay maaaring maglaman lamang ng mga awtomatikong variable na tumutukoy sa target (ibig sabihin,
"$(output)", "$(outputs)", o ang kanilang mga kasingkahulugan). Ang aksyon ay maaaring maglaman ng anumang awtomatiko
mga variable.

Kung magpasya ang makepp na kailangang isagawa ang panuntunan, isasagawa ang bawat linya ng panuntunan
sunud-sunod, at kung may nagbabalik ng hindi zero na katayuan, ang natitira ay hindi isasagawa (at
makepp aborts na may error maliban kung tinukoy mo ang "-k" na opsyon sa command line.)
Ang bawat aksyon ay dapat na isang linya lamang. Kung ang isang aksyon ay masyadong mahaba upang isulat nang maginhawa sa a
solong linya, maaari mo itong hatiin sa ilang linya at maglagay ng backslash upang ipahiwatig na ang
ilang linya ang dapat pagsamahin sa isa.

Upang makilala ang mga aksyon mula sa susunod na panuntunan, dapat na mas naka-indent ang aksyon
kaysa sa linyang naglalaman ng mga target at dependencies. Hindi tulad ng ibang mga pagpapatupad ng
gumawa, wala talagang pakialam ang makepp kung gaano mo ito indent o kung gumagamit ka ng mga character sa tab
sa halip na mga espasyo. Upang mapanatili ang pabalik na pagkakatugma sa tradisyonal na paggawa, ang mga patakaran
ginagamit ng makepp upang magpasya kung kailan magtatapos ang mga aksyon at ang susunod na panuntunan ay magsisimula ay medyo kumplikado:

· Ang unang linya ng aksyon ay dapat na naka-indent nang higit sa linyang naglalaman ng target.

· Kung ang isang linya ay naka-indent ng isang tab na character o 8 puwang o higit pa, ito ay isasaalang-alang
isang linya ng aksyon.

· Isang blangkong linya o linya ng komento na may "#" na character sa kanang margin ang nagtatapos sa
panuntunan, maliban kung ang susunod na hindi blangko na linya ay naka-indent ng higit sa 8 mga puwang (o higit sa isa
tab).

· Kung ang isang linya ay naka-indent nang mas marami o higit pa kaysa sa unang linya ng aksyon, kung gayon ito ay
itinuturing na isang karagdagang linya ng pagkilos.

Mayroong ilang mga espesyal na item ng pagkilos:

& Ang simbolo na ito ay susundan ng isang command name at anumang bilang ng mga argumento. Shell
hindi ganap na naiintindihan ang syntax dito, single at double quotes lang at backslashed
mga character sa loob, tulad ng sa buong makepp. Ang pangalan ng command ay maaaring humantong sa isang function
"c_pangalan" na tatawagin kasama ang natitirang mga string bilang mga argumento. Kung ang ganitong function ay maaari
hindi matagpuan, ito ay kapareho ng pagtawag sa "run" mula sa isang "perl" block.

Nagbibigay-daan ito sa mahusay na pagtawag sa isang built-in, makefile-provided o external na command.
Napili ang prefix na "&" dahil ito ang function invoker sa Perl, at dahil
sa simula bawal ito sa Shell.

$(ROOT)/include/%.h: %.h
&ln $(input) $(output)

noecho
@ Karaniwan, ang bawat shell command ay naka-print habang ito ay naisakatuparan. Gayunpaman, kung ang unang salita
ng aksyon ay "noecho" (o kung ito ay nagsisimula sa karakter na "@"), pagkatapos ay ang command
ay hindi nakalimbag. Halimbawa,

%.o: %.cxx
noecho $(LIBTOOL) --mode=compile $(CC) -c $(input)

Nangangahulugan ito na kapag ang libtool command ay naisakatuparan, hindi ito naka-print. (Libtool
ang mismong sarili ay kadalasang nagpi-print ng binagong utos na ipinapatupad nito, kaya ito ay kalabisan
i-print ito ng dalawang beses.)

ignore_error
- Karaniwan, kung ang shell command ay nagbabalik ng isang non-zero na katayuan, ang makepp ay abort dahil
nabigo ang utos. Gayunpaman, ang ilang mga programa ay hindi wastong nagtakda ng katayuan sa paglabas, o
maaaring mayroong isang error na talagang hindi nakamamatay at hindi dapat i-abort ang kabuuan
compilation. Maaari mong maging sanhi ng makepp na huwag pansinin ang status ng pagbabalik sa pamamagitan ng pagtukoy
"ignore_error" bilang unang salita ng command line (o "-" bilang unang character).
Halimbawa,

$(huwad na pamamahagi):
ignore_error rm -r my_program-$(VERSION) # Alisin ang nakaraang basura.
&mkdir my_program-$(VERSION)
&cp $(FILES) my_program-$(VERSION)
tar cf my_program-$(VERSION).tar my_program-$(VERSION)

Ang utos na ito ay gumagawa ng isang direktoryo, kinokopya ang isang bungkos ng mga file dito, at pagkatapos ay inilalagay
lahat sa isang tar file para sa pamamahagi. Magandang ideya na linisin ang
mga nakaraang nilalaman ng direktoryo, kung mayroong anumang bagay doon dati, at iyon
kung ano ang ginagawa ng unang linya. Maaaring mabigo ang "rm", ngunit hindi papansinin ang katayuan ng pagbabalik nito.

perlas
makeperl
Ito ay mahalagang kapareho ng perl na pahayag, ngunit ito ay ginaganap sa tuwing kailan
tumatakbo ang panuntunan, hindi kapag nagbabasa ng makefile. Ang unang variant ay plain Perl
code, habang ang pangalawang variant ay unang ipinapasa ang pahayag sa pamamagitan ng Make-style variable
expansion.

Para sa dalawang posibilidad ng paglalagay ng braces ng katawan, tingnan ang paliwanag sa
"perl_perlcode" sa makepp_statements. Tandaan na ang ikatlong variant ay ipinaliwanag doon
walang kabuluhan dito, dahil ang lahat ng mga linya ng aksyon ay dapat na naka-indent. Dapat kang magsenyas
kabiguan sa mga pahayag ng Perl, sa pamamagitan ng pagtawag sa "mamatay".

Bawat panuntunan ang mga Perl na pahayag ay kasalukuyang sinusuri sa isang karaniwang subprocess, maliban sa
Windows. Nangangahulugan iyon na nabasa lang nila ang access sa anumang mga variable ng makefile. Ito rin ay
ang prosesong nagsasagawa ng mga pagkilos na hindi Perl. Kaya ang pagtawag sa exec o exit ay malito
makepp. Ngunit ito ay maaaring magbago sa hinaharap. Para sa isang mahusay na paraan upang tawagan si Perl
script, tingnan ang nakaraang item na "&" o "run".

$(huwad na bersyon):
noecho perl {{ # $(target) at $(VERSION) mula sa Perl:
print "Ito ay ".f_target()." $VERSION\n";
}}
echo Maaari mong ihalo ito sa mga utos ng Shell
-makeperl { print "Ito ay $(target) $(VERSION)\n" }

Mayroong ilang iba't ibang uri ng mga patakaran, bawat isa ay may iba't ibang layunin.

Malinaw Batas
target1 target2: dependency1 dependency2 ...
mga aksyon na gagawin

Ang syntax na ito ay tumutukoy na upang gawin ang alinman target1 or target2, lahat ng mga file
dependency1, dependency2, atbp., ay dapat na ginawa na. Pagkatapos ang mga ibinigay na aksyon ay
isinagawa ng shell upang gawin ang mga target.

Ang unang tahasang panuntunan sa isang file ay ang default na target, at gagawin kung hindi mo tinukoy
anumang mga target sa command line.

Hindi tulad ng mga tradisyunal na programa ng paggawa, karaniwang ipinapalagay ng makepp na ang isang invocation ng aksyon
ginagawa ang lahat ng mga target (maliban kung walang dependencies). Halimbawa, isang invocation
ng yacc ay lumilikha ng parehong mga output file para sa panuntunang ito:

y.tab.c y.tab.h : parser.y
$(YACC) -d parser.y

Tandaan na ang ibang mga pagpapatupad ng make ay walang konsepto ng iisang command
paggawa ng maramihang mga output file, at kaya kapag tumukoy ka ng maramihang mga target ay gagawin nila
isagawa ang panuntunan nang isang beses bawat target. Babalik ang Makepp sa gawi na ito kung mukhang
ito ay isang lumang-style makefile. Sa partikular, isasagawa nito ang panuntunan nang isang beses bawat target,
sa halip na isang beses lang sa pangkalahatan, kung totoo ang lahat ng sumusunod:

· Binabanggit ng pagkilos ng panuntunan ang awtomatikong variable na $@. (Ang mga kasingkahulugang "$(output)" o
"$(target)" huwag mag-trigger ng pag-uugaling ito.)

· Ang pagkilos ng panuntunan ay hindi binanggit ang awtomatikong variable na "$(outputs)" (o ang kasingkahulugan nito
"$(mga target)").

· Ito ay hindi isang pattern rule, at walang foreach clause.

Halimbawa,

lahat ng pagsubok na pag-install:
para sa subdir sa $(SUBDIRS); gawin ang cd $$subdir && $(GUMAWA) $@; cd ..; tapos na

ay isang karaniwang idyoma sa makefiles, at sinusuportahan ito ng makepp. (Tandaan na hindi mo dapat gamitin
recursive make sa anumang bagong makefile na isusulat mo--gamitin ang "load_makefile" na pahayag, o
implicit makefile loading sa halip.)

Kung gusto mong ipatupad ang parehong panuntunan nang isang beses para sa bawat target (hal., dahil ang mga target
may mga katulad na utos), mas mainam na gumamit ng alinman sa isang pattern na panuntunan (tingnan sa ibaba) o a
"foreach" clause. Halimbawa, kung sa isang tradisyunal na make program ay isusulat mo ang:

a B C D:
do_something to build $@ > $@

sa makepp, malamang na gusto mong isulat ito ng ganito:

$(foreach) : : foreach abcd
do_something to build $(output) > $(output)

Phony target

A hindi pagkakasundo target ay isang target na hindi kailanman aktwal na iiral sa file system; ito ay isang
paraan ng pagkuha ng makepp upang bumuo ng ilang mga target at posibleng magsagawa ng ilang karagdagang mga utos.

Ang karaniwang huwad na target ay "lahat", na kadalasang ginagamit upang maging sanhi ng lahat ng maaaring mangyari
binuo upang maitayo, tulad nito:

lahat: prog1 prog2 subdir/prog3 subdir2/libmine.a
@&echo "Tapos na lahat!"

Kung nag-type ka ng "makepp all", o kung inilagay mo ang lahat bilang unang tahasang target sa iyong makefile
(na karaniwan) at i-type lamang ang "makepp", pagkatapos ay magiging sanhi ito ng lahat ng dependencies
binuo, pagkatapos ay i-print ang "All done!". Sa puntong ito, hahanapin ng makepp ang file ./lahat
at matutuklasan na hindi ito umiiral. Magrereklamo ito ng malakas.

Para hindi umasa si makepp sa file ./lahat upang lumabas, kailangan mong sabihin dito na ito ay a
huwad na target. Maglagay lamang ng isang linya tulad ng sumusunod sa iyong makefile (wala itong pinagkaiba
saan):

.PHONY: lahat

Ang isang katumbas na alternatibo na kung minsan ay mas maginhawa ay ang paggamit ng "$(phony )"
function, tulad nito:

$(phony all): prog1 prog2 subdir/prog3 subdir2/libmine.a

Ang mga huwad na target sa isang makefile ay maaaring sumangguni sa mga huwad na target sa isa pang makefile. Ito ay
madalas na ginagawa sa "malinis" na target, tulad nito:

# Nangungunang antas ng makefile:
# maraming panuntunan at bagay dito
# ....
$(phony clean): subdir1/clean subdir2/clean
&rm -fm my_program

Pagkatapos sa mga subdirectory, ang mga makefile ay maaaring magbasa ng ganito:

# Makefile sa isang subdirectory
# ...
$(huwad na malinis):
&rm -fm $(wildcard *.o *.a)

Ngunit sa ngayon ay gagamitin mo ang "makeppclean" na utos, sa halip na isang malinis na target.

Mga wildcard

Ligtas na tukuyin ang mga wildcard sa listahan ng dependency. Ang mga wildcard ay tumutugma hindi lamang sa mga file
na umiiral, ngunit ang mga file na maaaring malikha dahil sa mga panuntunan sa makefile. Halimbawa,
para bumuo ng library mula sa lahat ng .o file sa isang direktoryo, maaari mong isulat ito:

libmine.a: *.o
&rm -f $(output)
ar cr $(output) $(inputs)

Ito ay gagana kahit na wala pa sa mga ".o" na file ang nagawa pa, dahil ang makepp's
Ang mga wildcard ay tumutugma sa mga file na hindi pa umiiral ngunit maaaring itayo. Ito ay mapupulot pa
mga file na ang panuntunan ay natuklasan sa ibang pagkakataon (sa parehong makefile, o isang hindi pa nababasa). Dito sa
huling punto ay naiiba ito sa function na "wildcard", na limitado sa mga kilalang panuntunan,
dahil dapat itong ibalik ang resulta nito kapag ito ay pinalawak.

Sinusuportahan ng Makepp ang lahat ng karaniwang mga wildcard ng shell ("*", "?", at "[]"). Mayroon din itong isang
wildcard na "**" na tumutugma sa anumang bilang ng mga intervening directory. (Ang ideyang ito ay ninakaw
mula sa zsh.) Halimbawa, ang "**/*.c" ay tumutugma sa lahat ng .c mga file sa buong source tree.
Ang "objects/**/*.o" ay tumutugma sa lahat ng .o mga file na nakapaloob saanman sa subdirectory bagay
o alinman sa mga subdirectory nito o alinman sa kanilang mga subdirectory. Ang "**" wildcard ay hindi
sundin ang mga malambot na link sa mga direktoryo sa anumang antas. Hindi rin nito ibabalik ang mga huwad na target.

Babalewalain ng mga wildcard ng Makepp ang mga file o direktoryo na umiiral ngunit hindi mababasa. Pagkatapos
lahat, hindi magagamit ang mga ganoong file sa proseso ng pagbuo. Ang paglalagay ng mga hindi nababasang file sa a
directory ay pangunahing kapaki-pakinabang upang pigilan ang awtomatikong pag-import ng ibinigay na file mula sa a
imbakan.

Ang unang assertion ay na ito ay ligtas. Ito ay sa kahulugan na ito ay gumagana kung
ang mga file ay mayroon na, o kailangang itayo muna. Gayunpaman ito ay hindi ligtas sa kahulugan
na tutugma pa rin ito sa mga file na binuo ng makepp, ngunit wala nang panuntunan (hal
tinanggal mo ang .c file, ngunit ang .o naroon pa rin ang file.) Upang maiwasan ito, gamitin ang
"--rm-stale" na opsyon.

huwaran patakaran
Ang panuntunan ng pattern ay isang panuntunang inilalapat batay sa ilang textual pattern. Ito ay nakasanayan na
ilapat ang parehong panuntunan sa isang buong klase ng mga file. Ang syntax ay kapareho ng GNU make's
mga panuntunan sa pattern:

%.o: %.c
$(CC) -c $(input) -o $(output)

Sinasabi nito na ang anumang file sa kasalukuyang direktoryo na tumutugma sa "*.c" ay maaaring ma-convert sa
ang kaukulang .o file gamit ang ibinigay na command.

Tandaan na maaaring maibigay ang ilang dependency ng pattern. Halimbawa, kung ang iyong xyz.o file
depende sa kaukulang xyz.cpp file, at gayundin sa isang file na tinatawag na moc_xyz.cflags alin
naglalaman ng mga pagpipilian sa compiler, maaari itong ipahayag sa:

%.o: %.cpp %.cflags
$(CXX) `cat $(stem).cflags` -c $(inputs) -o $(output)

Maaari ka ring magkaroon ng ilang target ng pattern. Halimbawa,

%.tab.h %.tab.c : %.y
yacc -d $(input)
&mv y.tab.h $(stem).tab.h
&mv y.tab.c $(stem).tab.c

Karaniwan, ang mga panuntunan sa pattern ay naghahanap lamang ng mga file sa kasalukuyang mga direktoryo. Pwede mong pilitin
upang maghanap sa kasalukuyang direktoryo at lahat ng mga direktoryo sa ilalim nito sa pamamagitan ng pagtatakda

makepp_percent_subdirs := 1

bago ang unang panuntunan ng pattern sa iyong makefile o sa command line halimbawa.

May malinaw na pagkakaiba sa pagitan ng "%" at ng wildcard na "*", kahit na parehong tumutugma sa alinman
string: Ang wildcard ay nagbabalik ng isang listahan ng mga file na ganap na ginagamit sa puntong iyon. Kaya
ito ay depende sa lahat .o mga file na mabubuo dito:

prog: *.o
$(LD) $(LDFLAGS) $(inputs) -o $(output)

Hindi ito makakamit sa pamamagitan ng pagpapalit ng "*" ng "%", dahil ang huli ay para sa isa-isa
pagtutugma ng input sa output, na gumagawa ng panloob ng isang panuntunan para sa bawat katugmang stem.

Statik huwaran patakaran
Ang isang static na panuntunan ng pattern ay isang pattern ng panuntunan na inilalapat lamang sa isang limitadong hanay ng mga file:

$(SPECIAL_MODULES).o : %.o : %.cpp
$(CXX) -c $(input) -o $(output)

Sinasabi nito na ang panuntunan ng pattern ay nalalapat lamang sa mga file sa "$(SPECIAL_MODULES).o".

Ito ay kadalasang para sa pagiging tugma sa GNU make; para sa bawat panuntunan (tingnan sa ibaba) ay higit pa
makapangyarihang paraan ng paggawa ng parehong bagay.

Magpakailanman patakaran
Ang syntax ng panuntunan ng pattern sa itaas ay sapat na makapangyarihan upang suportahan ang halos lahat ng mga build, ngunit
paminsan-minsan ay kinakailangan na gumawa ng isang bagay na mas kumplikado. Nagbibigay ang Makepp ng higit pa
malakas na syntax: ang ":foreach" na sugnay para sa panuntunan.

target_expression : dependency_expression : foreach file-list
pagkilos

Ang pinakasimpleng uri ng foreach na panuntunan ay isang pattern na panuntunan lamang na ang aplikasyon ay pinaghihigpitan
sa isang partikular na listahan ng mga file. Halimbawa, ipagpalagay na mayroon kang panuntunan sa pattern na nagsasabi
makepp paano i-compile lahat .c mga file. Gayunpaman, mayroon kang listahan ng .c mga file kung saan ka
gustong gumawa ng kakaiba. Maaari kang gumawa ng isang bagay tulad nito:

# Narito ang panuntunang nalalapat sa lahat:
%.o : %.c
$(CC) $(CFLAGS) -c $(input) -o $(output)

%.o : %.c : foreach $(SPECIAL_MODULES)
$(CC) $(SPECIAL_CFLAGS) -c $(input) -o $(output)

Ang isang mas malakas na paggamit ng foreach panuntunan ay sinasamantala ang katotohanan na ang variable
Ang "$(foreach)" ay nakatakda naman sa bawat file na tumutugma sa listahan ng file at sa target at
nasusuri ang mga expression ng dependency. Ang listahan ng file ay maaaring maglaman ng mga wildcard, at ang mga ito
tumugma sa kahit na mga file na hindi pa umiiral ngunit maaaring itayo (tingnan ang "Wildcards" sa
makepp_rules).

Ito ay isang mahirap gamitin na syntax ngunit ito ay lubos na nababaluktot, dahil ang "$(foreach)" na variable
maaaring lumitaw sa anumang paraan sa pagpapahayag. Una, tandaan na ang mga panuntunan sa pattern ay sa katunayan a
espesyal na kaso ng foreach rules; ang pattern rule

%.o : %.c
$(CC) $(CFLAGS) -c $(input) -o $(output)

ay eksaktong katumbas ng:

$(patsubst %.c, %.o, $(foreach)): $(foreach) : foreach *.c
$(CC) $(CFLAGS) -c $(input) -o $(output)

(Sa katunayan, ito ay na-convert sa humigit-kumulang na iyon sa loob.)

Bilang isang halimbawa ng kung paano mo gagamitin ang isang ":foreach" na sugnay kung saan ang panuntunan ng pattern ay hindi
sapat na, ipagpalagay na mayroon kang ilan .c mga file na binuo gamit ang ilang uri ng preprocessor
na tumatagal bilang mga file ng input na may a .k extension. Gusto mong i-compile ang mga iyon .c mga file na may a
ibang hanay ng mga opsyon sa compilation kaysa sa karaniwan .c mga file na karaniwang pinagmumulan
mga file. Maaari kang gumawa ng isang bagay tulad nito:

# Panuntunan para sa mga ordinaryong .c na file:
%.o : %.c
$(CC) $(CFLAGS) -c $(input) -o $(output)

# Panuntunan para gumawa ng mga .c na file mula sa mga .k na file:
%.c: %.k
$(preprocessor) $(input) > $(output)

# Mga espesyal na panuntunan sa pagbuo para sa mga .c na file na ginawa mula sa mga .k na file:
$(foreach:%.k=%.o) : $(foreach:%.c=%.k): foreach *.k
$(CC) $(SPECIAL_CFLAGS) -c $(input) -o $(output)

(Gumagamit ito ng bahagyang mas maigsi na pagpapalit na reference syntax kaysa sa pagtawag
"patsubst" tahasang.)

Tandaan na kung ang gusto mo lang gawin ay baguhin ang halaga ng isang variable ("CFLAGS" dito
kaso) minsan mas maginhawang gumamit ng mga variable na partikular sa target.

Pamana suffix patakaran
Para sa backward compatibility, sinusuportahan ng makepp ang lumang-style na mga panuntunan sa suffix.

.suffix1.suffix2:
pagkilos

ay katumbas ng

%.suffix2: %.suffix1
pagkilos

ngunit mas mahirap tandaan. (Aling suffix ang mauna?) Kadalasan, may lalabas na panuntunan
sa isang legacy makefile tulad nito:

.co:
$(CC) $(CFLAGS) -c $*.c -o $*.o

na eksaktong katumbas ng

%.o : %.c
$(CC) $(CFLAGS) -c $(input) -o $(output)

Salungat patakaran
Kapag mayroong higit sa isang paraan upang gumawa ng isang file, ang makepp ay gumagamit ng isang simpleng pamamaraan upang
tukuyin kung aling tuntunin ang gagamitin.

· Ito ay isang error na magkaroon ng magkasalungat na tahasang mga panuntunan para sa pagbuo ng isang file.

· Ang mga panuntunan sa pattern at mga panuntunan sa foreach na may mga wildcard ay hindi kailanman na-override ang mga tahasang panuntunan. Sa gayon
maaaring gamitin ang mga tahasang panuntunan upang tukuyin ang mga pagbubukod para sa mga panuntunan ng pattern. (Tandaan na lang
ang paggamit ng ":foreach" na sugnay ay hindi gumagawa ng isang bagay bilang panuntunan ng pattern. Dapat itong magkaroon ng isang
wildcard (tulad ng "*" o "?") bilang bahagi ng filename sa clause na ":foreach". Kung ito ay
isang tahasang listahan lamang ng mga file, ito ay itinuturing bilang isang tahasang panuntunan para sa bawat isa sa mga iyon
mga file.)

· Kapag ang magkasalungat na panuntunan sa pattern ay nagmula sa iba't ibang makefile, mga panuntunan mula sa "mas malapit"
makefiles override panuntunan mula sa "mas malayo" makefiles. "Malapit" ay nangangahulugan na ang makefile
ay matatagpuan mas malapit sa target sa hierarchy ng direktoryo (ibig sabihin, ang pangalan ng file ng
target na may kaugnayan sa direktoryo kung saan pinapatakbo ang makefile ay mas maikli). Kung ito
ay hindi nakikilala ang mga makefile, pagkatapos ay ang panuntunan mula sa makefile na na-load
pinakabagong ginagamit.

Nangangahulugan ito na maaari kang tumukoy ng panuntunan ng pattern na nalalapat sa lahat ng mga file sa iyong
buong directory tree sa top-level makefile lang, ngunit maaari mo itong i-override
isang mas mababang antas ng makefile. Halimbawa, ang iyong top-level na makefile ay maaaring maglaman ng:

%.o : %.c : foreach **/*.c
$(CC) $(CFLAGS) -c $(input) -o $(output)

at maaari kang magkaroon ng makefile sa isa sa mga subdirectory na nagsasabing:

%.o : %.c
$(CC) $(SPECIAL_CFLAGS) -c $(input) -o $(output)

· Ang mga panuntunan sa pattern na may mas maikling chain of inference ay mas gusto kaysa sa ibang pattern
mga tuntunin. Halimbawa, kung mayroon kang mga sumusunod na panuntunan (batay sa isang halimbawa mula sa
Linux kernel):

%.s: %.c
$(CC) -s $(input) -o $(output)

%.o: %.s
$(AS) $(input) -o $(output)

%.o: %.c
$(CC) -c $(input) -o $(output)

Kung kailangan nating buuin ang "xyz.o", maaari nating buuin ang intermediate na ".s" na file at pagkatapos
patakbuhin iyon sa pamamagitan ng assembler gamit ang unang dalawang panuntunan, o maaari kaming direktang pumunta sa a
".o" na file gamit ang huling panuntunan. Mas gusto ang huling panuntunan dahil mas kaunti
mga hakbang sa chain of inference (isa sa halip na dalawa).

· Mga panuntunan sa pattern sa ibang pagkakataon sa isang makefile override pattern rules na mas maaga. (Ito ay
pabalik mula sa GNU make.) Nangangahulugan ito na dapat mong ilagay ang iyong mas pangkalahatang mga tuntunin
mas maaga, at ang iyong mas partikular na mga panuntunan sa ibang pagkakataon. Halimbawa,

%.o: %.c # Pangkalahatang tuntunin ng compilation.
aksyon

special_%.o: special_%.c # Espesyal na panuntunan para sa mga file na may a
ibang aksyon # "espesyal_" prefix.

Patakaran pagpipilian
Minsan kinakailangan na magbigay ng mga karagdagang opsyon para baguhin kung paano isinasagawa ng makepp ang
tuntunin. Ang mga opsyong ito ay tinukoy bilang ":optionname value", alinman sa linyang naglalaman
ang mga dependencies, o sa susunod na linya.

Ang pagbibigay ng mga opsyon sa magkahiwalay na linya ay maaaring gawing posible para sa iyo na gumamit ng pareho
makefile na may makepp at isang tradisyonal na make. Halimbawa,

target : dependencies
: signature target_newer
pagkilos

gagana nang maayos sa isang tradisyunal na paggawa ng Unix, dahil binibigyang-kahulugan nito ang linyang ": lagda".
bilang isang shell command, at isang command na nagsisimula sa isang colon ay walang ginagawa.

:build_cache /path/to/build/cache
target : dependencies
: build_cache /put/cache/files/over/there
pagkilos

Tinutukoy ang path sa isang build cache na gagamitin para sa mga file na ginawa ng panuntunang ito. Ito
override ang epekto ng "build_cache" na pahayag o ang "--build-cache" na utos
opsyon sa linya, kung mayroon man, para sa panuntunang ito. Tingnan ang makepp_build_cache para sa mga detalye tungkol sa build
mga cache.

Kung tinukoy mo ang "wala" sa halip na isang path, hindi mo pinagana ang build cache para dito
partikular na tuntunin. Ito ay maaaring maging kapaki-pakinabang upang maiwasan ang pag-aaksaya ng espasyo sa disk sa mga file na ikaw
know aren't useful to cache, either because you are very sure will never be
ginamit muli o dahil ang mga ito ay binuo nang napakabilis na hindi sulit na i-cache ang mga ito.

:build_check build_check_method
target : dependencies
: build_check target_newer
pagkilos

Sinasabi nito sa makepp kung anong algorithm ang gagamitin upang magpasya kung ang mga target ay kailangang itayo muli.
Tingnan ang makepp_build_check para sa higit pang mga detalye. Ino-override nito ang epekto ng
"build_check" na pahayag o ang "--build-check-method" na opsyon sa command line, kung mayroon man, para sa
panuntunang ito.

:env VARIABLE ...
Magdagdag ng dependency sa mga halaga ng pinangalanang mga variable ng kapaligiran. Kung sino man sa kanila
naiiba mula sa nakaraang build, kung gayon ang mga target ay itinuturing na luma na, kung ang
build_check method kaya dinidikta. (Lahat ng built-in na build check method maliban sa
target_newer igalang ito.)

Ang VARIABLE ay maaaring nasa anyong "filename sa PATH_VARIABLE" (sa mga quote), kung saan ang
ang mga target ay itinuturing na luma na kung ang unang direktoryo mula sa colon-delimited
ang halaga ng PATH_VARIABLE kung saan umiiral ang filename ay iba sa huling build.
Magagamit ito upang maiwasan ang muling pagbuo ng mga target kapag nagbago ang PATH_VARIABLE sa isang
walang katuturang paraan.

:dispatch utos ...
Ilakip ang bawat pagkilos ng shell (ngunit hindi ang mga pagkilos ng Perl o ang mga utos ng Perl) sa isang "sh -c '...'"
at prefix ito ng command, ngunit ipagpalagay na ang target ay hindi nakadepende sa command.
Ito ay kapaki-pakinabang kung gusto mong magpadala ng mga aksyon sa isang sistema ng pagpila ng trabaho, ngunit ang resulta ay
ipinapalagay na independyente sa mga parameter ng queuing, pati na rin kung ang queuing
sistema ay ginagamit sa lahat.

:isama file_o_pattern
Nag-iiba ang panuntunan depende sa compiler:

%.o : %.c
: isama ang %.d : lagda C
gcc -MD -c ...

%.o : %.c
: isama ang %.u : lagda C # Gumagamit ang IBM ng ibang suffix
xlc -M -c ...

sub dependify { # Gawing kapaki-pakinabang na format ang chatter ng Microsoft
s/\$/\$\$/g;
s/(Tandaan: kasama ang file: *)?(.+?)\r?\n/$1 ? "'$2' " : "'".f_output()."': "/e;
}
%.o : %.c
: isama ang %.d : lagda C
cl -showIncludes -c ... >$(stem).d
&sed &depende -o +<$(stem).d

Ang ilang mga compiler (icc ng Intel tulad ng gcc sa itaas, o xlc ng IBM) ay maaaring makagawa ng dependency
mga file sa mabilisang. Ibig sabihin, habang nag-compile sila, nagsusulat sila ng makefile na kaya ng makepp
isama. Ang kalamangan sa scanner ng makepp ay ang garantisadong ito ay 100%
tama, kung saan maaari lamang tayong magkalapit.

Ginagamit ng opsyong ito sa isang espesyal na paraan: Kung wala ang file, ibig sabihin
karaniwang sa 1st build, nangyayari ang normal na pag-scan. Ngunit kung ang file ay naroroon, hindi
nagaganap ang pag-scan (kung kaya't tinukoy namin ang isang matalinong lagda sa itaas -- hindi bumabagsak ang pag-scan
bumalik sa piping default ng timestamp at laki). Sa halip kasama nito ang file, dati
pagpapatupad ng panuntunan. Matapos matagumpay na maisakatuparan ang panuntunan, nakalimutan nito kung ano man ito
basahin sa unang pagkakataon, dahil maaaring luma na ang file. Sa halip ay nagbabasa ito
muli ang file, kung nagbago ito, para sa pagkakaroon ng up-to-date na impormasyon ng build.

BABALA: Ito ay likas na hindi mapagkakatiwalaan. Ang dependency file ay nagagawa ng very
panuntunan kung saan ito ay isang dependency. Sa kabilang banda, alam ng compiler ang tungkol sa lahat
internal sub-includes ito, na kadalasang binabalewala ng makepp. Ito ay isang pagiging maaasahan
bentahe lamang para sa kaso kung saan inaayos lamang ng isang compiler patch ang mga sub-includes. Ang
Ang presyo ay ang makepp ay tumitingin sa marami pang mga file, na nangangailangan ng oras.

May catch kapag inalis mo ang isang "#include" na pahayag at ang kaukulang file:
Babanggitin pa rin ito sa dependency file mula sa huling pagkakataon, kung kailan ito
kailangan. Sa ganoong kaso dapat mong i-edit ang dependency file upang alisin ang dependency
na hindi na matutupad.

Hindi magagamit ang feature na ito sa isang build cache dahil kumukuha ng file mula doon
nangangailangan ng pag-alam ng lahat tungkol sa file. Ngunit ang isang dependency file ay nakasalalay sa mga iyon
mga file na natutunan ng makepp sa pamamagitan ng pagbabasa nito. Ang ganitong paikot na dependency ay hindi karaniwan
posible sa isang maaasahang sistema ng pagbuo. Ito ay isang pagbubukod dahil pagkatapos ng muling pagtatayo
at muling pagbabasa ng isang dependency file lahat ay tama muli.

Kung bubuo ka sa iyong mga repositoryo, kukunin ng makepp ang dependency file mula sa
1st repository na naglalaman ng isa. Ito ay hindi tulad ng iba pang mga file, kung saan ito ay tumatagal ng 1st
na may inaasahang pirma. Ito ay mas mahusay kaysa para sa build cache, kung saan para sa kakulangan ng
signature, hindi man lang nito mahanap ang file.

:huling pagkakataon
Paganahin ang isang open-ended na panuntunan, gaya ng

%.foo foo%.bar: :last_chance
&echo $@ -o $@
&cp $(mga output)

Dahil ang isang panuntunang tulad nito ay maaaring makabuo ng isang walang katapusang bilang ng mga target,
ang isang target ng panuntunang ito ay hindi tutugma sa isang function na $(wildcard) o panuntunan ng pattern maliban kung
may iba nang nagsagawa ng panuntunan sa pamamagitan ng partikular na pagtukoy sa target.
Higit pa rito, kung ang "--rm-stale" ay tinukoy, pagkatapos ay isang target na natitira mula sa isang nauna
Ang makepp run ay lalabas na lipas kung ang tanging paraan upang mabuo ito ay sa pamamagitan ng last_chance na panuntunan
na hindi pa nai-instance para sa target, na isang kanais-nais na pag-uugali dahil
mas tuluy-tuloy na mabibigo ang build kapag nagkamali itong umasa sa isang wildcard
tumugma sa mga target mula sa isang nakaraang pagtakbo.

Ang ":last_chance" na opsyon ay nilayon na tumawag ng pansin sa espesyal na pag-uugali ng
tuntunin tungkol sa pagtutugma ng mga wildcard.

:parser pares
Sinasabi nito sa makepp kung paano i-parse ang command para sa pag-detect (isama) ang mga file. kadalasan,
Nahuhulaan ng makepp kung paano ito gagawin batay sa mga salita sa mismong utos (tingnan
makepp_scanning para sa mga detalye). Gayunpaman, kung mali ang hula ni makepp, maaaring gusto mo
tahasang ipahiwatig ang parser, tulad nito:

%.o: %.abc
: parser c_compilation
aksyon dito

Nagiging sanhi ito ng makepp na gawin ang parehong pag-parse at pag-scan na ginagawa nito para sa C/C++
bumuo ng mga utos, kahit na hindi nito nakikilala ang aksyon bilang isang C compilation.

Ang default na parser ay nakasalalay sa utos. Kung hindi ka tumukoy ng opsyong ":parser",
pagkatapos ay susuriin ang unang salita ng bawat utos. Halimbawa para sa isang compile o link
command, makepp ay gagamit ng "c_compilation" parser; o kung ang utos ay mukhang ang
GNU variant, "gcc_compilation". Kung walang mahanap na parser, ginagamit nito ang "wala" na parser. Para sa
higit pang mga detalye tungkol dito, o kung gusto mong magsulat ng sarili mong parser o baguhin ang makepp's
mga default na parser, tingnan ang makepp_scanning.

Tandaan na nalalapat ito sa bawat command sa panuntunan, na maaaring hindi ang gusto mo:

%.o: %.c : parser c-compilation
@echo 'Gusali $(output)'
@funny_cc ...

Bibigyan din nito ng kahulugan ang "echo" bilang isang compiler at idededuce ang argumentong 'Building
mymodule.o' bilang isang implicit na dependency. Ito ay hahantong sa reklamo na ito
hindi alam kung paano bumuo ng ganoong file. Sa kasong ito, mas makabubuti sa iyo
"register_parser". Doon mo mahahanap ang paliwanag kung paano pares maaaring ibigay alinman bilang a
classname o bilang isang function name.

:pirma lagda_paraan
target : dependencies
: lagda md5
pagkilos

Sinasabi nito sa makepp kung anong algorithm ang gagamitin upang matukoy kung nagbago ang mga dependency.
Tingnan ang makepp_signatures para sa higit pang mga detalye. Mga pamamaraan ng lagda na kasama sa
Ang pamamahagi ng makepp ay "plain", "md5", "C" o "c_compilation_md5", at
"shared_object". Ino-override nito ang anumang paraan ng lagda na tinukoy sa "-m" o
"--signature-method" na mga opsyon sa command line, o kasama ang "signature" na pahayag.

espesyal character
Maaaring suportahan ng Makepp ang mga filename na may mga espesyal na character sa mga ito tulad ng colon o isang space.
Ipagpalagay, halimbawa, gusto mong lumikha ng isang file na tinatawag na "a:thing" mula sa file na "b:thing".
Hindi mo maaaring isulat ang panuntunan sa ganitong paraan:

a:thing : b:thing # Ito ay isang syntax error
&cat $(input) -o $(output)

dahil hindi malalaman ng makepp kung aling mga colon ang naghihiwalay sa mga target mula sa mga dependency at kung alin
bahagi ng mga filename. Sa halip, ilakip lamang ang pangalan sa mga quote, tulad nito:

"a:thing" : "b:thing"
&cat $(input) -o $(output)

Ngayon ang panuntunan ay hindi malabo.

Ang syntax ng pag-quote ng Makepp ay halos kapareho ng sa shell. Maaari mong, halimbawa, gumamit ng single
mga panipi sa halip na mga dobleng panipi, o maaari mong takasan ang mga espesyal na character na may backslash:

a\:thing : 'b:thing'
&cat $(input) -o $(output)

Ipagpalagay, halimbawa, na ang iyong filename ay "'"!;\$". Ngayon kung bakit mo gusto ang ganoong filename
Hindi ko alam, ngunit narito ang ilang mga paraan na maaari mong tukuyin ito sa makepp (at ang shell):

\''"!;\$$'
"'\"!;\\$$"

Magbayad ng pansin sa kung kailan makepp strips quotes at kapag ang shell ay. Tumingin si Makepp
quote lamang sa mga sumusunod na kaso:

· sa "ifeq" na pamilya ng mga pagsubok

· bago at pagkatapos ng rule colon

· sa isang makepp builtin command

· sa isang function na nauukol sa mga file

Hindi tulad ng shell, hindi pinapalawak ng makepp ang mga quote habang itinatalaga ang mga ito sa isang variable. Sa gayon
ang mga sumusunod na patakaran ay magkapareho:

FILE = 'pangalan na may mga puwang'
x := $(print $(FILE)) # para lang ma-check na nandoon pa rin ang mga quotes
$(FILE): # quotes sa paligid ng isang file na natanggal ng makepp
&echo hello -o$(FILE) # quotes sa paligid ng isang file na natanggal ng makepp
echo doon >>$(FILE) # quotes sa paligid ng isang file na natanggal ng Shell
'pangalan na may mga puwang':
&echo hello -o'name with spaces'
echo doon >>'$(output)' # quotes ang tinanggal sa itaas, idagdag muli ang mga ito

Tandaan na (hindi tulad ng Shell) ang mga variable na nagsisimula sa "$" ay pinalawak kahit sa loob ng single
quotes. Ang mga dollar sign ay hindi mapoprotektahan ng mga quote o backslashes. Upang makakuha ng literal
dollar sign, gumamit ng double dollar sign, hal,

$(huwad lahat):
@&echo Ito ay isang dollar sign: $$
@for val sa abcd; gawin echo $$val; tapos na

Sa pangkalahatan, dapat mong harapin ang halos anumang espesyal na karakter sa pamamagitan ng pagsipi nito
sa ibang paraan. Kabilang dito ang mga puwang, control character, atbp. Gayunpaman, magkaroon ng kamalayan na sa
sa kasalukuyan, medyo simplistic ang comment stripping ni makepp, at anumang "#" na character
na pinangungunahan ng whitespace ay bibigyang-kahulugan bilang mga komento gaano man ang mga ito ay sinipi.

Kapag ang isang target o dependency na pangalan ay inilagay sa isang awtomatikong variable tulad ng "$(output)", kung gayon
ang mga quote at anumang backslash ay hinubaran. Nangangahulugan ito na kung nais mong sanggunian ang
filename sa mga aksyon, malamang na kailanganin mo itong sipiin muli, tulad nito:

"isang pangalan ng file na may mga puwang":
echo "Mga espesyal na nilalaman" > "$@"

Kung hindi mo ilalagay ang mga quote sa paligid ng $@, makikita ng shell ang command

echo "Mga espesyal na nilalaman" > isang pangalan ng file na may mga puwang

na nagsusulat ng string na "Pangalan ng file ng mga espesyal na nilalaman na may mga puwang" sa file na tinatawag a.
Malamang hindi ito ang gusto mo.

Gumamit ng makepp_rules online gamit ang mga serbisyo ng onworks.net


Mga Libreng Server at Workstation

Mag-download ng Windows at Linux apps

Linux command

Ad