makepp_faq - Online sa Cloud

PROGRAMA:

NAME

makepp_faq -- Mga madalas itanong tungkol sa makepp

DESCRIPTION

Dito maaari kang makahanap ng mga tagubilin sa pag-install at ilang mga punto na hindi halata mula sa
natitirang bahagi ng dokumentasyon. Ito ay nagpapakita ng mga hadlang, samantalang kung paano mag-type ng mga tanong ay gagawin
makikita sa cookbook.

Pagkuha Started
Saan sa i-download?

Ang Makepp ay naka-host sa SourceForge at maaaring i-download bilang isang source code tarball o bilang
package ng pag-install para sa Debian .deb nakabatay sa mga Linux o .rpm nakabatay sa mga Linux mula sa
http://sourceforge.net/projects/makepp/files/

Tulad ng toneladang Perl software, ang makepp ay maaari ding i-download mula sa CPAN sa pamamagitan ng pag-click sa
I-download ang link sa http://search.cpan.org/dist/makepp/

Ang Makepp ay bahagi ng Debian GNU/Linux na hindi matatag at pagsubok. Nangangahulugan ito na maaari mong i-install ito
direkta sa pamamagitan ng "apt-get install makepp" o sa pamamagitan ng pagpili nito mula sa iyong ginustong tool sa package
parang synaptic.

Ang Makepp ay bahagi ng archlinux at ng Gentoo Linux. Tandaan na ang mga distro-specific na suffix tulad ng
Ang 2.0-1 o 2.0-r1 ay hindi ang release candidate 1, ngunit ang huling inilabas na bersyon 2.0.

Maaari I sumubok it wala pag-install?

Oo, kung gusto mong subukan ang makepp sa iyong sariling mga makefile, ilagay ang direktoryo kung saan mo
i-unpack ito sa iyong landas, o kung hindi patakbuhin ito nang tahasang tulad nito, na may ganap na o
kamag-anak na landas sa makepp:

perl /where/you/unpacked/it/makepp

Gaano sa piliin perlas bersyon?

Dapat ay mayroon kang Perl 5.8 o mas bago sa isang lugar sa iyong system. Bilang default, na-uninstall ang lahat
gagamitin ng mga script ang "perl" sa iyong landas. Ngunit maaari mong patakbuhin ang mga ito sa isang tahasang halimbawa
ng perl. Tatakbuhin ng test runner at pag-install ang lahat sa parehong pagkakataong ito.

/path/to/perl /where/you/unpacked/it/makepp

Kung sakaling hindi makilala ng ilang script kung aling "perl" ang ginagamit nito, magagawa mo
tulungan ito sa pamamagitan ng pagsasabi dito ng landas patungo sa parehong instance ng perl sa pamamagitan ng variable na "PERL":

PERL=/path/to/perl /path/to/perl /where/you/unpacked/it/makepp

Maaari rin itong isang instance na hahanapin sa iyong path, kung wala itong a
separator ng direktoryo:

PERL=perl5.16.2 perl5.16.2 /where/you/unpacked/it/makepp

Gaano sa i-install?

Mayroong dalawang paraan ng pag-install, na humahantong sa parehong resulta:

i-configure (alias config.pl)
Nagbibigay-daan ito para sa pag-install ng tradisyonal na istilo:

./configure && gumawa ng pagsubok && gumawa ng pag-install

Ang pagkakaiba lang ng dalawang ito ay ang "configure" ay hindi isang Perl script, kaya ikaw
hindi masasabing "perl configure", samantalang maaari mong gamitin ang lahat ng variant sa itaas tulad ng "perl
config.pl". Ang mga wastong opsyon ay:

-b, --bindir=/path/to/installation/bin
Kung saan napupunta ang mga binary (default: unlapi/ bin). Ang mga binary ng Makepp ay Perl lang
mga script kaya sila ay independyente sa arkitektura. Kung ibibigay mo ang pagpipiliang ito, ngunit hindi
"--prefix", aalisin nito / bin sa paghihinuha a unlapi para sa iba pang mga default na halaga.

-d, --datadir=/path/to/installation/share/makepp
Kung saan i-install ang mga file ng library ng makepp (default: unlapi/share/makepp).

-f, --findbin=relative/path/to/datadir/from/bindir
Kung saan mahahanap ang mga aklatan na may kaugnayan sa mga executable, o 'wala' (ang default) na hahanapin
sila sa datadir.

-h, --htmldir=/path/to/installation/share/html
Kung saan napupunta ang dokumentasyon ng HTML (default: unlapi/doc/makepp kung unlapi/doc
mayroon, iba pa datadir/html), o 'wala' kung ayaw mong mai-install ito.

-m, --mandir=/landas/sa/tao
Kung saan dapat manatili ang mga manu-manong pahina (default: unlapi/share/man kung meron, else
unlapi/man), o 'wala' kung ayaw mong mai-install ang mga ito.

--makefile=/path/to/Makefile
Tukuyin ang lokasyon kung saan maaari mong isulat ang Makefile (default: .). Hindi tulad ng iba
mga opsyon, na naaalala para sa sumusunod na hakbang sa pag-install, nilikha ang file na ito
kaagad.

-p, --prefix=/path/to/installation
Tukuyin ang lokasyon kung saan mo gustong i-install ang lahat (default: / usr / lokal). Lahat
iba pang mga path ay bilang default na nauugnay sa isang ito.

-V
--bersyon
I-print ang numero ng bersyon.

Kung gusto mong gumawa ng mockup installation sa ilang destdir para sa sarili mong packaging
pamamahagi, maaari kang magbigay ng karagdagang parameter sa huling utos:

gawin ang DESTDIR=/pansamantalang/destdir install

install.pl
Ito ang backend na nagsasagawa ng aktwal na pag-install. Maaari mo itong tawagan nang direkta:

./install.pl bindir datadir mandir htmldir findbin destdir

Ang mga parameter ay opsyonal at tumutugma sa mga opsyon mula sa nakaraang seksyon.
Sinenyasan ka para sa mga hindi mo ibinibigay, maliban sa huli, na hindi
karaniwang kailangan.

Makefile.PL
Ang nakasanayang file Makefile.PL ay kasalukuyang naroroon lamang para sa mga teknikal na kadahilanan. Ito
habilin hindi tulungan kang mag-install. Samakatuwid, sayang, hindi ka maaaring gumamit ng mga tool tulad ng "cpanm" sa
i-install nang sabay-sabay.

Sa ilang system, alinman sa "perl" ang tatawagan mo ay maaaring isang simbolikong link sa ilang tiyak
bersyon "perl5.mn". Sa kasong ito, iyon lang ang nakikita ni perl, at sa gayon ay gagamitin ito sa
i-install laban sa. Kung hindi mo gusto iyon, gamitin ang variable na "PERL" tulad ng inilarawan sa itaas. Kung
nag-install ka gamit ang pangalawang variant, ibig sabihin, ang pangalan lang ng executable na walang mga slash,
ang mga naka-install na script ay palaging maghahanap para sa isang iyon sa pamamagitan ng "/usr/bin/env". Ginagawa ito sa kanila
medyo mas mabagal sa pagsisimula, para sa higit na kakayahang umangkop.

Bakit ang instalasyon sabihin pahintulot tinanggihan?

Kung nais mong i-install sa isang direktoryo ng system tulad ng / usr, / usr / lokal or / opt, Maaari ka lamang
gawin iyon kung patakbuhin mo ang pag-install bilang root ng user. Sa maraming Unices maaari kang magpatakbo ng isang command bilang
ugat, sa pamamagitan ng paglalagay ng "sudo" dito, at depende sa sistemang pumapasok sa alinman sa ugat
password, o sa iyo, bilang sinenyasan para sa.

Ito ay hindi kinakailangan para sa paghahandang "i-configure" o "config.pl" na hakbang na lamang
nagsusulat ng a Makefile sa kasalukuyang direktoryo.

Magtayo Tanong
Ano ay hindi mahalaga mga target?

Naaalala ng Makepp ang mga dependency ng bawat file. Kung mayroon man sa kanila na kailangang itayo muli, iyon
ay gagawin bago muling mag-scan. Ngunit kung ang build ay nabigo, ngunit ang pag-scan ay nagtagumpay, dahil
ang file ay hindi na kailangan pa, pagkatapos ay sa dulo ang pagkabigo ay iuulat bilang
hindi mahalaga. (Hindi dapat subukan ang build, sa halip ay hayaan ang rescan na gawin iyon
Bumubuo ito ay nalaman na kinakailangan, ngunit iyon ay nangyayari sa ibang lugar, kaya ito ay magiging
mahirap.)

Bakit ang it tumakbo ito mamuno 3 beses?

Ang GNU make ay walang makepp style multi target rules. Sa halip ay binibigyang kahulugan ito bilang isang shortcut
para sa tatlong magkakahiwalay na panuntunan:

abc:
echo $@
pindutin ang abc

Gayunpaman, hindi nito sinusuri kung bakit naroroon ang isang file. Kung mayroong isang file (at mas bago kaysa sa alinman
dependencies) ito ay masaya. Alinman sa tatlong mga file ang unang mabuo, nagbibigay ng
dalawa pa, kaya medyo kumikilos ito tulad ng isang multitarget na panuntunan -- ngunit maaaring magdulot ng lahi
mga kondisyon sa parallel build.

Ang isang katulad na panuntunan ay maaaring:

abc:
pindutin ang $@

Pinapatakbo nga ng Gmake ang isang ito nang isang beses sa bawat kinakailangang file. Nang hindi nalalaman kung ano ang ginagawa ng utos
(maaaring ito ay isang script na panloob na lumilikha ng ilang mga file), ang dalawang kaso ay hindi madaling maging
pinaghiwalay ni makepp.

Kaya bilang isang espesyal na compatibility fallback, kung ang isang multi target na pagkilos na panuntunan ay nagbanggit lamang ng luma
istilong $@ at alinman sa bagong istilong "$(output)" o "$(target)" o ang kanilang mga plural na anyo, ito ay
itinuturing bilang hiwalay na mga patakaran. Gayunpaman, nangangahulugan ito ng pagpapatakbo nito nang paulit-ulit, dahil hindi pinapansin ng makepp
random na lumalabas na mga file kung saan wala itong metadata.

Bakit ang it magreklamo na a nilikha file is huwad?

Kung mayroon kang isang utos na patuloy na gumagana nang asynchronous, pagkatapos nitong bumalik na may kasamang a
success return code, mapapansin ng makepp ang ipinangakong file bilang nawawala at nagreklamo. Ito
maaari ding karaniwang mangyari sa ilang network file system, na maaaring pisikal na sumulat lamang
makalipas ang ilang segundo.

Kung hindi mo maiiwasan ang ganitong hindi kasiya-siyang sitwasyon, maaari mong hilingin sa makepp na maging palpak
tungkol sa tseke na ito gamit ang "--gullible" na opsyon. Ngunit pagkatapos ay ang susunod na utos na nakasalalay sa
maaaring mabigo pa rin ang ginawang file.

Bakit ang it muling likhain file hindi kailangan?

Naobserbahan ko ito sa NFS, kung saan dahil sa pag-cache ng katangian ng file ang timestamp ng
ang ginawang file ay hindi pa ang isa sa wakas nito. Sa sumunod na pagtakbo ay napansin ni makepp ang
pagkakaiba at isinasaalang-alang ang file na labis na binago. Nalutas ito gamit ang isang opsyon sa pag-mount
ng "acregmin=0", na ginagawang nakikita kaagad ang mga katangian.

Maaari rin itong mangyari sa mga repositoryo, hal. kung may ibang tao na nagtayo sa repositoryo
gamit ang "umask 066" o gamit ang isang compiler na humahadlang sa iba sa pagbabasa ng ginawang file.
Mangyayari rin ito kung ang repositoryo o ang iyong build tree ay nagbabahagi ng isang karaniwang landas
prefix na may ilang dependencies (hal /opt/repository at /opt/sometool, kung saan
Maaalala ng makepp ang landas nang isang beses bilang kamag-anak, at isang beses bilang ganap, mukhang nagbago
dependencies.

Ba ang C pinagmulan file or ang bagay file manangan on mga header?

Depende ito sa iyong pananaw. Kung nagbabago ang isang prototype sa isang header, maaaring mayroon ang programmer
upang iakma ang source code. Kaya mula sa pananaw na iyon mayroong isang dependency.

Ngunit para sa pagtatayo ito ay ganap na hindi nauugnay. Dito nakasalalay ang mga output sa mga input.
Kung magbabago ang isang file ng header maaari itong makaapekto sa object file (hal. pagdaragdag ng mga parameter na may
mga default na halaga, na maaaring balewalain ng programmer, ngunit hindi ang compiler). Kaya mula sa makepp's
viewpoint tanging ang ginawang object file ay nakasalalay sa mga header, ibig sabihin, dapat na muling itayo kapag
mga pagbabagong ito.

sari-sari
Bakit ang makepp pumipili tuklasin dependencies?

Sa panuntunang ito bakit gumagawa ang makepp output depende sa input1, ngunit hindi sa input2?

output:
zcat output
zcat input2 >>output

May tatlong antas sa pag-scan. Ang una ay ang lexer, na sumusubok na maunawaan ang
Shell bahagi ng pagpapatupad. Ibig sabihin kung aling mga utos ang matatawag at kung ano ang mga pag-redirect ng I/O
mangyari. Ito ay paunawa input1 at output (kahit hindi pa ito idineklara na target ng
panuntunang ito).

Ang susunod na hakbang ay ang mga command parser. May ilan ang Makepp para sa mga tipikal na command ng compilation.
Sinusuri nito ang mga opsyon sa command line upang maunawaan kung ano ang gagawin ng command. Nasa
proseso na kumukuha sila ng mga dependency tulad ng mga aklatan ("cc -llib"), isama ang mga landas ("cc -Idir")
at mga input file. Ang gawain ng isang "zcat" parser ay malaman na ang "-S" ay tumatagal ng isang
argumento, ngunit ang lahat ng iba pang hindi opsyong salita ay mga filename (opsyonal na nilagyan ng suffix ng .gz), At
na ang "--" ay nagtatapos sa mga opsyon. Sa kasamaang palad, walang ganoong parser, hindi hihigit sa daan-daang iba pa
utos.

Ang ikatlong hakbang para sa ilang wika ay ang pag-scan ng mga input file, upang matukoy ang kasama bilang
karagdagang dependencies. Hindi ito naaangkop sa halimbawang ito.

Gaano maaari I mag-alis ng mga insekto makepp?

Maaari mong ilagay ang "$(print )" sa paligid ng isang kahina-hinalang expression. Ibinabalik nito ang hindi nagbabago
expression, habang ini-print ito bilang isang side effect.

Maaari mong itapon ang kasalukuyang direktoryo (multiply pagkatapos ng "-C" kung gusto mo) makefile gamit ang
"--dump-makefile=file" na opsyon, upang makita kung paano ito nakikita ng makepp.

Nagsusulat si Makepp ng log ng lahat ng ginagawa nito at kung bakit. Maaari mong tingnan iyon gamit ang makepplog,
mppl o makeppgraph, mppg. Magagawa mo itong mas verbose sa pamamagitan ng pagtatakda ng kapaligiran
variable na "MAKEPP_DEBUG".

Itinatala ng Makepp ang lahat ng nalalaman nito tungkol sa isang file, para magamit muli sa susunod na pagtakbo. Kahit na ito ay tumatagal ng ilang
pag-unawa sa mga internals ng makepp, paglalaglag nito ng makeppinfo, mppi para sa isa o higit pa
file, kadalasang nagbibigay ng clue kung ano ang mali. Ang "MAKEPP_DEBUG" ay nagbibigay din ng
"RULE_SOURCE".

Kung feeling mo adventurous, gumamit ng makepp from cvs. Kabilang dito ang mga karagdagang module na
kumabit sa "perl -d" para mas maipakita ang mga internal ng makepp.

Is it ligtas sa gamitin?

Oo, gagawin nito kung ano mismo ang sinasabi ng iyong mga makefile (na mahirap gawin ng maraming programmer
maunawaan, dahil ang inference batay sa panuntunan ay ibang-iba sa karamihan ng mga paradigm sa programming).

at hindi, kung hindi ka nagtitiwala sa mga makefile na nakuha mo, tiyak na hindi! Ang isang makefile ay isang nakakatawa
uri ng script, ang layunin nito ay magpatakbo ng mga utos na inaasahang magbabago sa iyong
file system. Walang paraan ang Makepp para masuri kung anong pinsala ang gagawin nila.

Mas masahol pa, palaging may mga execute na syntax, na ginagawa kahit na may "--dry-run" (na
hindi nagpapatakbo ng mga patakaran, ngunit sinusuri ang lahat ng iba pa). Maaaring may katulad iyon
ito:

bad_boy := $(shell rm *)

panlabas mga kasangkapan
Maaari I gamitin cc -M or gcc -MM?

Ang maikling sagot ay oo. Ang mahabang sagot ay mayroon silang kalamangan na malaman ang
epekto ng kahit na ang huling kakaibang opsyon ng compiler, at mga sub-kabilang ang nakatago sa ilang compiler
panloob na direktoryo, kung saan malapit lang ang makepp. Ang disadvantage ay sila
walang ideya sa mga panuntunan sa pagbuo, kaya hindi sila maaasahang umasa sa mga gagawin pang file,
na kinabibilangan ng mga file na kukunin mula sa isang repositoryo. At hindi sila extensible sa
iba pang mga wika, gaya ng scanner ng makepp. Kadalasan ikaw ay hindi bababa sa mahusay, hindi
gumagamit ng mga tool na ito.

Gayunpaman, ang ilang mga compiler ay maaaring gumawa nito bilang isang by-product. Kung mas gugustuhin mong gamitin ito
tingnan: isama.

Maaari I gamitin CCache, Compilecache or cachecc1?

Ang maikling sagot ay oo. Ang mahabang sagot ay ang mga programang ito ay kailangang ulitin ang gawain
makepp, upang makakuha ng maaasahang fingerprint ng mga file. Sa tradisyunal na ginagawa ito kahit na
huli na, dahil nakakaligtaan ang mga sitwasyong nangangailangan ng muling pagsasama-sama. Sa
makepp mas madaling gamitin ang built in build cache, na may dagdag na kalamangan
na kaya nitong pangasiwaan ang lahat ng uri ng mga file.

Tandaan na ang ccache direct mode ay may bug https://bugzilla.samba.org/show_bug.cgi?id=8728
na babalewalain ang pagbabago sa isama ang mga landas. Ginagawa nitong t/makeppreplay.test mabibigo sa
"maling file: out". I-export ang "CCACHE_NODIRECT=1" para maiwasan iyon.

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