cons - ອອນໄລນ໌ຢູ່ໃນ Cloud

ໂຄງການ:

NAME

Cons - ລະບົບການກໍ່ສ້າງຊອບແວ

ລາຍລະອຽດ

ຄູ່ມືແລະເອກະສານອ້າງອີງສໍາລັບສະບັບ 2.2.0

ລິຂະສິດ (c) 1996-2000 Free Software Foundation, Inc.

ໂຄງ​ການ​ນີ້​ແມ່ນ​ຊອບ​ແວ​ຟຣີ​; ທ່ານ​ສາ​ມາດ​ແຈກ​ຢາຍ​ມັນ​ແລະ / ຫຼື​ປັບ​ປຸງ​ແກ້​ໄຂ​ມັນ​ພາຍ​ໃຕ້​ເງື່ອນ​ໄຂ​ຂອງ​
ໃບອະນຸຍາດສາທາລະນະທົ່ວໄປຂອງ GNU ທີ່ຈັດພິມໂດຍ Free Software Foundation; ບໍ່ວ່າຈະ
ສະບັບ 2 ຂອງໃບອະນຸຍາດ, ຫຼື (ຕາມທາງເລືອກຂອງທ່ານ) ສະບັບຕໍ່ມາ.

ໂຄງການນີ້ໄດ້ຖືກແຈກຢາຍໂດຍຫວັງວ່າມັນຈະເປັນປະໂຫຍດ, ແຕ່ບໍ່ມີການຮັບປະກັນໃດໆ;
ໂດຍບໍ່ມີການຮັບປະກັນທາງດ້ານການຄ້າ ຫຼືຄວາມສອດຄ່ອງສໍາລັບຈຸດປະສົງສະເພາະ.
ເບິ່ງໃບອະນຸຍາດສາທາລະນະທົ່ວໄປຂອງ GNU ສໍາລັບລາຍລະອຽດເພີ່ມເຕີມ.

ທ່ານຄວນໄດ້ຮັບສໍາເນົາຂອງໃບອະນຸຍາດສາທາລະນະທົ່ວໄປ GNU ພ້ອມກັບໂຄງການນີ້;
ເບິ່ງໄຟລ໌ COPYING. ຖ້າບໍ່ແມ່ນ, ຂຽນຫາ Free Software Foundation, Inc., 59 Temple
ສະຖານທີ່ - Suite 330, Boston, MA 02111-1307, USA.

ການນໍາສະເຫນີ

cons ແມ່ນລະບົບການກໍ່ສ້າງ, ຕົ້ນຕໍ, ຊອບແວ, ແຕ່ຂ້ອນຂ້າງແຕກຕ່າງຈາກ
ລະບົບການກໍ່ສ້າງຊອບແວທີ່ຜ່ານມາ. Cons ໄດ້​ຖືກ​ອອກ​ແບບ​ຈາກ​ພື້ນ​ຖານ​ເຖິງ​ການ​ຈັດ​ການ​
ໄດ້ຢ່າງງ່າຍດາຍກັບການກໍ່ສ້າງຂອງຊອບແວທີ່ແຜ່ຂະຫຍາຍຢູ່ໃນຫຼາຍໄດເລກະທໍລີແຫຼ່ງ. ຂໍ້ເສຍ
ເຮັດໃຫ້ມັນງ່າຍຕໍ່ການສ້າງສະຄິບທີ່ງ່າຍດາຍ, ເຂົ້າໃຈແລະຮັກສາໄດ້.
Cons ຮັບປະກັນວ່າຊອຟແວທີ່ຊັບຊ້ອນແມ່ນໄດ້ຢ່າງງ່າຍດາຍແລະຖືກຕ້ອງການແຜ່ພັນ.

Cons ໃຊ້ເຕັກນິກຈໍານວນຫນຶ່ງເພື່ອເຮັດສໍາເລັດທັງຫມົດນີ້. script ການກໍ່ສ້າງແມ່ນພຽງແຕ່
Perl scripts, ເຮັດໃຫ້ພວກເຂົາທັງສອງເຂົ້າໃຈງ່າຍແລະມີຄວາມຍືດຫຍຸ່ນຫຼາຍ. ຂອບເຂດທົ່ວໂລກຂອງ
ຕົວແປຖືກແທນທີ່ດ້ວຍກົນໄກການນໍາເຂົ້າ / ສົ່ງອອກສໍາລັບການແລກປ່ຽນຂໍ້ມູນລະຫວ່າງ
scripts, ຢ່າງຫຼວງຫຼາຍປັບປຸງການອ່ານແລະການຮັກສາໄວ້ຂອງແຕ່ລະ script.
ການກໍ່ສ້າງ ສະພາບແວດລ້ອມ ໄດ້ຖືກນໍາສະເຫນີ: ເຫຼົ່ານີ້ແມ່ນວັດຖຸ Perl ທີ່ເກັບກໍາ
ຂໍ້ມູນທີ່ຈໍາເປັນສໍາລັບການຄວບຄຸມຂະບວນການສ້າງ. ສະພາບແວດລ້ອມຫຼາຍຖືກນໍາໃຊ້
ໃນເວລາທີ່ semantics ທີ່ແຕກຕ່າງກັນແມ່ນຕ້ອງການສໍາລັບການສ້າງຜະລິດຕະພັນໃນຕົ້ນໄມ້ກໍ່ສ້າງ. ຂໍ້ເສຍ
ປະຕິບັດການວິເຄາະການເພິ່ງພາອາໄສອັດຕະໂນມັດແລະນໍາໃຊ້ອັນນີ້ເພື່ອຈັດລໍາດັບທົ່ວໂລກ
ສ້າງ. ການສ້າງຕົວແປແມ່ນຜະລິດໄດ້ງ່າຍຈາກຕົ້ນໄມ້ແຫຼ່ງດຽວ. ການກໍ່ສ້າງອັດສະລິຍະ
ການຕັ້ງຄ່າຍ່ອຍແມ່ນເປັນໄປໄດ້, ໃນເວລາທີ່ເຮັດວຽກກ່ຽວກັບການປ່ຽນແປງທ້ອງຖິ່ນ. Overrides ສາມາດຕັ້ງຄ່າໄດ້
ລົບລ້າງຄໍາແນະນໍາການກໍ່ສ້າງໄດ້ຢ່າງງ່າຍດາຍໂດຍບໍ່ມີການດັດແປງສະຄິບໃດໆ. MD5 ລະຫັດລັບ
ລາຍເຊັນ ແມ່ນກ່ຽວຂ້ອງກັບໄຟລ໌ທີ່ໄດ້ມາ, ແລະຖືກນໍາໃຊ້ເພື່ອກໍານົດຢ່າງຖືກຕ້ອງວ່າ
ໄຟລ​໌​ທີ່​ໄດ້​ຮັບ​ຈໍາ​ເປັນ​ຕ້ອງ​ໄດ້​ຮັບ​ການ​ສ້າງ​ໃຫມ່​.

ໃນຂະນະທີ່ສະເຫນີທັງຫມົດຂ້າງເທິງ, ແລະຫຼາຍ, Cons ຍັງຄົງງ່າຍດາຍແລະງ່າຍທີ່ຈະນໍາໃຊ້. ນີ້​ຈະ​,
ຫວັງເປັນຢ່າງຍິ່ງ, ກາຍເປັນທີ່ຈະແຈ້ງໃນຂະນະທີ່ທ່ານອ່ານສ່ວນທີ່ເຫຼືອຂອງເອກະສານນີ້.

ເປັນຫຍັງ ຂໍ້ເສຍ? ເປັນຫຍັງ ບໍ່ ເຮັດໃຫ້?

ຂໍ້ເສຍແມ່ນ ກ ເຮັດໃຫ້ ການທົດແທນ. ໃນວັກຕໍ່ໄປນີ້, ພວກເຮົາເບິ່ງສອງສາມຂໍ້
ຄຸນ​ລັກ​ສະ​ນະ​ທີ່​ບໍ່​ຕ້ອງ​ການ​ຂອງ​ການ​ຜະ​ລິດ - ແລະ​ສະ​ພາບ​ແວດ​ລ້ອມ​ການ​ກໍ່​ສ້າງ​ປົກ​ກະ​ຕິ​ໂດຍ​ອີງ​ໃສ່​ການ make--ທີ່​
ກະຕຸ້ນການພັດທະນາຂອງ Cons.

ສ້າງ ຄວາມສັບສົນ

ລະບົບການຜະລິດແບບດັ້ງເດີມຂອງຂະຫນາດໃດກໍ່ຕາມມີແນວໂນ້ມທີ່ຈະກາຍເປັນສະລັບສັບຊ້ອນ. ຕົ້ນສະບັບເຮັດ
ຜົນປະໂຫຍດແລະອະນຸພັນຂອງມັນໄດ້ປະກອບສ່ວນກັບແນວໂນ້ມນີ້ໃນຫຼາຍວິທີ. ເຮັດໃຫ້ເປັນ
ບໍ່ດີໃນການຈັດການກັບລະບົບທີ່ແຜ່ຂະຫຍາຍຢູ່ໃນຫຼາຍໄດເລກະທໍລີ. ວຽກ​ງານ​ຕ່າງໆ -
ອ້ອມຮອບໄດ້ຖືກນໍາໃຊ້ເພື່ອເອົາຊະນະຄວາມຫຍຸ້ງຍາກນີ້; ທາງເລືອກປົກກະຕິແມ່ນເພື່ອເຮັດໃຫ້ການຮຽກຮ້ອງ
ຕົວຂອງມັນເອງ recursively ສໍາລັບແຕ່ລະ sub-directory ຂອງການກໍ່ສ້າງ. ນີ້ເຮັດໃຫ້ລະຫັດສັບສົນ, in
ເຊິ່ງມັນມັກຈະບໍ່ຊັດເຈນວ່າຕົວແປຖືກຕັ້ງແນວໃດ, ຫຼືມີຜົນແນວໃດຕໍ່ກັບການຕັ້ງຄ່າຕົວແປ
ຈະມີການກໍ່ສ້າງທັງຫມົດ. ພາສາການຂຽນສະຄຣິບໄດ້ຖືກຂະຫຍາຍອອກໄປເທື່ອລະກ້າວ
ເພື່ອສະຫນອງຄວາມເປັນໄປໄດ້ຫຼາຍ, ແຕ່ສິ່ງເຫຼົ່ານີ້ສ່ວນໃຫຍ່ໄດ້ຮັບຜິດຊອບເພື່ອ clutter ແລ້ວ
ພາ​ສາ overextended​. ເລື້ອຍໆ, ການກໍ່ສ້າງແມ່ນເຮັດໃນຫຼາຍຂັ້ນຕອນເພື່ອສະຫນອງ
ຜະລິດຕະພັນທີ່ເຫມາະສົມຈາກໄດເລກະທໍລີຫນຶ່ງໄປຫາລາຍຊື່ອື່ນ. ນີ້ເປັນຕົວແທນຕື່ມອີກ
ເພີ່ມ​ຂຶ້ນ​ໃນ​ການ​ສ້າງ​ຄວາມ​ສັບ​ສົນ​.

ສ້າງ ການສືບພັນ

ຂໍ້ຫ້າມຂອງທຸກສິ່ງທີ່ເຮັດໃຫ້ໄດ້ສະເຫມີເປັນການຈັດການທີ່ຖືກຕ້ອງຂອງການຂຶ້ນກັບ. ສ່ວນຫຼາຍມັກ, ກ
ຄວາມພະຍາຍາມແມ່ນເຮັດເພື່ອເຮັດວຽກທີ່ສົມເຫດສົມຜົນຂອງການເພິ່ງພາອາໄສພາຍໃນໄດເລກະທໍລີດຽວ, ແຕ່ບໍ່ແມ່ນ
ພະຍາຍາມຢ່າງຈິງຈັງເພື່ອເຮັດວຽກລະຫວ່າງໄດເລກະທໍລີ. ເຖິງແມ່ນວ່າໃນເວລາທີ່ການເພິ່ງພາອາໄສ
ການ​ເຮັດ​ວຽກ​ຢ່າງ​ຖືກ​ຕ້ອງ​, ເຮັດ​ໃຫ້​ການ​ອີງ​ໃສ່​ການ​ປຽບ​ທຽບ​ສະ​ແຕມ​ທີ່​ງ່າຍ​ດາຍ​ເພື່ອ​ກໍາ​ນົດ​ວ່າ​
ໄຟລ໌ທີ່ລ້າສະໄຫມກ່ຽວກັບຜູ້ເພິ່ງພາອາໄສຂອງມັນບໍ່ແມ່ນ, ໂດຍທົ່ວໄປ, ພຽງພໍສໍາລັບ
ກໍານົດເວລາທີ່ໄຟລ໌ຄວນຈະໄດ້ຮັບການ redered. ຖ້າຫ້ອງສະຫມຸດພາຍນອກ, ສໍາລັບການຍົກຕົວຢ່າງ, ແມ່ນ
ສ້າງຂຶ້ນໃໝ່ແລະຫຼັງຈາກນັ້ນ '`snapped' ເຂົ້າໄປໃນບ່ອນ, ການສະແຕມເວລາໃນໄຟລ໌ທີ່ສ້າງຂຶ້ນໃຫມ່ຂອງມັນອາດຈະ
ດີກ່ວາການກໍ່ສ້າງທ້ອງຖິ່ນສຸດທ້າຍ, ນັບຕັ້ງແຕ່ມັນຖືກສ້າງຂຶ້ນກ່ອນທີ່ມັນຈະເຫັນໄດ້ຊັດເຈນ.

variant ສ້າງຂຶ້ນ

Make ສະຫນອງພຽງແຕ່ສິ່ງອໍານວຍຄວາມສະດວກທີ່ຈໍາກັດສໍາລັບການຈັດການການກໍ່ສ້າງ variant. ກັບການຂະຫຍາຍຕົວ
ຂອງເວທີຮາດແວແລະຄວາມຕ້ອງການສໍາລັບການ debuggable ທຽບກັບລະຫັດ optimized, ຄວາມສາມາດ
ສ້າງຕົວແປເຫຼົ່ານີ້ໄດ້ຢ່າງງ່າຍດາຍແມ່ນມີຄວາມຈໍາເປັນ. ສິ່ງທີ່ ສຳ ຄັນກວ່ານັ້ນ, ຖ້າຕົວແປຖືກສ້າງຂື້ນ, ມັນ
ມັນເປັນສິ່ງ ສຳ ຄັນທີ່ຈະສາມາດແຍກຕົວແປຫຼືສາມາດແຜ່ພັນໄດ້
ຕົ້ນສະບັບຫຼື variant ຢູ່ໃນໃຈ. ດ້ວຍເຮັດໃຫ້ມັນຍາກຫຼາຍທີ່ຈະແຍກການກໍ່ສ້າງອອກເປັນ
ຫຼາຍ build directory, ແຍກອອກຈາກແຫຼ່ງ. ແລະຖ້າເຕັກນິກນີ້ບໍ່ໄດ້ໃຊ້,
ມັນຍັງເປັນໄປບໍ່ໄດ້ທີ່ຈະຮັບປະກັນໃນເວລາໃດນຶ່ງທີ່ຕົວແປມີຢູ່
ເປັນໄມ້ຢືນຕົ້ນ, ໂດຍບໍ່ມີການ resorting ກັບການກໍ່ສ້າງທີ່ສົມບູນ.

ບັນດາຫໍປະຊຸມ

Make ສະຫນອງການສະຫນັບສະຫນູນຈໍາກັດພຽງແຕ່ສໍາລັບການກໍ່ສ້າງຊອບແວຈາກລະຫັດທີ່ມີຢູ່ໃນ a
ໂຄງ​ປະ​ກອບ​ການ repository ສູນ​ກາງ​. ຄຸນສົມບັດ VPATH ຂອງ GNU ເຮັດ (ແລະບາງອັນອື່ນໆ
ເຮັດໃຫ້ການປະຕິບັດ) ມີຈຸດປະສົງເພື່ອສະຫນອງສິ່ງນີ້, ແຕ່ບໍ່ໄດ້ຜົນຕາມທີ່ຄາດໄວ້: ມັນ
ການປ່ຽນແປງເສັ້ນທາງຂອງໄຟລ໌ເປົ້າຫມາຍໄປຫາຊື່ VPATH ໄວເກີນໄປໃນການວິເຄາະຂອງມັນ, ແລະດັ່ງນັ້ນ
ຄົ້ນຫາທຸກສິ່ງທີ່ຂຶ້ນກັບຢູ່ໃນໄດເລກະທໍລີ VPATH. ເພື່ອຮັບປະກັນການພັດທະນາທີ່ຖືກຕ້ອງ
builds, ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະສາມາດສ້າງໄຟລ໌ໃນໄດເລກະທໍລີສ້າງທ້ອງຖິ່ນແລະມີ
ໄຟລ໌ໃດໆໃນບ່ອນເກັບລະຫັດ (ບັນຊີ VPATH, ໃນຂໍ້ກໍານົດ) ທີ່ຂຶ້ນກັບທ້ອງຖິ່ນ
ໄຟລ໌ໄດ້ຮັບການສ້າງໃຫມ່ຢ່າງຖືກຕ້ອງ. ອັນນີ້ເປັນໄປບໍ່ໄດ້ກັບ VPATH, ໂດຍບໍ່ມີການເຂົ້າລະຫັດຫຼາຍ
ຄວາມຮູ້ repository ສະລັບສັບຊ້ອນໂດຍກົງເຂົ້າໄປໃນ makefiles.

ການຮັກສາ it ງ່າຍດາຍ

ຄວາມຫຍຸ້ງຍາກຈໍານວນຫນຶ່ງຂອງການເຮັດໃຫ້ໄດ້ຖືກກ່າວເຖິງຂ້າງເທິງ. ໃນນີ້ແລະຕໍ່ມາ
ພາກສ່ວນ, ພວກເຮົາຈະແນະນໍາ Cons ແລະສະແດງໃຫ້ເຫັນວ່າບັນຫາເຫຼົ່ານີ້ຖືກແກ້ໄຂແນວໃດ.

Perl scripts

ຂໍ້ເສຍແມ່ນອີງໃສ່ Perl. ນັ້ນແມ່ນ, Cons scripts--ທະບຽນ ແລະ ກໍ່ສ້າງ ໄຟລ໌, ທຽບເທົ່າ
to makefile or makefile-- ທັງຫມົດແມ່ນຂຽນໃນ Perl. ນີ້ສະຫນອງຜົນປະໂຫຍດທັນທີ: ໄດ້
ພາສາສໍາລັບການຂຽນສະຄິບເປັນພາສາທີ່ຄຸ້ນເຄີຍ. ເຖິງແມ່ນວ່າເຈົ້າບໍ່ໄດ້ເປັນ Perl
ຜູ້ຂຽນໂປລແກລມ, ມັນຊ່ວຍໃຫ້ຮູ້ວ່າ Perl ແມ່ນພື້ນຖານພຽງແຕ່ເປັນພາສາປະກາດທີ່ງ່າຍດາຍ,
ດ້ວຍການໄຫລຂອງການຄວບຄຸມທີ່ຖືກກໍານົດໄວ້ດີ, ແລະຄວາມຫມາຍທີ່ຄຸ້ນເຄີຍ. ມັນມີຕົວແປທີ່ປະຕິບັດຕົວ
ໂດຍພື້ນຖານແລ້ວວິທີທີ່ທ່ານຈະຄາດຫວັງໃຫ້ພວກເຂົາ, subroutines, ການໄຫຼເຂົ້າຂອງການຄວບຄຸມ, ແລະອື່ນໆ. ຢູ່ທີ່ນັ້ນ
ບໍ່ມີ syntax ພິເສດທີ່ນໍາສະເຫນີສໍາລັບ Cons. ການໃຊ້ Perl ເປັນພາສາຂຽນ
simplifies ວຽກງານຂອງການສະແດງການແກ້ໄຂທີ່ເຫມາະສົມກັບສະລັບສັບຊ້ອນເລື້ອຍໆ
ຄວາມ​ຕ້ອງ​ການ​ຂອງ​ການ​ກໍ່​ສ້າງ​.

ສະບາຍດີ, ໂລກ!

ເພື່ອພື້ນຖານການສົນທະນາຕໍ່ໄປນີ້, ນີ້ແມ່ນວິທີທີ່ທ່ານສາມາດສ້າງ ສະບາຍດີ, ໂລກ! C
ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ທີ່​ມີ Cons​:

$env = new cons();
ໂຄງການ $env 'hello', 'hello.c';

ຖ້າທ່ານຕິດຕັ້ງສະຄິບນີ້ຢູ່ໃນໄດເລກະທໍລີ, ຕັ້ງຊື່ສະຄິບ ກໍ່ສ້າງ, ແລະສ້າງ
ສະບາຍດີ.c ແຫຼ່ງໄຟລ໌ໃນໄດເລກະທໍລີດຽວກັນ, ຫຼັງຈາກນັ້ນທ່ານສາມາດພິມ 'cons hello' ເພື່ອສ້າງ
ຄໍາຮ້ອງສະຫມັກ:

% cons ສະບາຍດີ
cc -c hello.c -o hello.o
cc -o ສະບາຍດີ hello.o

ການກໍ່ສ້າງ ສະພາບແວດລ້ອມ

A ຄວາມງ່າຍຂອງ cons ແມ່ນແນວຄວາມຄິດຂອງ a ການກໍ່ສ້າງ ສະພາບແວດລ້ອມ. ການກໍ່ສ້າງ
ສະພາບແວດລ້ອມເປັນ ຈຸດ​ປະ​ສົງ ມີລັກສະນະເປັນຊຸດຂອງຄູ່ຄີ/ມູນຄ່າ ແລະຊຸດຂອງ ວິທີການ.
ໃນຄໍາສັ່ງທີ່ຈະບອກ Cons ວິທີການສ້າງບາງສິ່ງບາງຢ່າງ, ທ່ານຮຽກຮ້ອງໃຫ້ວິທີການທີ່ເຫມາະສົມໂດຍຜ່ານ an
ສະພາບແວດລ້ອມການກໍ່ສ້າງທີ່ເຫມາະສົມ. ພິຈາລະນາຕົວຢ່າງຕໍ່ໄປນີ້:

$env = ຂໍ້ເສຍໃໝ່(
CC => 'gcc',
LIBS => 'libworld.a'
);

ໂຄງການ $env 'hello', 'hello.c';

ໃນກໍລະນີນີ້, ແທນທີ່ຈະໃຊ້ສະພາບແວດລ້ອມການກໍ່ສ້າງໃນຕອນຕົ້ນ, ຄືກັບວ່າພວກເຮົາມີ
overridden ຄ່າຂອງ 'CC' ເພື່ອໃຫ້ GNU C Compiler ທຽບເທົ່າຖືກໃຊ້ແທນ. ນັບຕັ້ງແຕ່
ສະ​ບັບ​ນີ້​ຂອງ​ ສະບາຍດີ, ໂລກ! ຕ້ອງ​ການ​ຫ້ອງ​ສະ​ຫມຸດ​, libworld.a, ພວກເຮົາໄດ້ລະບຸວ່າໃດໆ
ໂຄງການທີ່ເຊື່ອມໂຍງໃນສະພາບແວດລ້ອມນີ້ຄວນຈະເຊື່ອມຕໍ່ກັບຫ້ອງສະຫມຸດນັ້ນ. ຖ້າຫໍສະຫມຸດ
ມີຢູ່ແລ້ວ, ດີແລະດີ, ແຕ່ຖ້າບໍ່ແມ່ນ, ພວກເຮົາຍັງຈະຕ້ອງປະກອບຄໍາຖະແຫຼງທີ່:

ຫໍສະໝຸດ $env 'libworld', 'world.c';

ດຽວນີ້ຖ້າທ່ານພິມ 'cons hello', ຫ້ອງສະຫມຸດຈະຖືກສ້າງຂື້ນກ່ອນທີ່ໂຄງການຈະຖືກເຊື່ອມຕໍ່, ແລະ,
ແນ່ນອນ, 'gcc' ຈະຖືກນໍາໃຊ້ເພື່ອລວບລວມທັງສອງໂມດູນ:

% cons ສະບາຍດີ
gcc -c hello.c -o hello.o
gcc -c world.c -o world.o
ar r libworld.a world.o
ar: ການສ້າງ libworld.a
ranlib libworld.a
gcc -o ສະບາຍດີ hello.o libworld.a

ອັດຕະໂນມັດ ແລະ ສົມບູນ ການເພິ່ງພາອາໄສ ການວິເຄາະ

ດ້ວຍ Cons, ການເພິ່ງພາອາໄສຈະຖືກຈັດການໂດຍອັດຕະໂນມັດ. ສືບຕໍ່ຕົວຢ່າງທີ່ຜ່ານມາ, ຫມາຍເຫດ
ວ່າໃນເວລາທີ່ພວກເຮົາປັບປຸງແກ້ໄຂ world.c, world.o ຖືກລວບລວມຄືນ, libworld.a recreated, ແລະ ສະບາຍດີ
ເຊື່ອມຕໍ່ຄືນໃໝ່:

% vi world.c
[ແກ້ໄຂ]
% cons ສະບາຍດີ
gcc -c world.c -o world.o
ar r libworld.a world.o
ar: ການສ້າງ libworld.a
ranlib libworld.a
gcc -o ສະບາຍດີ hello.o libworld.a

ນີ້ແມ່ນຕົວຢ່າງທີ່ຂ້ອນຂ້າງງ່າຍດາຍ: Cons ``ຮູ້´ world.o ຂື້ນກັບ world.c, ເພາະວ່າ
ການເພິ່ງພາອາໄສແມ່ນຕັ້ງຂຶ້ນຢ່າງຈະແຈ້ງໂດຍວິທີການ 'ຫ້ອງສະໝຸດ'. ມັນຍັງຮູ້ວ່າ libworld.a
ຂື້ນກັບ world.o ແລະ​ນັ້ນ ສະບາຍດີ ຂື້ນກັບ libworld.a, ທັງຫມົດສໍາລັບເຫດຜົນທີ່ຄ້າຍຄືກັນ.

ໃນປັດຈຸບັນມັນ turns ໃຫ້ເຫັນວ່າ ສະບາຍດີ.c ຍັງປະກອບມີໄຟລ໌ຄໍານິຍາມຂອງການໂຕ້ຕອບ, world.h:

% emacs world.h
[ແກ້ໄຂ]
% cons ສະບາຍດີ
gcc -c hello.c -o hello.o
gcc -o ສະບາຍດີ hello.o libworld.a

Cons ຮູ້ໄດ້ແນວໃດ ສະບາຍດີ.c ປະກອບມີ world.h, ແລະ​ນັ້ນ ສະບາຍດີ ສະນັ້ນຕ້ອງເປັນ
ລວບລວມຄືນໃຫມ່? ສໍາລັບໃນປັດຈຸບັນ, ມັນພຽງພໍທີ່ຈະເວົ້າວ່າໃນເວລາທີ່ພິຈາລະນາບໍ່ວ່າຈະເປັນຫຼືບໍ່ ສະບາຍດີ ແມ່ນ​ຂຶ້ນ-
ມາຮອດປະຈຸ, Cons ຮຽກຮ້ອງເຄື່ອງສະແກນສໍາລັບການເພິ່ງພາອາໄສຂອງມັນ, ສະບາຍດີ.c. scanner ນີ້ enumerates ໄດ້
ໄຟລ໌ລວມໂດຍ ສະບາຍດີ.c ເພື່ອມາເຖິງບັນຊີລາຍຊື່ຂອງການເພິ່ງພາອາໄສເພີ່ມເຕີມ, ນອກເຫນືອຈາກນັ້ນ
ເຮັດຢ່າງຊັດເຈນໂດຍ Cons script. ຂະບວນການນີ້ແມ່ນ recursive: ໄຟລ໌ໃດໆລວມໂດຍ
ໄຟລ໌ລວມຈະຖືກສະແກນເຊັ່ນກັນ.

ອັນນີ້ບໍ່ແພງບໍ? ຄໍາຕອບແມ່ນ - ມັນຂຶ້ນກັບ. ຖ້າເຈົ້າສ້າງລະບົບໃຫຍ່ເຕັມຮູບແບບ
ເວລາສະແກນແມ່ນບໍ່ສໍາຄັນ. ຖ້າ​ຫາກ​ວ່າ​ທ່ານ​ເຮັດ​ການ​ຟື້ນ​ຟູ​ຂອງ​ລະ​ບົບ​ຂະ​ຫນາດ​ໃຫຍ່​, ຫຼັງ​ຈາກ​ນັ້ນ Cons ຈະ​
ໃຊ້ ເວ ລາ ເປັນ ຈໍາ ນວນ ເງິນ ທີ່ ເຫມາະ ສົມ ຂອງ ການ ຄິດ ກ່ຽວ ກັບ ມັນ ກ່ອນ ທີ່ ມັນ ຈະ ຕັດ ສິນ ໃຈ ວ່າ ບໍ່ ມີ ຫຍັງ ຈະ ເປັນ
ເຮັດແລ້ວ (ເຖິງແມ່ນວ່າບໍ່ຈໍາເປັນຕ້ອງໃຊ້ເວລາຫຼາຍກ່ວາເຮັດໃຫ້!). ຂ່າວດີແມ່ນວ່າ Cons ເຮັດໃຫ້ມັນ
ງ່າຍຫຼາຍທີ່ຈະສະຫຼາດຍ່ອຍສ້າງຂອງທ່ານ, ໃນເວລາທີ່ທ່ານກໍາລັງເຮັດວຽກກ່ຽວກັບການປ່ຽນແປງທ້ອງຖິ່ນ.

ອັດຕະໂນມັດ ທົ່ວໂລກ ການກໍ່ສ້າງ ລໍາດັບ

ເນື່ອງຈາກວ່າ Cons ເຮັດການວິເຄາະການເພິ່ງພາອາໄສຢ່າງເຕັມທີ່ແລະຖືກຕ້ອງ, ແລະເຮັດສິ່ງນີ້ທົ່ວໂລກ, ສໍາລັບ
ການກໍ່ສ້າງທັງຫມົດ, Cons ແມ່ນສາມາດນໍາໃຊ້ຂໍ້ມູນນີ້ເພື່ອຄວບຄຸມຢ່າງເຕັມທີ່ຂອງ ລໍາດັບ
ຂອງ​ການ​ກໍ່​ສ້າງ. ການຈັດລໍາດັບນີ້ແມ່ນເຫັນໄດ້ຊັດເຈນໃນຕົວຢ່າງຂ້າງເທິງ, ແລະທຽບເທົ່າກັບສິ່ງທີ່
ທ່ານຈະຄາດຫວັງສໍາລັບການເຮັດໃຫ້, ເນື່ອງຈາກຊຸດເຕັມຂອງການຂຶ້ນກັບ. ມີ Cons, ນີ້ຂະຫຍາຍ
ເລັກນ້ອຍເຖິງການສ້າງຫຼາຍໄດເລກະທໍລີທີ່ໃຫຍ່ກວ່າ. ດັ່ງນັ້ນ, ທັງຫມົດຂອງຄວາມສັບສົນທີ່ກ່ຽວຂ້ອງ
ເພື່ອເຮັດໃຫ້ແນ່ໃຈວ່າການກໍ່ສ້າງໄດ້ຖືກຈັດຢ່າງຖືກຕ້ອງ - ລວມທັງການຈັດລໍາດັບ multi-pass hierarchical
ການກໍ່ສ້າງ - ຖືກລົບລ້າງ. ພວກເຮົາຈະປຶກສາຫາລືເລື່ອງນີ້ຕື່ມອີກໃນພາກຕໍ່ໄປ.

ການກໍ່ສ້າງ ຂະຫນາດໃຫຍ່ ຕົ້ນໄມ້ - ຍັງ ພຽງແຕ່ as ງ່າຍດາຍ

A ລຳ ດັບຊັ້ນ of ການກໍ່ສ້າງ scripts

ການກໍ່ສ້າງຂະຫນາດໃຫຍ່, ໃນ Cons, ຖືກຈັດໂດຍການສ້າງລໍາດັບຊັ້ນຂອງ ການກໍ່ສ້າງ scripts. ຢູ່ເທິງສຸດ
ຂອງຕົ້ນໄມ້ແມ່ນ script ເອີ້ນວ່າ ກໍ່ສ້າງ. ສ່ວນທີ່ເຫຼືອຂອງສະຄິບ, ໂດຍສົນທິສັນຍາ, ແມ່ນແຕ່ລະຄົນ
ເອີ້ນວ່າ ທະບຽນ. ສະຄຣິບເຫຼົ່ານີ້ຖືກເຊື່ອມຕໍ່ກັນ, ງ່າຍດາຍຫຼາຍ, ໂດຍ 'ສ້າງ',
ຄໍາສັ່ງ 'ສົ່ງອອກ' ແລະ 'ນໍາເຂົ້າ'.

ໄດ້ ສ້າງ ຄໍາສັ່ງ

ຄໍາສັ່ງ 'ສ້າງ' ເອົາບັນຊີລາຍຊື່ຂອງ ທະບຽນ ຊື່ໄຟລ໌, ແລະຈັດໃຫ້ພວກເຂົາເປັນ
ລວມຢູ່ໃນການກໍ່ສ້າງ. ຍົກ​ຕົວ​ຢ່າງ:

ສ້າງ qw(
ໄດເວີ / ຈໍສະແດງຜົນ / Conscript
ຄົນຂັບ/ເມົາສ໌/Conscript
parser/Conscript
utilities/Conscript
);

ນີ້ແມ່ນລໍາດັບຊັ້ນສອງຊັ້ນທີ່ງ່າຍດາຍຂອງສະຄິບກໍ່ສ້າງ: ບໍລິສັດຍ່ອຍທັງຫມົດ ທະບຽນ ໄຟ
ໄດ້ຖືກກ່າວເຖິງໃນລະດັບສູງສຸດ ກໍ່ສ້າງ ໄຟລ໌. ສັງເກດເຫັນວ່າບໍ່ແມ່ນໄດເລກະທໍລີທັງຫມົດໃນຕົ້ນໄມ້
ຈໍາເປັນຕ້ອງມີ build script ທີ່ກ່ຽວຂ້ອງກັບພວກມັນ.

ນີ້ຍັງສາມາດຂຽນເປັນ script ຫຼາຍລະດັບ. ສໍາລັບຕົວຢ່າງ, ໄດ້ ກໍ່ສ້າງ ໄຟລ໌ອາດຈະ
ມີຄໍາສັ່ງນີ້:

ສ້າງ qw(
parser/Conscript
ຄົນຂັບ/Conscript
utilities/Conscript
);

ແລະ ທະບຽນ ໄຟລ໌ໃນ ຄົນຂັບລົດ ໄດເລກະທໍລີອາດມີອັນນີ້:

ສ້າງ qw(
ສະແດງ/Conscript
ຫນູ / Conscript
);

ປະສົບການໄດ້ສະແດງໃຫ້ເຫັນວ່າຕົວແບບໃນອະດີດແມ່ນເລັກນ້ອຍງ່າຍທີ່ຈະເຂົ້າໃຈ, ນັບຕັ້ງແຕ່
ຕົ້ນໄມ້ກໍ່ສ້າງທັງໝົດຖືກວາງໄວ້ຢູ່ຕໍ່ໜ້າເຈົ້າ, ໃນລະດັບສູງສຸດ. ໂຄງ​ການ​ປະ​ສົມ​ແມ່ນ​
ຍັງເປັນໄປໄດ້. ອົງປະກອບທີ່ຮັກສາໄວ້ແຍກຕ່າງຫາກທີ່ຈໍາເປັນຕ້ອງຖືກລວມເຂົ້າໃນ a
ການກໍ່ສ້າງຕົ້ນໄມ້, ສໍາລັບຕົວຢ່າງ, ອາດຈະຕິດກັບຕົ້ນໄມ້ກໍ່ສ້າງຢູ່ໃນສະຖານທີ່ຫນຶ່ງ, ແຕ່ກໍານົດຂອງມັນເອງ
ລຳດັບຊັ້ນກໍ່ສ້າງ.

ໂດຍຄ່າເລີ່ມຕົ້ນ, Cons ບໍ່ປ່ຽນໄດເລກະທໍລີທີ່ເຮັດວຽກຂອງມັນໄປຫາໄດເລກະທໍລີທີ່ມີ a
ບໍລິສັດຍ່ອຍ ທະບຽນ ໄຟລ໌ມັນແມ່ນລວມທັງ. ພຶດຕິກໍານີ້ສາມາດຖືກເປີດໃຊ້ສໍາລັບການກໍ່ສ້າງໂດຍ
ການລະບຸ, ໃນລະດັບສູງສຸດ ກໍ່ສ້າງ file:

Conscript_chdir 1;

ເມື່ອເປີດໃຊ້, Cons ຈະປ່ຽນເປັນບໍລິສັດຍ່ອຍ ທະບຽນ ໄຟລ໌ທີ່ປະກອບດ້ວຍໄດເລກະທໍລີ
ໃນ​ຂະ​ນະ​ທີ່​ການ​ອ່ານ​ໃນ​ໄຟລ​໌​ນັ້ນ​, ແລະ​ຫຼັງ​ຈາກ​ນັ້ນ​ປ່ຽນ​ກັບ​ຄືນ​ໄປ​ບ່ອນ​ລະ​ດັບ​ສູງ​ສຸດ​ຄັ້ງ​ໄຟລ​໌​
ໄດ້ຮັບການປຸງແຕ່ງ.

ຄາດວ່າພຶດຕິກໍານີ້ຈະກາຍເປັນຄ່າເລີ່ມຕົ້ນໃນບາງລຸ້ນ Cons ໃນອະນາຄົດ.
ເພື່ອກະກຽມສໍາລັບການຫັນປ່ຽນນີ້, ການກໍ່ສ້າງທີ່ຄາດຫວັງວ່າ Cons ຈະຍັງຄົງຢູ່ເທິງສຸດຂອງການກໍ່ສ້າງ
ໃນຂະນະທີ່ມັນອ່ານຢູ່ໃນບໍລິສັດຍ່ອຍ ທະບຽນ ໄຟລ໌ຄວນປິດການໃຊ້ງານຄຸນສົມບັດນີ້ເປັນຢ່າງຈະແຈ້ງ
ຕໍ່ໄປນີ້:

Conscript_chdir 0;

ພີ່ນ້ອງ, ຍາດຕິພີ່ນ້ອງສູງສຸດ, ແລະ ຢ່າງແທ້ຈິງ ເອກະສານ ຊື່

ທ່ານອາດຈະສັງເກດເຫັນວ່າຊື່ໄຟລ໌ທີ່ລະບຸໄວ້ໃນຄໍາສັ່ງ Build ແມ່ນກ່ຽວຂ້ອງກັບ
ສະ​ຖານ​ທີ່​ຂອງ script ທີ່​ມັນ​ໄດ້​ຖືກ​ຮຽກ​ຮ້ອງ​ຈາກ​. ໂດຍທົ່ວໄປແລ້ວນີ້ແມ່ນຄວາມຈິງສໍາລັບຊື່ໄຟລ໌ອື່ນ
ການໂຕ້ຖຽງກັບຄໍາສັ່ງອື່ນໆ, ເຊັ່ນດຽວກັນ, ເຖິງແມ່ນວ່າພວກເຮົາອາດຈະກ່າວເຖິງໃນທີ່ນີ້ວ່າຖ້າທ່ານເລີ່ມຕົ້ນ
ຊື່​ໄຟລ​໌​ທີ່​ມີ​ເຄື່ອງ​ຫມາຍ hash​, `` # ''​, ຫຼັງ​ຈາກ​ນັ້ນ​ໄຟລ​໌​ທີ່​ຖືກ​ຕີ​ລາ​ຄາ​ສົມ​ທຽບ​ກັບ​ທາງ​ເທິງ​.
ລະ​ດັບ​ການ​ລະ​ດັບ (ບ່ອນ​ທີ່ ກໍ່ສ້າງ ໄຟລ໌ຢູ່). ແລະ, ບໍ່ແປກໃຈ, ຖ້າທ່ານເລີ່ມຕົ້ນມັນ
ດ້ວຍ ``/'', ຫຼັງຈາກນັ້ນມັນຖືກພິຈາລະນາວ່າເປັນຊື່ເສັ້ນທາງຢ່າງແທ້ຈິງ. ນີ້ແມ່ນຄວາມຈິງເຖິງແມ່ນວ່າຢູ່ໃນລະບົບ
ເຊິ່ງໃຊ້ສະໄລ້ດ້ານຫຼັງແທນທີ່ຈະເປັນເຄື່ອງໝາຍໜ້າເພື່ອຕັ້ງຊື່ເສັ້ນທາງຢ່າງແທ້ຈິງ.

ການນໍາໃຊ້ ໂມດູນ in ການກໍ່ສ້າງ scripts

ທ່ານອາດຈະດຶງໂມດູນເຂົ້າໄປໃນແຕ່ລະ ທະບຽນ ໄຟລ໌ໂດຍໃຊ້ Perl ປົກກະຕິ 'ໃຊ້' ຫຼື 'ຕ້ອງການ'
ຖະແຫຼງການ:

ໃຊ້ພາສາອັງກິດ;
ຕ້ອງການຂອງຂ້ອຍ::ໂມດູນ;

ແຕ່ລະ 'ໃຊ້' ຫຼື 'ຕ້ອງການ' ມີຜົນກະທົບພຽງແຕ່ຫນຶ່ງ ທະບຽນ ໄຟລ໌ທີ່ມັນປາກົດ. ການ​ນໍາ​ໃຊ້ a
ໂມດູນໃນຫຼາຍ ທະບຽນ ໄຟລ໌, ທ່ານຕ້ອງໃສ່ຄໍາຖະແຫຼງທີ່ 'ໃຊ້' ຫຼື 'ຕ້ອງການ' ໃນແຕ່ລະ
ຫນຶ່ງທີ່ຕ້ອງການໂມດູນ.

ຂອບເຂດ of ຕົວແປ

ລະດັບສູງສຸດ ກໍ່ສ້າງ ໄຟລ໌ ແລະທັງໝົດ ທະບຽນ ໄຟລ໌ເລີ່ມຕົ້ນຊີວິດໃນ Perl ທົ່ວໄປ, ແຍກຕ່າງຫາກ
package cons ຄວບຄຸມຕາຕະລາງສັນຍາລັກສໍາລັບຊຸດດັ່ງນັ້ນ, ຕາຕະລາງສັນຍາລັກສໍາລັບ
ແຕ່ລະສະຄຣິບແມ່ນຫວ່າງເປົ່າ, ຍົກເວັ້ນ ກໍ່ສ້າງ ໄຟລ໌, ເຊິ່ງໄດ້ຮັບບາງເສັ້ນຄໍາສັ່ງ
ການໂຕ້ຖຽງ. ທຸກໆຕົວແປທີ່ຖືກກໍານົດຫຼືໃຊ້, ດັ່ງນັ້ນ, ຖືກກໍານົດໂດຍ script
ຕົວຂອງມັນເອງ - ບໍ່ແມ່ນໂດຍສະຄິບພາຍນອກບາງອັນ.

ຕົວແປສາມາດເຫັນໄດ້ຊັດເຈນ ນຳ ເຂົ້າ ໂດຍສະຄຣິບຈາກສະຄຣິບຫຼັກຂອງມັນ. ການ​ນໍາ​ເຂົ້າ a
ຕົວແປ, ມັນຕ້ອງເປັນ ສົ່ງອອກ ໂດຍພໍ່ແມ່ແລະເລີ່ມຕົ້ນ (ຖ້າບໍ່ດັ່ງນັ້ນຄວາມຜິດພາດ
ຈະ​ເກີດ​ຂຶ້ນ).

ໄດ້ ການສົ່ງອອກ ຄໍາສັ່ງ

ຄໍາສັ່ງ 'ສົ່ງອອກ' ຖືກນໍາໃຊ້ໃນຕົວຢ່າງຕໍ່ໄປນີ້:

$env = new cons();
$INCLUDE = "#export/include";
$LIB = "#export/lib";
ສົ່ງອອກ q( env ລວມ LIB );
ສ້າງ qw(util/Conscript );

ຄ່າຂອງຕົວແປງ່າຍໆທີ່ໄດ້ກ່າວໄວ້ໃນລາຍການ 'ສົ່ງອອກ' ຈະຖືກກະຮອກອອກໄປ
ໂດຍຄໍາສັ່ງ 'ສ້າງ' ຕໍ່ມາ. ຄໍາສັ່ງ 'ສົ່ງອອກ' ຈະສົ່ງອອກພຽງແຕ່ Perl ຜິວ ໜັງ
ຕົວແປ, ນັ້ນແມ່ນ, ຕົວແປທີ່ຊື່ເລີ່ມຕົ້ນດ້ວຍ `$'. ຕົວແປອື່ນໆ, ວັດຖຸ, ແລະອື່ນໆ.
ສາມາດຖືກສົ່ງອອກໂດຍການອ້າງອີງ - ແຕ່ສະຄິບທັງຫມົດຈະອ້າງອີງເຖິງວັດຖຸດຽວກັນ, ແລະນີ້
ວັດຖຸຄວນຖືກພິຈາລະນາໃຫ້ອ່ານຢ່າງດຽວໂດຍສະຄຣິບຍ່ອຍ ແລະໂດຍຕົ້ນສະບັບ
script ການ​ສົ່ງ​ອອກ​. ຢ່າງໃດກໍຕາມ, ມັນເປັນການຍອມຮັບທີ່ຈະກໍານົດມູນຄ່າໃຫມ່ໃຫ້ກັບ scalar ທີ່ສົ່ງອອກ
ຕົວແປ--ທີ່ຈະບໍ່ປ່ຽນແປງຕົວແປທີ່ອ້າງອີງ. ລໍາດັບນີ້, ສໍາລັບ
ຕົວຢ່າງ, ແມ່ນ OK:

$env = new cons();
ສົ່ງອອກ q( env ລວມ LIB );
ສ້າງ qw(util/Conscript );
$env = new cons(CFLAGS => '-O');
ສ້າງ qw(ອື່ນໆ/Conscript );

ມັນບໍ່ສໍາຄັນວ່າຕົວແປຈະຖືກກໍານົດກ່ອນຫຼືຫຼັງຈາກຄໍາສັ່ງ 'ສົ່ງອອກ'. ໄດ້
ສິ່ງທີ່ສໍາຄັນແມ່ນມູນຄ່າຂອງຕົວແປໃນເວລາທີ່ຄໍາສັ່ງ 'Build' ຖືກປະຕິບັດ.
ນີ້ແມ່ນສິ່ງທີ່ກະຮອກອອກໄປ. ທຸກໆຄໍາສັ່ງ 'ສົ່ງອອກ' ຕໍ່ມາ, ໂດຍວິທີທາງການ,
invalidate ທໍາອິດ: ທ່ານຕ້ອງກ່າວເຖິງຕົວແປທັງຫມົດທີ່ທ່ານຕ້ອງການທີ່ຈະສົ່ງອອກໃນແຕ່ລະ
ຄໍາສັ່ງ 'ສົ່ງອອກ'.

ໄດ້ ການນໍາເຂົ້າ ຄໍາສັ່ງ

ຕົວແປທີ່ສົ່ງອອກໂດຍຄໍາສັ່ງ 'ສົ່ງອອກ' ສາມາດຖືກນໍາເຂົ້າເຂົ້າໄປໃນສະຄິບຍ່ອຍໂດຍ
ຄໍາສັ່ງ 'ນໍາເຂົ້າ'. script ຍ່ອຍສະເຫມີນໍາເຂົ້າຕົວແປໂດຍກົງຈາກ
script ດີກວ່າ. ພິຈາລະນາຕົວຢ່າງນີ້:

ນຳເຂົ້າ q(env INCLUDE );

ອັນນີ້ແມ່ນຖືກຕ້ອງຕາມກົດໝາຍເທົ່ານັ້ນຫາກສະຄຣິບຫຼັກສົ່ງອອກທັງ `$env' ແລະ `$INCLUDE'. ມັນຍັງຕ້ອງ
ໄດ້ໃຫ້ແຕ່ລະຄ່າຂອງຕົວແປເຫຼົ່ານີ້. ມັນເໝາະສົມສຳລັບສະຄຣິບຍ່ອຍເທົ່ານັ້ນ
ນໍາເຂົ້າຊຸດຍ່ອຍຂອງຕົວແປທີ່ສົ່ງອອກ (ໃນຕົວຢ່າງນີ້, `$LIB', ເຊິ່ງຖືກສົ່ງອອກໂດຍ
ຕົວຢ່າງທີ່ຜ່ານມາ, ບໍ່ໄດ້ນໍາເຂົ້າ).

ທຸກຕົວແປທີ່ນໍາເຂົ້າຈະຖືກສົ່ງອອກຄືນໃຫມ່ໂດຍອັດຕະໂນມັດ, ດັ່ງນັ້ນລໍາດັບ:

ນໍາເຂົ້າ qw ( env ລວມ );
ສ້າງ qw (ຢູ່ລຸ່ມ-ຂ້ອຍ/Conscript);

ຈະສະໜອງທັງ `$env' ແລະ `$INCLUDE' ໃຫ້ກັບໄຟລ໌ຍ່ອຍ. ຖ້າພຽງແຕ່ '$env' ຈະເປັນ
ສົ່ງອອກ, ຫຼັງຈາກນັ້ນດັ່ງຕໍ່ໄປນີ້ຈະພຽງພໍ:

ນໍາເຂົ້າ qw ( env ລວມ );
ສົ່ງອອກ q ( env );
ສ້າງ qw (ຢູ່ລຸ່ມ-ຂ້ອຍ/Conscript);

ບໍ່ຈໍາເປັນຕ້ອງເວົ້າ, ຕົວແປອາດຈະຖືກແກ້ໄຂໃນທ້ອງຖິ່ນກ່ອນທີ່ຈະເອີ້ນ 'ສ້າງ' ໃນ
script ຍ່ອຍ.

ສ້າງ script ການປະເມີນຜົນ ຄໍາສັ່ງ

ຂໍ້ຈໍາກັດພຽງແຕ່ໃນຄໍາສັ່ງຂອງ build scripts ແມ່ນວ່າ scripts ດີກວ່າ
ປະເມີນກ່ອນ script inferior ຂອງເຂົາເຈົ້າ. ລະດັບສູງສຸດ ກໍ່ສ້າງ ໄຟລ໌, ສໍາລັບການຍົກຕົວຢ່າງ, ແມ່ນ
ຖືກປະເມີນກ່ອນ, ຕິດຕາມດ້ວຍຕົວອັກສອນທີ່ຕໍ່າກວ່າໃດໆ. ນີ້ແມ່ນທັງຫມົດທີ່ເຈົ້າຕ້ອງການຮູ້ແທ້ໆ
ກ່ຽວກັບຄໍາສັ່ງການປະເມີນຜົນ, ເນື່ອງຈາກວ່າຄໍາສັ່ງໂດຍທົ່ວໄປແມ່ນບໍ່ກ່ຽວຂ້ອງ. ພິຈາລະນາຕໍ່ໄປນີ້
ຄໍາສັ່ງ 'ສ້າງ':

ສ້າງ qw(
ໄດເວີ / ຈໍສະແດງຜົນ / Conscript
ຄົນຂັບ/ເມົາສ໌/Conscript
parser/Conscript
utilities/Conscript
);

ພວກເຮົາໄດ້ເລືອກໃສ່ຊື່ສະຄຣິບຕາມລຳດັບຕົວອັກສອນ, ເພາະວ່ານັ້ນແມ່ນຫຼາຍທີ່ສຸດ
ສະດວກສໍາລັບຈຸດປະສົງບໍາລຸງຮັກສາ. ການປ່ຽນແປງຄໍາສັ່ງຈະບໍ່ແຕກຕ່າງກັນ
ກໍ່ສ້າງ.

A ຮູບແບບ ສໍາລັບການ ການແລກປ່ຽນ ໄຟ

ບາງ ງ່າຍດາຍ ອະນຸສັນຍາ

ໃນລະບົບຊອບແວທີ່ສັບສົນໃດໆ, ວິທີການແບ່ງປັນຜະລິດຕະພັນກໍ່ສ້າງຕ້ອງມີ
ສ້າງຕັ້ງຂຶ້ນ. ພວກ​ເຮົາ​ສະ​ເຫນີ​ບັນ​ດາ​ສົນ​ທິ​ສັນ​ຍາ​ທີ່​ງ່າຍ​ດາຍ​ທີ່​ບໍ່​ສໍາ​ຄັນ​ເພື່ອ​ປະ​ຕິ​ບັດ​ກັບ​
Cons, ແຕ່ປະສິດທິພາບຫຼາຍ.

ກົດ​ລະ​ບຽບ​ພື້ນ​ຖານ​ແມ່ນ​ຕ້ອງ​ການ​ຜະ​ລິດ​ຕະ​ພັນ​ການ​ກໍ່​ສ້າງ​ທັງ​ຫມົດ​ທີ່​ຈໍາ​ເປັນ​ຕ້ອງ​ໄດ້​ຮັບ​ການ​ແບ່ງ​ປັນ​ລະ​ຫວ່າງ​
ໄດເລກະທໍລີຖືກແບ່ງປັນຜ່ານໄດເລກະທໍລີລະດັບກາງ. ໂດຍທົ່ວໄປແລ້ວພວກເຮົາເອີ້ນວ່າອັນນີ້
ການສົ່ງອອກ, ແລະ, ໃນສະພາບແວດລ້ອມ C, ສະຫນອງການຍ່ອຍແບບທໍາມະດາຂອງໄດເລກະທໍລີນີ້,
ເຊັ່ນ​ວ່າ ປະກອບດ້ວຍ, lib, ເຈົ້າ, ແລະອື່ນໆ

ໄດເລກະທໍລີເຫຼົ່ານີ້ຖືກກໍານົດໂດຍລະດັບສູງສຸດ ກໍ່ສ້າງ ໄຟລ໌. ງ່າຍດາຍ ກໍ່ສ້າງ file for
a ສະບາຍດີ, ໂລກ! ແອັບພລິເຄຊັນ, ຈັດລະບຽບໂດຍໃຊ້ຫຼາຍໄດເລກະທໍລີ, ອາດຈະເບິ່ງຄືວ່ານີ້:

# ສ້າງໄຟລ໌ສໍາລັບສະບາຍດີ, ໂລກ!

# ບ່ອນໃດວາງສິນຄ້າທີ່ແບ່ງປັນຂອງພວກເຮົາທັງຫມົດ.
$EXPORT = '#ສົ່ງອອກ';

ສົ່ງອອກ q(CONS ລວມມີ LIB BIN );

# ໄດເລກະທໍລີມາດຕະຖານສໍາລັບການແບ່ງປັນຜະລິດຕະພັນ.
$INCLUDE = "$EXPORT/ລວມ";
$LIB = "$EXPORT/lib";
$BIN = "$EXPORT/bin";

# ສະພາບແວດລ້ອມການກໍ່ສ້າງມາດຕະຖານ.
$CONS = ຂໍ້ເສຍໃໝ່ (
CPPPATH => $INCLUDE, # ລວມເສັ້ນທາງສຳລັບການລວບລວມຂໍ້ມູນ C
LIBPATH => $LIB, # ເສັ້ນທາງຫ້ອງສະໝຸດສຳລັບໂຄງການເຊື່ອມຕໍ່
LIBS => '-lworld', # ລາຍຊື່ຫ້ອງສະໝຸດມາດຕະຖານ
);

ສ້າງ qw(
ສະບາຍດີ/Conscript
ໂລກ/Conscript
);

ໄດ້ ໂລກ ໄດເລກະທໍລີ ທະບຽນ ໄຟລ໌ເບິ່ງຄືວ່ານີ້:

# ໄຟລ໌ Conscript ສໍາລັບໂລກໄດເລກະທໍລີ
ນຳເຂົ້າ q(CONS INCLUDE LIB );

# ຕິດຕັ້ງຜະລິດຕະພັນຂອງໄດເລກະທໍລີນີ້
ຕິດຕັ້ງ $CONS $LIB, 'libworld.a';
ຕິດຕັ້ງ $CONS $INCLUDE, 'world.h';

#ສິນຄ້າພາຍໃນ
ຫໍສະໝຸດ $CONS 'libworld.a', 'world.c';

ແລະ ສະບາຍດີ ໄດເລກະທໍລີ ທະບຽນ ໄຟລ໌ເບິ່ງຄືວ່ານີ້:

# ໄຟລ໌ conscript ສໍາລັບ directory ສະບາຍດີ
ນໍາເຂົ້າ qw(CONS BIN );

#ສິນຄ້າສົ່ງອອກ
ຕິດຕັ້ງ $CONS $BIN, 'ສະບາຍດີ';

#ສິນຄ້າພາຍໃນ
ໂຄງການ $CONS 'ສະບາຍດີ', 'hello.c';

ການກໍ່ສ້າງກ ສະບາຍດີ, ໂລກ! ໂຄງການທີ່ມີໂຄງສ້າງໄດເລກະທໍລີນີ້, ໄປຫາລະດັບສູງສຸດ
ໄດເລກະທໍລີ, ແລະເອີ້ນ 'cons' ດ້ວຍການໂຕ້ຖຽງທີ່ເຫມາະສົມ. ໃນຕົວຢ່າງຕໍ່ໄປນີ້, ພວກເຮົາ
ບອກ Cons ເພື່ອສ້າງໄດເລກະທໍລີ ການສົ່ງອອກ. ເພື່ອສ້າງໄດເລກະທໍລີ, Cons recursively ກໍ່ສ້າງທັງຫມົດ
ຜະລິດຕະພັນທີ່ຮູ້ຈັກພາຍໃນໄດເລກະທໍລີນັ້ນ (ພຽງແຕ່ຖ້າພວກເຂົາຕ້ອງການສ້າງໃຫມ່, ແນ່ນອນ). ຖ້າມີ
ຜະ​ລິດ​ຕະ​ພັນ​ເຫຼົ່າ​ນັ້ນ​ແມ່ນ​ຂຶ້ນ​ກັບ​ຜະ​ລິດ​ຕະ​ພັນ​ອື່ນໆ​ໃນ​ບັນ​ຊີ​ລາຍ​ການ​ອື່ນໆ​, ຫຼັງ​ຈາກ​ນັ້ນ​ສິ່ງ​ທີ່​ຈະ​ສ້າງ​ຂຶ້ນ​,
ເຊັ່ນດຽວກັນ.

% cons ສົ່ງອອກ
ຕິດຕັ້ງ world/world.h ເປັນ export/include/world.h
cc -Iexport/include -c hello/hello.c -o hello/hello.o
cc -Iexport/include -c world/world.c -o world/world.o
ar r world/libworld.a world/world.o
ar: ການສ້າງໂລກ/libworld.a
ranlib world/libworld.a
ຕິດຕັ້ງ world/libworld.a ເປັນ export/lib/libworld.a
cc -o hello/hello hello/hello.o -Lexport/lib -lworld
ຕິດຕັ້ງ hello/hello ເປັນ export/bin/hello

ສະອາດ, ເຂົ້າ​ໃຈ​ໄດ້​, ສະ​ຖານ​ທີ່​ເປັນ​ເອ​ກະ​ລາດ​ scripts

ທ່ານຈະສັງເກດວ່າທັງສອງ ທະບຽນ ໄຟລ໌ແມ່ນສະອາດຫຼາຍແລະກົງກັບຈຸດ. ພວກເຂົາພຽງແຕ່
ລະບຸຜະລິດຕະພັນຂອງໄດເລກະທໍລີແລະວິທີການສ້າງຜະລິດຕະພັນເຫຼົ່ານັ້ນ. ຄໍາແນະນໍາການກໍ່ສ້າງ
ແມ່ນຫນ້ອຍທີ່ສຸດ: ພວກເຂົາກໍານົດສະພາບແວດລ້ອມການກໍ່ສ້າງທີ່ຈະນໍາໃຊ້, ຊື່ຂອງຜະລິດຕະພັນ,
ແລະຊື່ຂອງວັດສະດຸປ້ອນ. ໃຫ້ສັງເກດວ່າສະຄິບແມ່ນຂຶ້ນກັບສະຖານທີ່: ຖ້າເຈົ້າ
ປາດຖະຫນາທີ່ຈະຈັດລະບຽບຕົ້ນໄມ້ແຫຼ່ງຂອງທ່ານ, ທ່ານມີອິດສະຫຼະທີ່ຈະເຮັດແນວນັ້ນ: ທ່ານພຽງແຕ່ມີການປ່ຽນແປງ
ກໍ່ສ້າງ ໄຟລ໌ (ໃນຕົວຢ່າງນີ້), ເພື່ອກໍານົດສະຖານທີ່ໃຫມ່ຂອງ ທະບຽນ ແຟ້ມ. ທ
ການນໍາໃຊ້ຕົ້ນໄມ້ສົ່ງອອກເຮັດໃຫ້ເປົ້າຫມາຍນີ້ງ່າຍ.

ຫມາຍເຫດ, ເຊັ່ນດຽວກັນ, ວິທີການ Cons ດູແລລາຍລະອຽດເລັກນ້ອຍສໍາລັບທ່ານ. ທັງໝົດ ການສົ່ງອອກ ໄດເລກະທໍລີ, ສໍາລັບ
ຕົວຢ່າງ, ຖືກສ້າງຂື້ນໂດຍອັດຕະໂນມັດ. ແລະໄຟລ໌ທີ່ຕິດຕັ້ງໄດ້ຖືກເຊື່ອມຕໍ່ຍາກແທ້ໆເຂົ້າໄປໃນ
ໄດເລກະທໍລີສົ່ງອອກຕາມລໍາດັບ, ເພື່ອຊ່ວຍປະຢັດພື້ນທີ່ແລະເວລາ. ຄວາມສົນໃຈກັບລາຍລະອຽດນີ້ຊ່ວຍປະຢັດ
ວຽກງານຫຼາຍ, ແລະເຮັດໃຫ້ມັນງ່າຍຂຶ້ນໃນການຜະລິດສະຄິບທີ່ງ່າຍດາຍ, ສາມາດຮັກສາໄດ້.

ການແຍກຕ່າງຫາກ ແຫຼ່ງ ແລະ ການກໍ່ສ້າງ ຕົ້ນໄມ້

ມັນມັກຈະເປັນຄວາມປາຖະຫນາທີ່ຈະຮັກສາໄຟລ໌ທີ່ມາຈາກການກໍ່ສ້າງແຍກຕ່າງຫາກຢ່າງສົມບູນຈາກ
ໄຟລ໌ແຫຼ່ງ. ນີ້ເຮັດໃຫ້ມັນງ່າຍຂຶ້ນຫຼາຍທີ່ຈະຕິດຕາມພຽງແຕ່ສິ່ງທີ່ເປັນໄຟລ໌ແຫຼ່ງ, ແລະ
ຍັງເຮັດໃຫ້ມັນງ່າຍຕໍ່ການຈັດການ variant ການກໍ່ສ້າງ, ໂດຍສະເພາະຖ້າຫາກວ່າທ່ານຕ້ອງການ variant builds
ຢູ່ຮ່ວມກັນ.

ການແຍກຕ່າງຫາກ ການກໍ່ສ້າງ ແລະ ແຫຼ່ງ ໄດເລກະທໍລີ ການນໍາໃຊ້ ໄດ້ ການເຊື່ອມຕໍ່ ຄໍາສັ່ງ

Cons ສະຫນອງກົນໄກທີ່ງ່າຍດາຍທີ່ຈັດການກັບຄວາມຕ້ອງການເຫຼົ່ານີ້ທັງຫມົດ. ລິ້ງຄ໌
ຄໍາສັ່ງແມ່ນ invoked ໃນຕົວຢ່າງນີ້:

ເຊື່ອມຕໍ່ 'build' => 'src';

ໄດເລກະທໍລີທີ່ລະບຸໄວ້ແມ່ນ ``ເຊື່ອມຕໍ່'' ກັບໄດເລກະທໍລີແຫຼ່ງທີ່ລະບຸ. ສົມມຸດວ່າ
ທີ່ທ່ານຕັ້ງໄດເລກະທໍລີແຫຼ່ງ, src, ກັບໄດເລກະທໍລີຍ່ອຍ ໂລກ ແລະ ສະບາຍດີ ຂ້າງ​ລຸ່ມ​ນີ້​,
ໃນຕົວຢ່າງທີ່ຜ່ານມາ. ຫຼັງຈາກນັ້ນທ່ານສາມາດທົດແທນສໍາລັບສາຍການກໍ່ສ້າງຕົ້ນສະບັບໄດ້
ຕໍ່ໄປນີ້:

ສ້າງ qw(
build/world/Conscript
build/hello/Conscript
);

ສັງເກດເຫັນວ່າທ່ານປິ່ນປົວພະຍາດ ທະບຽນ ໄຟລ໌ຄືກັບວ່າມັນມີຢູ່ໃນໄດເລກະທໍລີສ້າງ. ໃນປັດຈຸບັນຖ້າຫາກວ່າ
ທ່ານພິມຄໍາສັ່ງດຽວກັນກັບກ່ອນ, ທ່ານຈະໄດ້ຮັບຜົນໄດ້ຮັບດັ່ງຕໍ່ໄປນີ້:

% cons ສົ່ງອອກ
ຕິດຕັ້ງ build/world/world.h ເປັນ export/include/world.h
cc -Iexport/include -c build/hello/hello.c -o build/hello/hello.o
cc -Iexport/include -c build/world/world.c -o build/world/world.o
ar r build/world/libworld.a build/world/world.o
ar: ການສ້າງ build/world/libworld.a
ranlib build/world/libworld.a
ຕິດຕັ້ງ build/world/libworld.a ເປັນ export/lib/libworld.a
cc -o build/hello/hello build/hello/hello.o -Lexport/lib -lworld
ຕິດຕັ້ງ build/hello/hello ເປັນ export/bin/hello

ອີກເທື່ອຫນຶ່ງ, Cons ໄດ້ດູແລລາຍລະອຽດສໍາລັບທ່ານ. ໂດຍສະເພາະ, ທ່ານຈະສັງເກດເຫັນວ່າທັງຫມົດ
ການກໍ່ສ້າງແມ່ນເຮັດໄດ້ໂດຍໃຊ້ໄຟລ໌ແຫຼ່ງແລະໄຟລ໌ວັດຖຸຈາກໄດເລກະທໍລີສ້າງ. ສໍາລັບ
ຍົກຕົວຢ່າງ, build/world/world.o ແມ່ນລວບລວມມາຈາກ build/world/world.c, ແລະ
ສົ່ງອອກ/include/world.h ຖືກຕິດຕັ້ງຈາກ build/world/world.h. ນີ້​ແມ່ນ​ສໍາ​ເລັດ​ໃນ​ຫຼາຍ​ທີ່​ສຸດ​
ລະ​ບົບ​ໂດຍ​ການ​ທີ່​ເຫມາະ​ສົມ​ທີ່​ງ່າຍ​ດາຍ​ຂອງ ``ຍາກ​' ການ​ເຊື່ອມ​ຕໍ່​ໄຟລ​໌​ທີ່​ຕ້ອງ​ການ​ຈາກ​ແຕ່​ລະ​ແຫຼ່ງ​
ໄດເລກະທໍລີເຂົ້າໄປໃນໄດເລກະທໍລີການກໍ່ສ້າງທີ່ເຫມາະສົມ.

ການເຊື່ອມຕໍ່ຖືກຮັກສາໄວ້ຢ່າງຖືກຕ້ອງໂດຍ Cons, ບໍ່ວ່າທ່ານຈະເຮັດແນວໃດກັບໄດເລກະທໍລີແຫຼ່ງ.
ຖ້າ​ຫາກ​ວ່າ​ທ່ານ​ປັບ​ປຸງ​ແກ້​ໄຂ​ໄຟລ​໌​ທີ່​ມາ​, ບັນ​ນາ​ທິ​ການ​ຂອງ​ທ່ານ​ອາດ​ຈະ​ເຮັດ​ແນວ​ນີ້ ``​ໃນ​ສະ​ຖານ​ທີ່​' ຫຼື​ມັນ​ອາດ​ຈະ​ປ່ຽນ​ຊື່​ມັນ​
ທໍາອິດແລະສ້າງໄຟລ໌ໃຫມ່. ໃນກໍລະນີສຸດທ້າຍ, ການເຊື່ອມຕໍ່ຍາກໃດໆຈະສູນເສຍ. Cons ຈະ
ກວດຫາເງື່ອນໄຂນີ້ໃນຄັ້ງຕໍ່ໄປທີ່ຕ້ອງການໄຟລ໌ແຫຼ່ງ, ແລະຈະເຊື່ອມຕໍ່ມັນຄືນໃໝ່
ຢ່າງ ເໝາະ ສົມ.

ທ່ານຍັງຈະສັງເກດເຫັນ, ໂດຍວິທີທາງການ, ວ່າ no ການ​ປ່ຽນ​ແປງ​ໄດ້​ຖືກ​ຕ້ອງ​ການ​ທີ່​ຕິດ​ພັນ​ ທະບຽນ
ໄຟລ໌. ແລະພວກເຮົາສາມາດໄປຕື່ມອີກ, ດັ່ງທີ່ພວກເຮົາຈະເຫັນໃນພາກຕໍ່ໄປ.

variant ສ້າງຂຶ້ນ

ສະບາຍດີ, ໂລກ! ສໍາລັບການ ກ້ວຍ ແລະ peAH OS ຂອງ

ການສ້າງ variant ຕ້ອງການການຂະຫຍາຍທີ່ງ່າຍດາຍອື່ນ. ໃຫ້ເອົາເປັນຕົວຢ່າງ a
ຄວາມຕ້ອງການອະນຸຍາດໃຫ້ສ້າງສໍາລັບທັງສອງລະບົບປະຕິບັດການ baNaNa ແລະ peAcH. ໃນ​ກໍ​ລະ​ນີ​ນີ້,
ພວກເຮົາກໍາລັງໃຊ້ລະບົບໄຟລ໌ທີ່ແຈກຢາຍ, ເຊັ່ນ NFS ເພື່ອເຂົ້າເຖິງລະບົບສະເພາະ, ແລະ
ພຽງແຕ່ຫນຶ່ງຫຼືອື່ນໆຂອງລະບົບຕ້ອງໄດ້ຮັບການລວບລວມສໍາລັບການຮຽກຮ້ອງໃດໆຂອງ
`ຂໍ້ເສຍ'. ນີ້ແມ່ນວິທີຫນຶ່ງທີ່ພວກເຮົາສາມາດຕັ້ງຄ່າໄດ້ ກໍ່ສ້າງ ໄຟລ໌ສໍາລັບພວກເຮົາ ສະບາຍດີ, ໂລກ!
ຄໍາຮ້ອງສະຫມັກ:

# ສ້າງໄຟລ໌ສໍາລັບສະບາຍດີ, ໂລກ!

die qq(OS ຕ້ອງຖືກລະບຸ) ເວັ້ນເສຍແຕ່ $OS = $ARG{OS};
die qq (OS ຕ້ອງເປັນ "peach" ຫຼື "banana")
ຖ້າ $OS ne "peach" && $OS ne "banana";

# ບ່ອນໃດວາງສິນຄ້າທີ່ແບ່ງປັນຂອງພວກເຮົາທັງຫມົດ.
$EXPORT = "#export/$OS";

ສົ່ງອອກ q(CONS ລວມມີ LIB BIN );

# ໄດເລກະທໍລີມາດຕະຖານສໍາລັບການແບ່ງປັນຜະລິດຕະພັນ.
$INCLUDE = "$EXPORT/ລວມ";
$LIB = "$EXPORT/lib";
$BIN = "$EXPORT/bin";

# ສະພາບແວດລ້ອມການກໍ່ສ້າງມາດຕະຖານ.
$CONS = ຂໍ້ເສຍໃໝ່ (
CPPPATH => $INCLUDE, # ລວມເສັ້ນທາງສຳລັບການລວບລວມຂໍ້ມູນ C
LIBPATH => $LIB, # ເສັ້ນທາງຫ້ອງສະໝຸດສຳລັບໂຄງການເຊື່ອມຕໍ່
LIBS => '-lworld', # ລາຍຊື່ຫ້ອງສະໝຸດມາດຕະຖານ
);

# $BUILD ແມ່ນບ່ອນທີ່ພວກເຮົາຈະເອົາມາໃຫ້ທຸກຢ່າງ.
$BUILD = "#build/$OS";

# ບອກຂໍ້ເສຍວ່າໄຟລ໌ທີ່ມາຂອງ $BUILD ຢູ່ໃສ.
ເຊື່ອມຕໍ່ $BUILD => 'src';

ກໍ່ສ້າງ (
"$BUILD/hello/Conscript",
"$BUILD/world/Conscript",
);

ໃນປັດຈຸບັນຖ້າພວກເຮົາເຂົ້າສູ່ລະບົບ peAcH, ພວກເຮົາສາມາດສ້າງຂອງພວກເຮົາ ສະບາຍດີ, ໂລກ! ຄໍາຮ້ອງສະຫມັກສໍາລັບການນັ້ນ
ເວທີ:

% cons ສົ່ງອອກ OS=peach
ຕິດຕັ້ງ build/peach/world/world.h ເປັນ export/peach/include/world.h
cc -Iexport/peach/include -c build/peach/hello/hello.c -o build/peach/hello/hello.o
cc -Iexport/peach/include -c build/peach/world/world.c -o build/peach/world/world.o
ar r build/peach/world/libworld.a build/peach/world/world.o
ar: ການສ້າງ build/peach/world/libworld.a
ranlib build/peach/world/libworld.a
ຕິດຕັ້ງ build/peach/world/libworld.a ເປັນ export/peach/lib/libworld.a
cc -o build/peach/hello/hello build/peach/hello/hello.o -Lexport/peach/lib -lworld
ຕິດຕັ້ງ build/peach/hello/hello ເປັນການສົ່ງອອກ/peach/bin/hello

ການປ່ຽນແປງ on a ຫົວຂໍ້

ການປ່ຽນແປງອື່ນໆຂອງຮູບແບບນີ້ແມ່ນເປັນໄປໄດ້. ຕົວຢ່າງ, ທ່ານອາດຈະຕັດສິນໃຈວ່າທ່ານຕ້ອງການ
ເພື່ອແຍກເອົາໄຟລ໌ຂອງທ່ານອອກເປັນໄຟລ໌ທີ່ຂຶ້ນກັບເວທີ ແລະໄຟລ໌ເອກະລາດຂອງເວທີ.
ໃນກໍລະນີນີ້, ທ່ານຈະຕ້ອງກໍານົດທາງເລືອກເປັນ `$INCLUDE' ສໍາລັບເວທີທີ່ຂຶ້ນກັບ
ໄຟລ໌. ຫຼາຍທີ່ສຸດ ທະບຽນ ໄຟລ໌, ການສ້າງເວທີທີ່ເປັນເອກະລາດຢ່າງດຽວປະກອບມີໄຟລ໌, ຈະ
ບໍ່ຈໍາເປັນຕ້ອງມີການປ່ຽນແປງ.

ເຈົ້າອາດຈະຕ້ອງການສາມາດລວບລວມລະບົບທັງໝົດຂອງເຈົ້າດ້ວຍການດີບັກ ຫຼືການສ້າງໂປຣໄຟລ໌,
ຕົວຢ່າງ, ເປີດໃຊ້ງານ. ທ່ານສາມາດເຮັດສິ່ງນີ້ດ້ວຍຕົວເລືອກເສັ້ນຄໍາສັ່ງທີ່ເຫມາະສົມ, ເຊັ່ນ:
`DEBUG=on'. ນີ້ຈະຖືກແປເປັນເວທີທີ່ເຫມາະສົມສະເພາະ
ຂໍ້​ກໍາ​ນົດ​ເພື່ອ​ເປີດ​ໃຊ້​ງານ debugging (ນີ້​ອາດ​ຈະ​ລວມ​ເຖິງ​ການ​ປິດ​ການ​ປັບ​ປຸງ​, ສໍາ​ລັບ​ການ​
ຕົວຢ່າງ). ທ່ານ​ສາ​ມາດ​ເລືອກ​ທີ່​ຈະ​ປ່ຽນ​ຊື່​ຊ່ອງ​ສໍາ​ລັບ​ປະ​ເພດ​ທີ່​ແຕກ​ຕ່າງ​ກັນ​ຂອງ​ລະ​ບົບ​ເຫຼົ່າ​ນີ້​,
ແຕ່, ດັ່ງທີ່ພວກເຮົາຈະເຫັນໃນພາກຕໍ່ໄປ, ມັນບໍ່ແມ່ນ ທີ່ສໍາຄັນ ເພື່ອເຮັດສິ່ງນີ້, ນັບຕັ້ງແຕ່ Cons ແມ່ນງາມ
ສະຫລາດກ່ຽວກັບການກໍ່ສ້າງຄືນໃຫມ່ເມື່ອທ່ານປ່ຽນທາງເລືອກ.

ລາຍເຊັນ

MD5 ການເຂົ້າລະຫັດລັບ ລາຍເຊັນ

ເມື່ອໃດກໍ່ຕາມ Cons ສ້າງໄຟລ໌ທີ່ໄດ້ມາ, ມັນເກັບຮັກສາ a ລາຍເຊັນ ສໍາລັບໄຟລ໌ນັ້ນ. ລາຍເຊັນ
ຖືກເກັບໄວ້ໃນໄຟລ໌ແຍກຕ່າງຫາກ, ຫນຶ່ງຕໍ່ໄດເລກະທໍລີ. ຫຼັງຈາກຕົວຢ່າງທີ່ຜ່ານມາໄດ້ຖືກລວບລວມ,
ໄດ້ .ສົ່ງ ໄຟລ໌ໃນ build/peach/world ໄດເລກະທໍລີມີລັກສະນະນີ້:

world.o:834179303 23844c0b102ecdc0b4548d1cd1cbd8c6
libworld.a:834179304 9bf6587fa06ec49d864811a105222c00

ຕົວເລກທໍາອິດແມ່ນການສະແຕມເວລາ - ສໍາລັບລະບົບ UNIX, ໂດຍທົ່ວໄປແລ້ວນີ້ແມ່ນຈໍານວນ
ວິນາທີນັບຕັ້ງແຕ່ວັນທີ 1 ມັງກອນ 1970. ຄ່າທີສອງແມ່ນ MD5 checksum. ໄດ້ ຂໍ້ຄວາມ ຍ່ອຍອາຫານ
ລະບົບວິເຄາະ ແມ່ນສູດການຄິດໄລ່ທີ່, ໃຫ້ສະຕຣິງປ້ອນຂໍ້ມູນ, ຄິດໄລ່ການເຂົ້າລະຫັດລັບທີ່ເຂັ້ມແຂງ
ລາຍເຊັນສໍາລັບສາຍນັ້ນ. MD5 checksum ເກັບໄວ້ໃນ .ສົ່ງ ໄຟລ໌ແມ່ນ, ໃນຄວາມເປັນຈິງ, a
ຍ່ອຍຂໍ້ມູນການເພິ່ງພາອາໄສທັງໝົດຂອງໄຟລ໌ທີ່ລະບຸໄວ້. ດັ່ງນັ້ນ, ສໍາລັບການຍົກຕົວຢ່າງ, ສໍາລັບ
world.o ໄຟລ໌, ນີ້ປະກອບມີຢ່າງຫນ້ອຍ world.c ໄຟລ໌, ແລະໄຟລ໌ header ໃດໆທີ່ Cons
ຮູ້​ກ່ຽວ​ກັບ​ການ​ທີ່​ລວມ​, ໂດຍ​ກົງ​ຫຼື​ໂດຍ​ທາງ​ອ້ອມ​ໂດຍ​ world.c. ບໍ່ພຽງແຕ່ເທົ່ານັ້ນ, ແຕ່ວ່າ
ເສັ້ນຄໍາສັ່ງຕົວຈິງທີ່ຖືກນໍາໃຊ້ເພື່ອສ້າງ world.o ຍັງຖືກປ້ອນເຂົ້າໃນການຄິດໄລ່ຂອງ
ລາຍເຊັນ. ເຊັ່ນດຽວກັນ, libworld.a ໄດ້​ຮັບ​ລາຍ​ເຊັນ​ທີ່ ``ລວມ​ທັງ​ຫມົດ​
ລາຍເຊັນຂອງອົງປະກອບຂອງຕົນ (ແລະເພາະສະນັ້ນ, transitively, ລາຍເຊັນຂອງ ຂອງເຂົາເຈົ້າ
constituents), ເຊັ່ນດຽວກັນກັບເສັ້ນຄໍາສັ່ງທີ່ສ້າງໄຟລ໌.

ລາຍເຊັນຂອງໄຟລ໌ທີ່ບໍ່ໄດ້ມາຈາກຖືກຄິດໄລ່, ໂດຍຄ່າເລີ່ມຕົ້ນ, ໂດຍການເອົາປັດຈຸບັນ
ເວ​ລາ​ການ​ດັດ​ແກ້​ຂອງ​ໄຟລ​໌​ແລະ​ຊື່​ເຂົ້າ​ຂອງ​ໄຟລ​໌ (ເວັ້ນ​ເສຍ​ແຕ່​ມີ​ຫຍັງ​ເກີດ​ຂຶ້ນ​ເປັນ a
ໃນປະຈຸບັນ .ສົ່ງ ການປ້ອນຂໍ້ມູນສໍາລັບໄຟລ໌ນັ້ນ, ໃນກໍລະນີທີ່ລາຍເຊັນນັ້ນຖືກນໍາໃຊ້).

ສັງເກດເຫັນວ່າບໍ່ຈໍາເປັນຕ້ອງມີໄຟລ໌ທີ່ໄດ້ມາເພື່ອຂຶ້ນກັບສະເພາະໃດຫນຶ່ງ ກໍ່ສ້າງ or
ທະບຽນ ໄຟລ໌ - ຖ້າການປ່ຽນແປງໄຟລ໌ເຫຼົ່ານີ້ມີຜົນກະທົບຕໍ່ໄຟລ໌ທີ່ເປັນຄໍາຖາມ, ຫຼັງຈາກນັ້ນມັນຈະເປັນ
ສະທ້ອນໃຫ້ເຫັນອັດຕະໂນມັດໃນລາຍເຊັນຂອງຕົນ, ເນື່ອງຈາກວ່າພາກສ່ວນທີ່ກ່ຽວຂ້ອງຂອງສາຍຄໍາສັ່ງແມ່ນ
ລວມຢູ່ໃນລາຍເຊັນ. ການປ່ຽນແປງທີ່ບໍ່ກ່ຽວຂ້ອງຈະບໍ່ມີຜົນກະທົບ.

ເມື່ອ Cons ພິຈາລະນາວ່າຈະມາຈາກໄຟລ໌ໃດນຶ່ງ, ຫຼັງຈາກນັ້ນ, ມັນທໍາອິດທີ່ຈະຄິດໄລ່
ລາຍເຊັນທີ່ຄາດໄວ້ຂອງໄຟລ໌. ຈາກນັ້ນມັນປຽບທຽບເວລາດັດແກ້ຫຼ້າສຸດຂອງໄຟລ໌ກັບ
ທີ່​ໃຊ້​ເວ​ລາ​ບັນ​ທຶກ​ໄວ້​ໃນ​ .ສົ່ງ ເຂົ້າ, ຖ້າມີຢູ່. ຖ້າເວລາເຫຼົ່ານີ້ກົງກັນ, ຫຼັງຈາກນັ້ນ
ລາຍເຊັນເກັບຮັກສາໄວ້ໃນ .ສົ່ງ ໄຟລ໌ແມ່ນຖືວ່າຖືກຕ້ອງ. ຖ້າໄຟລ໌ຜ່ານມາ
ລາຍເຊັນບໍ່ກົງກັບລາຍເຊັນທີ່ຄາດໄວ້ໃໝ່, ຫຼັງຈາກນັ້ນໄຟລ໌ຈະຕ້ອງຖືກຖອດຖອນຄືນ.

ສັງເກດເຫັນວ່າໄຟລ໌ຈະຖືກຖອດຖອນຄືນທຸກຄັ້ງທີ່ມີການປ່ຽນແປງໄຟລ໌ທີ່ຂຶ້ນກັບ. ໃນ
ໂດຍສະເພາະ, ສັງເກດເຫັນວ່າ ໃດ ການ​ປ່ຽນ​ແປງ​ທີ່​ໃຊ້​ເວ​ລາ​ການ​ດັດ​ແກ້​ຂອງ​ການ​ຂຶ້ນ​ກັບ (ຕໍ່​ຫນ້າ​ຫຼື​
ຖອຍຫຼັງໃນເວລາ) ຈະບັງຄັບການລວບລວມໄຟລ໌ທີ່ໄດ້ມາ.

ການນໍາໃຊ້ລາຍເຊັນເຫຼົ່ານີ້ແມ່ນວິທີການງ່າຍດາຍທີ່ສຸດ, ປະສິດທິພາບ, ແລະປະສິດທິພາບຂອງ
ການປັບປຸງ - ຢ່າງຫຼວງຫຼາຍ - ການແຜ່ພັນຂອງລະບົບ.

ພວກເຮົາຈະສະແດງສິ່ງນີ້ດ້ວຍຕົວຢ່າງງ່າຍໆ:

# ງ່າຍໆ "ສະບາຍດີໂລກ!" ກໍ່ສ້າງໄຟລ໌
$CFLAGS = '-g' ຖ້າ $ARG{DEBUG} eq 'on';
$CONS = new cons(CFLAGS => $CFLAGS);
ໂຄງການ $CONS 'ສະບາຍດີ', 'hello.c';

ສັງເກດເຫັນວິທີການ Cons recompiles ໃນເວລາທີ່ເຫມາະສົມ:

% cons ສະບາຍດີ
cc -c hello.c -o hello.o
cc -o ສະບາຍດີ hello.o
% cons ສະບາຍດີ
cons: "ສະບາຍດີ" ແມ່ນທັນສະໄຫມ.
% cons DEBUG=ສະບາຍດີ
cc -g -c hello.c -o hello.o
cc -o ສະບາຍດີ hello.o
% cons DEBUG=ສະບາຍດີ
cons: "ສະບາຍດີ" ແມ່ນທັນສະໄຫມ.
% cons ສະບາຍດີ
cc -c hello.c -o hello.o
cc -o ສະບາຍດີ hello.o

ລະຫັດ ບັນດາຫໍປະຊຸມ

ອົງການຈັດຕັ້ງການພັດທະນາຊອບແວຈໍານວນຫຼາຍຈະມີຫນຶ່ງຫຼືຫຼາຍລະບົບ repository ສູນກາງ
ຕົ້ນໄມ້ທີ່ມີລະຫັດແຫຼ່ງປະຈຸບັນສໍາລັບຫນຶ່ງຫຼືຫຼາຍໂຄງການ, ເຊັ່ນດຽວກັນກັບທີ່ໄດ້ມາ
ໄຟລ໌ວັດຖຸ, ຫ້ອງສະຫມຸດ, ແລະປະຕິບັດໄດ້. ເພື່ອຫຼຸດຜ່ອນການລວບລວມຄືນໃຫມ່ທີ່ບໍ່ຈໍາເປັນ,
ມັນເປັນປະໂຫຍດທີ່ຈະນໍາໃຊ້ໄຟລ໌ຈາກ repository ເພື່ອສ້າງຊອບແວການພັດທະນາ - ສົມມຸດຕິຖານ, ຂອງ
ແນ່ນອນ, ບໍ່ມີໄຟລ໌ການເພິ່ງພາອາໄສອັນໃຫມ່ຢູ່ໃນຕົ້ນໄມ້ກໍ່ສ້າງທ້ອງຖິ່ນ.

Repository

Cons ສະຫນອງກົນໄກການກໍານົດບັນຊີລາຍຊື່ຂອງ repositories ລະຫັດທີ່ຈະຊອກຫາ,
in-order, ສໍາລັບໄຟລ໌ຕົ້ນສະບັບແລະໄຟລ໌ທີ່ມາຈາກບໍ່ພົບຢູ່ໃນຕົ້ນໄມ້ build directory ທ້ອງຖິ່ນ.

ແຖວຕໍ່ໄປນີ້ໃນ a ກໍ່ສ້າງ ໄຟລ໌ຈະແນະນໍາ Cons ເພື່ອເບິ່ງທໍາອິດພາຍໃຕ້
/usr/experiment/repository directory ແລະ​ຫຼັງ​ຈາກ​ນັ້ນ​ພາຍ​ໃຕ້​ການ​ /usr/product/repository ໄດເລກະທໍລີ:

Repository qw (
/usr/experiment/repository
/usr/product/repository
);

ໄດເລກະທໍລີ repository ທີ່ລະບຸໄວ້ອາດມີໄຟລ໌ແຫຼ່ງ, ໄຟລ໌ທີ່ມາຈາກ (objects,
ຫ້ອງສະຫມຸດແລະການປະຕິບັດ), ຫຼືທັງສອງ. ຖ້າບໍ່ມີໄຟລ໌ທ້ອງຖິ່ນ (ແຫຼ່ງຫຼືມາຈາກ) ພາຍໃຕ້
ໄດເລກະທໍລີທີ່ Cons ຖືກປະຕິບັດ, ຫຼັງຈາກນັ້ນສໍາເນົາທໍາອິດຂອງໄຟລ໌ທີ່ມີຊື່ດຽວກັນທີ່ພົບ
ພາຍໃຕ້ບັນຊີຂອງ repository ຈະຖືກນໍາໃຊ້ເພື່ອສ້າງໄຟລ໌ທີ່ມາຈາກທ້ອງຖິ່ນໃດໆ.

Cons ຮັກສາບັນຊີລາຍຊື່ທົ່ວໂລກຂອງໄດເລກະທໍລີ repositories. Cons ຈະ​ລົບ​ລ້າງ​
ໄດເລກະທໍລີປະຈຸບັນ, ແລະໄດເລກະທໍລີທີ່ບໍ່ມີຢູ່ແລ້ວ, ຈາກລາຍຊື່.

ຊອກ ໄດ້ ກໍ່ສ້າງ ເອກະສານ in a Repository

Cons ຍັງຈະຄົ້ນຫາສໍາລັບ ກໍ່ສ້າງ ແລະ ທະບຽນ ໄຟລ໌ໃນ repository tree ຫຼືຕົ້ນໄມ້.
ນີ້ນໍາໄປສູ່ສະຖານະການໄກ່ແລະໄຂ່, ເຖິງແມ່ນວ່າ: ເຈົ້າເບິ່ງຢູ່ໃນຕົ້ນໄມ້ repository ແນວໃດ
ສໍາ​ລັບ ກໍ່ສ້າງ ໄຟລ໌ຖ້າຫາກວ່າ ກໍ່ສ້າງ ໄຟລ໌ບອກເຈົ້າວ່າບ່ອນເກັບມ້ຽນຢູ່ໃສ? ໄດ້​ຮັບ
ປະມານນີ້, repositories ອາດຈະຖືກກໍານົດໂດຍຜ່ານທາງເລືອກ `-R' ໃນເສັ້ນຄໍາສັ່ງ:

% cons -R /usr/experiment/repository -R /usr/product/repository .

ໄດເລກະທໍລີ repository ໃດລະບຸໄວ້ໃນ ກໍ່ສ້າງ or ທະບຽນ ໄຟລ໌ຈະຖືກຕໍ່ທ້າຍ
ໄປຫາໄດເລກະທໍລີ repository ທີ່ລະບຸໄວ້ໂດຍຕົວເລືອກແຖວຄໍາສັ່ງ `-R'.

Repository ແຫຼ່ງ ໄຟ

ຖ້າລະຫັດແຫຼ່ງ (ລວມທັງ ທະບຽນ file) ສໍາລັບສະບັບຫ້ອງສະຫມຸດຂອງ ສະບາຍດີ,
ໂລກ! ແອັບພລິເຄຊັນ C ຢູ່ໃນບ່ອນເກັບມ້ຽນ (ບໍ່ມີໄຟລ໌ທີ່ມາຈາກ), Cons ຈະໃຊ້
repository ແຫຼ່ງໄຟລ໌ເພື່ອສ້າງໄຟລ໌ວັດຖຸທ້ອງຖິ່ນແລະໄຟລ໌ປະຕິບັດໄດ້:

% cons -R /usr/src_only/repository ສະບາຍດີ
gcc -c /usr/src_only/repository/hello.c -o hello.o
gcc -c /usr/src_only/repository/world.c -o world.o
ar r libworld.a world.o
ar: ການສ້າງ libworld.a
ranlib libworld.a
gcc -o ສະບາຍດີ hello.o libworld.a

ການສ້າງໄຟລ໌ແຫຼ່ງທ້ອງຖິ່ນຈະເຮັດໃຫ້ Cons ກໍ່ສ້າງໄຟລ໌ທີ່ໄດ້ມາທີ່ເຫມາະສົມຫຼື
ແຟ້ມ:

% pico world.c
[ແກ້ໄຂ]
% cons -R /usr/src_only/repository ສະບາຍດີ
gcc -c world.c -o world.o
ar r libworld.a world.o
ar: ການສ້າງ libworld.a
ranlib libworld.a
gcc -o ສະບາຍດີ hello.o libworld.a

ແລະການເອົາໄຟລ໌ແຫຼ່ງທ້ອງຖິ່ນອອກຈະເຮັດໃຫ້ Cons ກັບຄືນໄປຫາການກໍ່ສ້າງທີ່ມາຈາກ
ໄຟລ໌ຈາກແຫຼ່ງ repository:

% rm world.c
% cons -R /usr/src_only/repository ສະບາຍດີ
gcc -c /usr/src_only/repository/world.c -o world.o
ar r libworld.a world.o
ar: ການສ້າງ libworld.a
ranlib libworld.a
gcc -o ສະບາຍດີ hello.o libworld.a

Repository derived ໄຟ

ຖ້າຕົ້ນໄມ້ repository ມີໄຟລ໌ທີ່ມາຈາກ (ປົກກະຕິແລ້ວໄຟລ໌ວັດຖຸ, ຫ້ອງສະຫມຸດ, ຫຼື
executables), Cons ຈະປະຕິບັດການຄິດໄລ່ລາຍເຊັນປົກກະຕິຂອງຕົນເພື່ອຕັດສິນໃຈບໍ່ວ່າຈະເປັນ
ໄຟລ໌ repository ແມ່ນທັນສະໄຫມຫຼືໄຟລ໌ທີ່ມາຈາກຕ້ອງໄດ້ຮັບການສ້າງຢູ່ໃນທ້ອງຖິ່ນ. ນີ້​ຫມາຍ​ຄວາມ​ວ່າ​,
ເພື່ອຮັບປະກັນການຄິດໄລ່ລາຍເຊັນທີ່ຖືກຕ້ອງ, ຕົ້ນໄມ້ທີ່ເກັບມ້ຽນຍັງຕ້ອງມີ
.ສົ່ງ ໄຟລ໌ທີ່ຖືກສ້າງຂື້ນໂດຍ Cons ເມື່ອສ້າງໄຟລ໌ທີ່ໄດ້ມາ.

ນີ້ປົກກະຕິແລ້ວຈະສໍາເລັດໂດຍການກໍ່ສ້າງຊອບແວໃນ repository (ຫຼື,
ໃນທາງກົງກັນຂ້າມ, ໃນໄດເລກະທໍລີສ້າງ, ແລະຫຼັງຈາກນັ້ນຄັດລອກຜົນໄດ້ຮັບໄປຫາບ່ອນເກັບມ້ຽນ):

% cd /usr/all/repository
% cons ສະບາຍດີ
gcc -c hello.c -o hello.o
gcc -c world.c -o world.o
ar r libworld.a world.o
ar: ການສ້າງ libworld.a
ranlib libworld.a
gcc -o ສະບາຍດີ hello.o libworld.a

(ນີ້​ແມ່ນ​ປອດ​ໄພ​ເຖິງ​ແມ່ນ​ວ່າ​ ກໍ່ສ້າງ ໄຟລ໌ລາຍຊື່ /usr/all/repository ໄດເລກະທໍລີໃນ a
ຄໍາສັ່ງ 'Repository' ເພາະວ່າ Cons ຈະເອົາໄດເລກະທໍລີປະຈຸບັນອອກຈາກບ່ອນເກັບມ້ຽນ
ບັນຊີລາຍຊື່.)

ໃນປັດຈຸບັນຖ້າພວກເຮົາຕ້ອງການສ້າງສໍາເນົາຄໍາຮ້ອງສະຫມັກດ້ວຍຕົວເຮົາເອງ ສະບາຍດີ.c ໄຟລ໌, ພວກເຮົາພຽງແຕ່ຕ້ອງການ
ເພື່ອສ້າງໄຟລ໌ແຫຼ່ງທີ່ຈໍາເປັນອັນຫນຶ່ງ, ແລະໃຊ້ທາງເລືອກ `-R' ທີ່ຈະມີ cons ໃຊ້ອື່ນໆ
ໄຟລ​໌​ຈາກ repository​:

% mkdir $HOME/build1
% cd $HOME/Build1
%ed hello.c
[ແກ້ໄຂ]
% cons -R /usr/all/repository ສະບາຍດີ
gcc -c hello.c -o hello.o
gcc -o ສະບາຍດີ hello.o /usr/all/repository/libworld.a

ສັງ​ເກດ​ເຫັນ​ວ່າ Cons ບໍ່​ໄດ້ bothered ກັບ recreate ທ້ອງ​ຖິ່ນ​ libworld.a ຫໍສະຫມຸດ (ຫຼື recomple the
world.o module), ແຕ່ແທນທີ່ຈະໃຊ້ສະບັບທີ່ລວບລວມແລ້ວຈາກ repository.

ເນື່ອງຈາກວ່າລາຍເຊັນ MD5 ທີ່ Cons ວາງໄວ້ໃນ .ສົ່ງ ໄຟລ໌ມີເວລາປະທັບຕາສໍາລັບ
ໄຟລ໌ທີ່ໄດ້ມາ, ການສະແຕມເວລາລາຍເຊັນຈະຕ້ອງກົງກັບເວລາຂອງໄຟລ໌ສໍາລັບການລົງລາຍເຊັນ
ຖືວ່າຖືກຕ້ອງ.

ບາງລະບົບຊອຟແວອາດຈະປ່ຽນແປງເວລາໃນໄຟລ໌ repository (ໂດຍການຄັດລອກພວກມັນ,
eg), ໃນກໍລະນີ Cons ຈະ, ໂດຍຄ່າເລີ່ມຕົ້ນ, ສົມມຸດວ່າລາຍເຊັນຂອງ repository ບໍ່ຖືກຕ້ອງ.
ແລະສ້າງໄຟລ໌ໃຫມ່ໂດຍບໍ່ຈໍາເປັນ. ພຶດຕິກໍານີ້ອາດຈະຖືກປ່ຽນແປງໂດຍການລະບຸ:

Repository_Sig_Times_OK 0;

ນີ້ບອກ Cons ທີ່ຈະບໍ່ສົນໃຈເວລາໃນເວລາທີ່ຕັດສິນໃຈວ່າລາຍເຊັນທີ່ຖືກຕ້ອງ. (ຫມາຍ​ເຫດ​
ວ່າການຫຼີກເວັ້ນການກວດກາສຸຂາພິບານນີ້ຫມາຍຄວາມວ່າຈະຕ້ອງມີການຄວບຄຸມທີ່ເຫມາະສົມກັບ repository
ຕົ້ນໄມ້ເພື່ອຮັບປະກັນວ່າໄຟລ໌ທີ່ມາຈາກບໍ່ສາມາດແກ້ໄຂໄດ້ໂດຍບໍ່ມີການປັບປຸງ .ສົ່ງ
ລາຍເຊັນ.)

ທ້ອງຖິ່ນ ສໍາເນົາ of ໄຟ

ຖ້າຕົ້ນໄມ້ repository ມີຜົນໄດ້ຮັບທີ່ສົມບູນຂອງການກໍ່ສ້າງ, ແລະພວກເຮົາພະຍາຍາມສ້າງຈາກ
repository ໂດຍບໍ່ມີໄຟລ໌ໃດໆຢູ່ໃນຕົ້ນໄມ້ທ້ອງຖິ່ນຂອງພວກເຮົາ, ບາງສິ່ງບາງຢ່າງທີ່ຫນ້າປະຫລາດໃຈປານກາງ
ເກີດ​ຂຶ້ນ:

% mkdir $HOME/build2
% cd $HOME/Build2
% cons -R /usr/all/repository ສະບາຍດີ
cons: "ສະບາຍດີ" ແມ່ນທັນສະໄຫມ.

Cons ເປັນຫຍັງເວົ້າວ່າ ສະບາຍດີ ໂຄງການແມ່ນທັນສະໄຫມໃນເວລາທີ່ບໍ່ມີ ສະບາຍດີ program in
ໄດເລກະທໍລີກໍ່ສ້າງທ້ອງຖິ່ນ? ເນື່ອງຈາກວ່າບ່ອນເກັບມ້ຽນ (ບໍ່ແມ່ນໄດເລກະທໍລີທ້ອງຖິ່ນ) ປະກອບດ້ວຍ
up-to-date ສະບາຍດີ ໂຄງ​ການ​, ແລະ Cons ຖືກ​ກໍາ​ນົດ​ຢ່າງ​ຖືກ​ຕ້ອງ​ທີ່​ບໍ່​ມີ​ຫຍັງ​ຈໍາ​ເປັນ​ຕ້ອງ​ເຮັດ​ໄດ້​
ສ້າງສຳເນົາໄຟລ໌ທີ່ທັນສະໄໝນີ້ຄືນໃໝ່.

ຢ່າງໃດກໍຕາມ, ມີຫຼາຍຄັ້ງທີ່ມັນເຫມາະສົມເພື່ອຮັບປະກັນວ່າສໍາເນົາທ້ອງຖິ່ນຂອງ a
ໄຟລ໌ມີຢູ່ສະເໝີ. ຕົວຢ່າງເຊັ່ນການຫຸ້ມຫໍ່ຫຼືການທົດສອບ, ອາດຈະສົມມຸດວ່າແນ່ນອນ
ໄຟລ໌ທີ່ສ້າງຂຶ້ນມີຢູ່ໃນທ້ອງຖິ່ນ. ແທນທີ່ຈະເຮັດໃຫ້ສະຄຣິບຍ່ອຍເຫຼົ່ານີ້ຮູ້ເຖິງ
ໄດເລກະທໍລີ repository, ຄໍາສັ່ງ 'ທ້ອງຖິ່ນ' ອາດຈະຖືກເພີ່ມເຂົ້າໃນ a ກໍ່ສ້າງ or ທະບຽນ file to
ລະບຸວ່າໄຟລ໌ ຫຼືໄຟລ໌ໃດໜຶ່ງຈະຕ້ອງປາກົດຢູ່ໃນໄດເຣັກທໍຣີສ້າງທ້ອງຖິ່ນ:

ທ້ອງຖິ່ນ qw(
ສະບາຍດີ
);

ຫຼັງຈາກນັ້ນ, ຖ້າພວກເຮົາດໍາເນີນການຄໍາສັ່ງດຽວກັນຄືນໃຫມ່, Cons ຈະເຮັດໃຫ້ສໍາເນົາທ້ອງຖິ່ນຂອງໂຄງການຈາກ
ສໍາເນົາ repository (ບອກທ່ານວ່າມັນກໍາລັງເຮັດເຊັ່ນນັ້ນ):

% cons -R /usr/all/repository ສະບາຍດີ
ສໍາເນົາທ້ອງຖິ່ນຂອງສະບາຍດີຈາກ /usr/all/repository/hello
cons: "ສະບາຍດີ" ແມ່ນທັນສະໄຫມ.

ສັງເກດເຫັນວ່າ, ເນື່ອງຈາກວ່າການກະທໍາຂອງການເຮັດສໍາເນົາທ້ອງຖິ່ນບໍ່ໄດ້ຖືວ່າເປັນ "ການກໍ່ສ້າງ" ຂອງ
ສະບາຍດີ ໄຟລ໌, Cons ຍັງລາຍງານວ່າມັນທັນສະໄຫມ.

ການສ້າງສໍາເນົາທ້ອງຖິ່ນແມ່ນເປັນປະໂຫຍດທີ່ສຸດສໍາລັບໄຟລ໌ທີ່ກໍາລັງຖືກຕິດຕັ້ງເຂົ້າໄປໃນ
ໄດເລກະທໍລີລະດັບກາງ (ສໍາລັບການແບ່ງປັນກັບໄດເລກະທໍລີອື່ນໆ) ຜ່ານຄໍາສັ່ງ 'ຕິດຕັ້ງ'.
ມາພ້ອມກັບຄໍາສັ່ງ 'ຕິດຕັ້ງ' ສໍາລັບໄຟລ໌ທີ່ມີຄໍາສັ່ງ 'ທ້ອງຖິ່ນ' companion ແມ່ນດັ່ງນັ້ນ
ທົ່ວໄປທີ່ Cons ສະຫນອງຄໍາສັ່ງ 'Install_Local' ເປັນວິທີທີ່ສະດວກທີ່ຈະເຮັດທັງສອງ:

Install_Local $env, '#export', 'ສະບາຍດີ';

ເທົ່າກັບ:

ຕິດຕັ້ງ $env '#export', 'hello';
ທ້ອງຖິ່ນ '#export/hello';

ທັງຄໍາສັ່ງ 'Local' ແລະ 'Install_Local' ປັບປຸງທ້ອງຖິ່ນ .ສົ່ງ ໄຟລ໌ທີ່ມີ
ລາຍເຊັນໄຟລ໌ທີ່ເຫມາະສົມ, ດັ່ງນັ້ນການກໍ່ສ້າງໃນອະນາຄົດຖືກປະຕິບັດຢ່າງຖືກຕ້ອງ.

Repository ການເພິ່ງພາອາໄສ ການວິເຄາະ

ເນື່ອງຈາກການສະແກນຕົວຂອງມັນເອງ, Cons ຈະຄົ້ນຫາຕົ້ນໄມ້ repository ທີ່ລະບຸໄວ້ສໍາລັບການລວມ
.h ໄຟລ໌. ເວັ້ນເສຍແຕ່ວ່າຜູ້ລວບລວມຂໍ້ມູນຍັງຮູ້ກ່ຽວກັບຕົ້ນໄມ້ repository, ເຖິງແມ່ນວ່າ, ມັນຈະເປັນ
ບໍ່ສາມາດຊອກຫາ .h ໄຟລ໌ທີ່ມີພຽງແຕ່ຢູ່ໃນບ່ອນເກັບມ້ຽນ. ສໍາລັບຕົວຢ່າງ, ຖ້າຫາກວ່າ ສະບາຍດີ.c
ໄຟລ໌ປະກອບມີ ສະບາຍດີ ໄຟລ໌ຢູ່ໃນໄດເລກະທໍລີປະຈຸບັນຂອງມັນ:

% cons -R /usr/all/repository ສະບາຍດີ
gcc -c /usr/all/repository/hello.c -o hello.o
/usr/all/repository/hello.c:1: hello.h: ບໍ່ມີໄຟລ໌ ຫຼືລາຍຊື່ດັ່ງກ່າວ.

ການແກ້ໄຂບັນຫານີ້ບັງຄັບໃຫ້ຄວາມຕ້ອງການບາງຢ່າງໄປສູ່ວິທີການກໍ່ສ້າງສະພາບແວດລ້ອມ
ກໍານົດແລະໄປສູ່ວິທີການ C `#include' preprocessor directive ຖືກນໍາໃຊ້ເພື່ອປະກອບມີໄຟລ໌.

ເພື່ອແຈ້ງໃຫ້ຜູ້ລວບລວມຂໍ້ມູນກ່ຽວກັບຕົ້ນໄມ້ repository, Cons ຈະເພີ່ມ "-I" ທີ່ເຫມາະສົມ.
ທຸງກັບຄໍາສັ່ງການລວບລວມ. ນີ້ຫມາຍຄວາມວ່າຕົວແປ 'CPPPATH' ໃນ
ສະພາບແວດລ້ອມການກໍ່ສ້າງຕ້ອງລະບຸຢ່າງຈະແຈ້ງໄດເລກະທໍລີຍ່ອຍທັງໝົດທີ່ຈະຊອກຫາ
ສໍາລັບໄຟລ໌ລວມ, ລວມທັງໄດເລກະທໍລີປະຈຸບັນ. ດັ່ງນັ້ນ, ພວກເຮົາສາມາດແກ້ໄຂຂ້າງເທິງ
ຕົວຢ່າງໂດຍການປ່ຽນແປງການສ້າງສະພາບແວດລ້ອມໃນ ກໍ່ສ້າງ ໄຟລ໌ດັ່ງຕໍ່ໄປນີ້:

$env = ຂໍ້ເສຍໃໝ່(
CC => 'gcc',
CPPPATH => '.',
LIBS => 'libworld.a',
);

ເນື່ອງຈາກຄໍານິຍາມຂອງຕົວແປ 'CPPPATH', ຜົນໄດ້ຮັບນີ້, ເມື່ອພວກເຮົາປະຕິບັດຄືນໃຫມ່.
ຄໍາສັ່ງ:

% cons -R /usr/all/repository ສະບາຍດີ
gcc -c -I. -I/usr/all/repository /usr/all/repository/hello.c -o hello.o
gcc -o ສະບາຍດີ hello.o /usr/all/repository/libworld.a

ຄໍາສັ່ງຂອງທຸງ `-I” replicates, ສໍາລັບ C preprocessor, repository ດຽວກັນ-
ເສັ້ນທາງຄົ້ນຫາໄດເລກະທໍລີທີ່ Cons ໃຊ້ສໍາລັບການວິເຄາະການເພິ່ງພາອາໄສຂອງຕົນເອງ. ຖ້າມີ
ຫຼາຍ repositories ແລະຫຼາຍ 'CPPPATH' directory, Cons ຈະເພີ່ມເຕີມ repository
ໄດເລກະທໍລີໄປຫາຈຸດເລີ່ມຕົ້ນຂອງແຕ່ລະໄດເຣັກທໍຣີ 'CPPPATH', ການຄູນຈຳນວນຢ່າງໄວວາ
ຂອງທຸງ '-I'. ເປັນຕົວຢ່າງທີ່ສຸດ, a ກໍ່ສ້າງ ໄຟລ໌ປະກອບມີ:

Repository qw(
/u1
/u2
);

$env = ຂໍ້ເສຍໃໝ່(
CPPPATH => 'a:b:c',
);

ຈະໃຫ້ຄໍາສັ່ງການລວບລວມຂອງ:

cc -Ia -I/u1/a -I/u2/a -Ib -I/u1/b -I/u2/b -Ic -I/u1/c -I/u2/c -c hello.c -o ສະບາຍດີ.o

ເນື່ອງຈາກວ່າ Cons ອີງໃສ່ທຸງ `-I' ຂອງ compiler ເພື່ອສື່ສານຄໍາສັ່ງໃນນັ້ນ
ໄດເລກະທໍລີ repository ຕ້ອງໄດ້ຮັບການຄົ້ນຫາ, Cons 'ການຈັດການຂອງ repository directory ແມ່ນ
ໂດຍພື້ນຖານແລ້ວບໍ່ເຂົ້າກັນໄດ້ກັບການໃຊ້ສອງວົງຢືມໃນຄໍາສັ່ງ `#include' ໃນ C ຂອງທ່ານ.
ລະຫັດແຫຼ່ງ:

#include "file.h" /* ຢ່າໃຊ້ສອງຄຳເວົ້າແບບນີ້ */

ນີ້ແມ່ນຍ້ອນວ່າ C preprocessors ສ່ວນໃຫຍ່, ເມື່ອປະເຊີນກັບຄໍາສັ່ງດັ່ງກ່າວ, ຈະທໍາອິດສະເຫມີ
ຄົ້ນຫາໄດເລກະທໍລີທີ່ມີໄຟລ໌ແຫຼ່ງ. ອັນນີ້ທໍາລາຍຄວາມລະອຽດຂອງ `-ຂ້ອຍ”.
ທາງເລືອກທີ່ Cons ກໍ່ສ້າງເພື່ອເຮັດໃຫ້ preprocessor ສອດຄ່ອງກັບການຄົ້ນຫາທີ່ຕ້ອງການ
ເສັ້ນທາງ

ດັ່ງນັ້ນ, ເມື່ອນໍາໃຊ້ຕົ້ນໄມ້ repository ໃນ Cons, ສະເຫມີໄປ ໃຊ້ວົງເລັບມຸມສໍາລັບການລວມ
ແຟ້ມ:

#ລວມທັງ /* ໃຊ້ ANGLE-BRACKETS ແທນ */

Repository_List

Cons ສະຫນອງຄໍາສັ່ງ 'Repository_List' ເພື່ອສົ່ງຄືນບັນຊີລາຍຊື່ຂອງ repository directory ທັງຫມົດ
ໃນຄໍາສັ່ງຄົ້ນຫາໃນປະຈຸບັນຂອງພວກເຂົາ. ນີ້ສາມາດຖືກນໍາໃຊ້ສໍາລັບການ debugging, ຫຼືເຮັດ Perl ສະລັບສັບຊ້ອນຫຼາຍ
ສິ່ງຂອງ:

@list =Repository_List;
ພິມເຂົ້າຮ່ວມ(' ', @list), "\n";

Repository ການພົວພັນຮ່ວມກັນ ກັບ ອື່ນໆ cons ຄຸນ​ລັກ​ສະ​ນະ

Cons 'ການຈັດການຕົ້ນໄມ້ repository ປະຕິສໍາພັນຢ່າງຖືກຕ້ອງກັບລັກສະນະ Cons ອື່ນໆ - ເຊິ່ງແມ່ນ
ເວົ້າ, ໂດຍທົ່ວໄປແລ້ວມັນເຮັດສິ່ງທີ່ເຈົ້າຄາດຫວັງ.

ໂດຍສະເພາະແມ່ນຕົ້ນໄມ້ repository ໂຕ້ຕອບຢ່າງຖືກຕ້ອງ, ແລະມີອໍານາດຫຼາຍ, ດ້ວຍ 'Link'
ຄໍາສັ່ງ. ຕົ້ນໄມ້ repository ອາດມີຫນຶ່ງຫຼືຫຼາຍໄດເລກະທໍລີຍ່ອຍສໍາລັບການສ້າງສະບັບ
ສ້າງຕັ້ງຂຶ້ນໂດຍຜ່ານ 'ເຊື່ອມຕໍ່' ໄປຫາໄດເລກະທໍລີຍ່ອຍແຫຼ່ງ. Cons ຈະຄົ້ນຫາໄຟລ໌ທີ່ໄດ້ມາໃນ
ການສ້າງໄດເລກະທໍລີຍ່ອຍທີ່ເຫມາະສົມພາຍໃຕ້ຕົ້ນໄມ້ repository.

ມາດຕະຖານ ເປົ້າຫມາຍ

ຈົນກ່ວາໃນປັດຈຸບັນ, ພວກເຮົາໄດ້ສະແດງໃຫ້ເຫັນການເອີ້ນ Cons ກັບເປົ້າຫມາຍທີ່ຊັດເຈນເພື່ອສ້າງ:

% cons ສະບາຍດີ

ໂດຍປົກກະຕິ, Cons ບໍ່ໄດ້ສ້າງສິ່ງໃດ, ເວັ້ນເສຍແຕ່ກໍານົດເປົ້າຫມາຍ, ແຕ່ລະບຸ '.'
(ໄດເລກະທໍລີປະຈຸບັນ) ຈະສ້າງທຸກຢ່າງ:

%cons # ບໍ່ໄດ້ສ້າງຫຍັງ

% cons . # ສ້າງທຸກຢ່າງພາຍໃຕ້ໄດເລກະທໍລີລະດັບສູງສຸດ

ການເພີ່ມວິທີການ 'ຄ່າເລີ່ມຕົ້ນ' ໃສ່ອັນໃດນຶ່ງ ກໍ່ສ້າງ or ທະບຽນ ໄຟລ໌ຈະເພີ່ມທີ່ກໍານົດໄວ້
ເປົ້າຫມາຍໄປຫາບັນຊີລາຍຊື່ຂອງເປົ້າຫມາຍເລີ່ມຕົ້ນ. Cons ຈະສ້າງຄ່າເລີ່ມຕົ້ນເຫຼົ່ານີ້ຖ້າບໍ່ມີ
ເປົ້າໝາຍທີ່ລະບຸໄວ້ໃນເສັ້ນຄຳສັ່ງ. ດັ່ງນັ້ນການເພີ່ມເສັ້ນຕໍ່ໄປນີ້ໃນລະດັບສູງສຸດ
ກໍ່ສ້າງ ໄຟລ໌ຈະເຮັດຕາມພຶດຕິກໍາປົກກະຕິຂອງ Make ຂອງການສ້າງທຸກຢ່າງຕາມຄ່າເລີ່ມຕົ້ນ:

ຄ່າເລີ່ມຕົ້ນ '.';

ຕໍ່ໄປນີ້ຈະເພີ່ມ ສະບາຍດີ ແລະ ລາກ່ອນ ຄໍາສັ່ງ (ຢູ່ໃນໄດເລກະທໍລີດຽວກັນກັບ
ກໍ່ສ້າງ or ທະບຽນ ໄຟລ​໌​) ກັບ​ບັນ​ຊີ​ລາຍ​ການ​ເລີ່ມ​ຕົ້ນ​:

ຄ່າເລີ່ມຕົ້ນ qw(
ສະບາຍດີ
ລາກ່ອນ
);

ວິທີການ 'ຄ່າເລີ່ມຕົ້ນ' ອາດຈະຖືກນໍາໃຊ້ຫຼາຍກວ່າຫນຶ່ງຄັ້ງເພື່ອເພີ່ມເປົ້າຫມາຍໃສ່ບັນຊີລາຍຊື່ເລີ່ມຕົ້ນ.

Selective ສ້າງຂຶ້ນ

Cons ສະຫນອງສອງວິທີການສໍາລັບການຫຼຸດຜ່ອນຂະຫນາດຂອງການກໍ່ສ້າງໃຫ້. ທໍາອິດແມ່ນໂດຍການລະບຸ
ເປົ້າຫມາຍຢູ່ໃນເສັ້ນຄໍາສັ່ງ, ແລະອັນທີສອງແມ່ນວິທີການຕັດຕົ້ນໄມ້ກໍ່ສ້າງ. ດີ
ພິຈາລະນາສະເພາະເປົ້າໝາຍກ່ອນ.

Selective ການກໍາຫນົດເປົ້າຫມາຍ

ເຊັ່ນດຽວກັນກັບການເຮັດໃຫ້, Cons ອະນຸຍາດໃຫ້ສະເພາະຂອງ `` ເປົ້າຫມາຍ '' ໃນເສັ້ນຄໍາສັ່ງ. Cons ເປົ້າຫມາຍ
ອາດຈະເປັນໄຟລ໌ຫຼືໄດເລກະທໍລີ. ເມື່ອໄດເລກະທໍລີຖືກລະບຸ, ນີ້ແມ່ນພຽງແຕ່ສັ້ນ
ຫມາຍເຫດມືສໍາລັບທຸກໆຜະລິດຕະພັນ - ທີ່ Cons ຮູ້ກ່ຽວກັບ - ໃນທີ່ກໍານົດໄວ້
directory ແລະຂ້າງລຸ່ມນີ້. ຍົກ​ຕົວ​ຢ່າງ:

% cons build/hello/hello.o

ຫມາຍຄວາມວ່າກໍ່ສ້າງ ສະບາຍດີ ແລະທຸກສິ່ງທຸກຢ່າງນັ້ນ ສະບາຍດີ ອາດຈະຕ້ອງການ. ນີ້ແມ່ນມາຈາກທີ່ຜ່ານມາ
ສະບັບຂອງ ສະບາຍດີ, ໂລກ! ໂຄງ​ການ​ທີ່​ ສະບາຍດີ ຂຶ້ນກັບ
ສົ່ງອອກ/include/world.h. ຖ້າໄຟລ໌ນັ້ນບໍ່ທັນສະໄໝ (ເພາະວ່າມີຄົນດັດແກ້
src/world/world.h), ຫຼັງຈາກນັ້ນມັນຈະຖືກສ້າງໃຫມ່, ເຖິງແມ່ນວ່າມັນຢູ່ໃນໄດເລກະທໍລີຫ່າງໄກສອກຫຼີກຈາກ
build/ສະບາຍດີ.

ໃນຕົວຢ່າງນີ້:

% cons ກໍ່ສ້າງ

ທຸກສິ່ງທຸກຢ່າງຢູ່ໃນ ການກໍ່ສ້າງ ໄດເລກະທໍລີຖືກສ້າງຂຶ້ນ, ຖ້າຈໍາເປັນ. ອີກເທື່ອຫນຶ່ງ, ນີ້ອາດຈະເຮັດໃຫ້ໄຟລ໌ຫຼາຍ
ທີ່​ຈະ​ໄດ້​ຮັບ​ການ​ກໍ່​ສ້າງ​. ໂດຍສະເພາະ, ທັງສອງ ສົ່ງອອກ/include/world.h ແລະ ສົ່ງອອກ/lib/libworld.a ມີ
ຕ້ອງການໂດຍ build/ສະບາຍດີ ໄດເລກະທໍລີ, ແລະດັ່ງນັ້ນພວກມັນຈະຖືກສ້າງຂື້ນຖ້າພວກເຂົາລ້າສະໄຫມ.

ຖ້າພວກເຮົາເຮັດ, ແທນທີ່ຈະ:

% cons ສົ່ງອອກ

ຫຼັງ​ຈາກ​ນັ້ນ​ພຽງ​ແຕ່​ໄຟລ​໌​ທີ່​ຄວນ​ຈະ​ໄດ້​ຮັບ​ການ​ຕິດ​ຕັ້ງ​ໃນ​ລະ​ບົບ​ການ​ສົ່ງ​ອອກ​ຈະ​ໄດ້​ຮັບ​ການ​ສ້າງ​ໃຫມ່​, ຖ້າ​ຫາກ​ວ່າ​
ມີຄວາມຈໍາເປັນ, ແລະຫຼັງຈາກນັ້ນຕິດຕັ້ງຢູ່ທີ່ນັ້ນ. ໃຫ້ສັງເກດວ່າ 'cons build' ອາດຈະສ້າງໄຟລ໌ທີ່ 'cons
ການສົ່ງອອກ 'ບໍ່ໄດ້ສ້າງ, ແລະໃນທາງກັບກັນ.

No ``ພິເສດ'' ເປົ້າຫມາຍ

ດ້ວຍຂໍ້ເສຍ, ການສ້າງແບບ '`ພິເສດ' ເປົ້າຫມາຍແມ່ນບໍ່ຈໍາເປັນ. ການປຽບທຽບທີ່ງ່າຍດາຍທີ່ສຸດກັບ Cons
ແມ່ນ​ການ​ນໍາ​ໃຊ້​ພິ​ເສດ​ ການສົ່ງອອກ ໄດເລກະທໍລີ, ແທນທີ່ຈະ. ຕົວຢ່າງ, ໃຫ້ສົມມຸດວ່າທ່ານມີ a
ຊຸດການທົດສອບທັງໝົດທີ່ກ່ຽວຂ້ອງກັບລະຫັດຂອງທ່ານ. ການທົດສອບດໍາລົງຊີວິດຢູ່ໃນ
ແຫຼ່ງທີ່ຢູ່ໃກ້ກັບລະຫັດ. ໂດຍປົກກະຕິ, ແນວໃດກໍ່ຕາມ, ທ່ານບໍ່ຕ້ອງການສ້າງການທົດສອບເຫຼົ່ານີ້.
ການແກ້ໄຂຫນຶ່ງແມ່ນເພື່ອສະຫນອງຄໍາແນະນໍາການກໍ່ສ້າງທັງຫມົດສໍາລັບການສ້າງການທົດສອບ, ແລະຫຼັງຈາກນັ້ນ
ຕິດຕັ້ງການທົດສອບເຂົ້າໄປໃນພາກສ່ວນແຍກຕ່າງຫາກຂອງຕົ້ນໄມ້. ຖ້າພວກເຮົາຕິດຕັ້ງການທົດສອບໃນລະດັບສູງສຸດ
ໄດເລກະທໍລີເອີ້ນວ່າ ການທົດສອບ, ຈາກນັ້ນ:

% cons ການທົດສອບ

ຈະ​ສ້າງ​ການ​ທົດ​ສອບ​ທັງ​ຫມົດ​.

% cons ສົ່ງອອກ

ຈະສ້າງສະບັບການຜະລິດຂອງລະບົບ (ແຕ່ບໍ່ແມ່ນການທົດສອບ), ແລະ:

% cons ກໍ່ສ້າງ

ອາດຈະຫຼີກເວັ້ນໄດ້ (ເນື່ອງຈາກມັນຈະລວບລວມການທົດສອບໂດຍບໍ່ຈໍາເປັນ).

ຖ້າ​ຫາກ​ວ່າ​ທ່ານ​ຕ້ອງ​ການ​ທີ່​ຈະ​ສ້າງ​ພຽງ​ແຕ່​ການ​ທົດ​ສອບ​ດຽວ​, ຫຼັງ​ຈາກ​ນັ້ນ​ທ່ານ​ສາ​ມາດ​ຕັ້ງ​ຊື່​ການ​ທົດ​ສອບ​ຢ່າງ​ຊັດ​ເຈນ (ໃນ​
ບໍ່ວ່າຈະ ການທົດສອບ ໄດເລກະທໍລີຫຼື ການກໍ່ສ້າງ ໄດເລກະທໍລີ). ນອກນັ້ນທ່ານຍັງສາມາດລວບລວມການທົດສອບໄດ້
ເຂົ້າໄປໃນລໍາດັບຊັ້ນທີ່ສະດວກພາຍໃນໄດເລກະທໍລີການທົດສອບ. ລໍາດັບຊັ້ນນີ້ບໍ່ຈໍາເປັນຕ້ອງ
ຈໍາເປັນຕ້ອງກົງກັບລໍາດັບຊັ້ນຂອງແຫຼ່ງ, ໃນລັກສະນະດຽວກັນກັບລໍາດັບຊັ້ນ
ອາດຈະບໍ່ກົງກັບລໍາດັບຊັ້ນຂອງແຫຼ່ງ (ການລວມເອົາລໍາດັບຊັ້ນບໍ່ຫນ້າຈະເປັນຫຼາຍ
ເລິກກວ່າສອງລະດັບ, ສໍາລັບໂຄງການ C).

ຖ້າທ່ານຕ້ອງການກໍ່ສ້າງທຸກສິ່ງທຸກຢ່າງຢູ່ໃນຕົ້ນໄມ້ (ຂຶ້ນກັບທາງເລືອກໃດກໍ່ຕາມ
ເລືອກ), ທ່ານສາມາດນໍາໃຊ້:

% cons .

ນີ້ບໍ່ແມ່ນປະສິດທິພາບໂດຍສະເພາະ, ເນື່ອງຈາກວ່າມັນຊ້ໍາກັນຈະຍ່າງຕົ້ນໄມ້ທັງຫມົດ,
ລວມທັງຕົ້ນໄມ້ທີ່ມາຈາກ. ຕົ້ນໄມ້ແຫຼ່ງ, ແນ່ນອນ, ອາດຈະມີວັດຖຸທີ່ສາມາດສ້າງໄດ້
ມັນ - ບໍ່ມີຫຍັງຢຸດເຈົ້າຈາກການເຮັດສິ່ງນີ້, ເຖິງແມ່ນວ່າປົກກະຕິທ່ານຈະສ້າງໃນການກໍ່ສ້າງແຍກຕ່າງຫາກ
ຕົ້ນໄມ້.

ສ້າງ ການອອກ ກຳ ລັງກາຍ

ສົມທົບກັບການຄັດເລືອກເປົ້າຫມາຍ, ການກໍ່ສ້າງ pruning ສາມາດຖືກນໍາໃຊ້ເພື່ອຫຼຸດຜ່ອນຂອບເຂດຂອງ
ສ້າງ. ໃນຕົວຢ່າງ peAcH ແລະ baNaNa ທີ່ຜ່ານມາ, ພວກເຮົາໄດ້ເຫັນແລ້ວວ່າ script-driven
ການກໍ່ສ້າງ pruning ສາມາດຖືກນໍາໃຊ້ເພື່ອເຮັດໃຫ້ພຽງແຕ່ເຄິ່ງຫນຶ່ງຂອງການກໍ່ສ້າງທີ່ມີທ່າແຮງສໍາລັບການໃຫ້ໃດໆ
ການຮຽກຮ້ອງຂອງ 'cons'. Cons ຍັງສະຫນອງ, ເປັນຄວາມສະດວກ, ສົນທິສັນຍາບັນທັດຄໍາສັ່ງທີ່
ອະນຸຍາດໃຫ້ທ່ານລະບຸວ່າອັນໃດ ທະບຽນ ໄຟລ໌ຕົວຈິງໄດ້ຮັບ ''ສ້າງ' -- ນັ້ນແມ່ນ, ປະກອບ
ເຂົ້າໄປໃນຕົ້ນໄມ້ກໍ່ສ້າງ. ຍົກ​ຕົວ​ຢ່າງ:

% cons ກໍ່ສ້າງ + ໂລກ

argument `+' ແນະນໍາການສະແດງອອກປົກກະຕິ Perl. ນີ້, ແນ່ນອນ, ໄດ້ຖືກອ້າງເຖິງຢູ່ທີ່
ລະດັບ shell ຖ້າມີຕົວລະຄອນເມຕາຂອງ shell ພາຍໃນສະແດງອອກ. ໄດ້
ການສະແດງອອກແມ່ນກົງກັບແຕ່ລະຄົນ ທະບຽນ ໄຟລ໌ທີ່ໄດ້ກ່າວມາໃນ 'ສ້າງ'
ຄໍາຖະແຫຼງການ, ແລະພຽງແຕ່ scripts ທີ່ມີຊື່ທີ່ກົງກັນແມ່ນລວມເຂົ້າໃນຕົວຈິງ
ສ້າງຕົ້ນໄມ້. ອະນຸຍາດໃຫ້ມີການໂຕ້ຖຽງດັ່ງກ່າວຫຼາຍອັນ, ໃນກໍລະນີທີ່ມີການຈັບຄູ່ກັບອັນໃດອັນໜຶ່ງຂອງມັນ
ແມ່ນພຽງພໍທີ່ຈະເຮັດໃຫ້ສະຄຣິບຖືກລວມເຂົ້າ.

ໃນຕົວຢ່າງຂ້າງເທິງ, the ສະບາຍດີ ໂຄງການຈະບໍ່ຖືກສ້າງຂຶ້ນ, ເນື່ອງຈາກວ່າ Cons ຈະບໍ່ມີ
ຄວາມ​ຮູ້​ຂອງ script ໄດ້​ ສະບາຍດີ/Conscript. ໄດ້ libworld.a ຮວບຮວມຈະຖືກສ້າງ, ຢ່າງໃດກໍຕາມ, ຖ້າ
ຕ້ອງການ.

ມີສອງສາມການນໍາໃຊ້ສໍາລັບການກໍ່ສ້າງ pruning ຜ່ານເສັ້ນຄໍາສັ່ງ. ບາງທີອາດເປັນປະໂຫຍດທີ່ສຸດ
ແມ່ນຄວາມສາມາດໃນການປ່ຽນແປງທ້ອງຖິ່ນ, ແລະຫຼັງຈາກນັ້ນ, ມີຄວາມຮູ້ພຽງພໍຂອງ
ຜົນສະທ້ອນຂອງການປ່ຽນແປງເຫຼົ່ານັ້ນ, ຈໍາກັດຂະຫນາດຂອງຕົ້ນໄມ້ກໍ່ສ້າງເພື່ອເລັ່ງ
ທີ່ໃຊ້ເວລາກໍ່ສ້າງໃຫມ່. ການນໍາໃຊ້ທີສອງສໍາລັບການກໍ່ສ້າງ pruning ແມ່ນເພື່ອປ້ອງກັນຢ່າງຈິງຈັງ recompilation
ຂອງບາງໄຟລ໌ທີ່ທ່ານຮູ້ວ່າຈະລວບລວມຄືນເນື່ອງຈາກ, ສໍາລັບການຍົກຕົວຢ່າງ, ໄຟລ໌ header ດັດແກ້.
ທ່ານອາດຈະຮູ້ວ່າການປ່ຽນແປງຂອງໄຟລ໌ header ແມ່ນບໍ່ສໍາຄັນ, ຫຼືວ່າ
ການ​ປ່ຽນ​ແປງ​ອາດ​ຈະ​ໄດ້​ຮັບ​ການ​ລະ​ເລີຍ​ຢ່າງ​ປອດ​ໄພ​ສໍາ​ລັບ​ການ​ຫຼາຍ​ທີ່​ສຸດ​ຂອງ​ຕົ້ນ​ໄມ້​, ສໍາ​ລັບ​ຈຸດ​ປະ​ສົງ​ການ​ທົດ​ສອບ​.With Cons​, ໄດ້​
ທັດສະນະແມ່ນວ່າມັນເປັນ pragmatic ທີ່ຈະຍອມຮັບປະເພດຂອງພຶດຕິກໍານີ້, ດ້ວຍຄວາມເຂົ້າໃຈທີ່
ໃນ​ການ​ກໍ່​ສ້າງ​ເຕັມ​ທີ່​ຕໍ່​ໄປ​ທຸກ​ສິ່ງ​ທຸກ​ຢ່າງ​ທີ່​ຈະ​ຕ້ອງ​ໄດ້​ຮັບ​ການ​ກໍ່​ສ້າງ​ໃຫມ່​ຈະ​ເປັນ​. ບໍ່ມີການທຽບເທົ່າ
ໄປຫາຄໍາສັ່ງ ``ເຮັດໃຫ້ສໍາຜັດ'', ເພື່ອໝາຍໄຟລ໌ວ່າອັບເດດຢ່າງຖາວອນ. ດັ່ງນັ້ນຄວາມສ່ຽງໃດໆທີ່ເປັນ
ທີ່ເກີດຂຶ້ນໂດຍການສ້າງ pruning ແມ່ນຫຼຸດຜ່ອນ. ສໍາລັບການເຮັດວຽກທີ່ມີຄຸນນະພາບການປ່ອຍ, ແນ່ນອນ, ພວກເຮົາແນະນໍາ
ວ່າທ່ານບໍ່ໄດ້ໃຊ້ການກໍ່ສ້າງ pruning (ມັນເຫມາະສົມຢ່າງສົມບູນທີ່ຈະໃຊ້ໃນລະຫວ່າງການປະສົມປະສານ, ແນວໃດກໍ່ຕາມ,
ສໍາລັບການກວດສອບການລວບລວມຂໍ້ມູນ, ແລະອື່ນໆ. ພຽງແຕ່ໃຫ້ແນ່ໃຈວ່າຈະສ້າງ unconstrained ກ່ອນທີ່ຈະ committing
ການປະສົມປະສານ).

ຊົ່ວຄາວ overrides

Cons ສະຫນອງກົນໄກທີ່ງ່າຍດາຍຫຼາຍສໍາລັບການ overriding ລັກສະນະຂອງການກໍ່ສ້າງ. ໂດຍເນື້ອແທ້ແລ້ວແມ່ນ
ວ່າທ່ານຂຽນໄຟລ໌ override ທີ່ມີຫນຶ່ງຫຼືຫຼາຍຄໍາສັ່ງ 'override', ແລະທ່ານ
ລະບຸມັນຢູ່ໃນເສັ້ນຄໍາສັ່ງ, ເມື່ອທ່ານດໍາເນີນການ 'cons':

% cons -o ຫຼາຍກວ່າການສົ່ງອອກ

ຈະສ້າງ ການສົ່ງອອກ ໄດເລກະທໍລີ, ກັບໄຟລ໌ທີ່ມາຈາກທັງຫມົດຂຶ້ນກັບການ overrides ປະຈຸບັນ
ໃນ ໃນໄລຍະ ໄຟລ໌. ຖ້າທ່ານອອກຈາກທາງເລືອກ '-o', ຫຼັງຈາກນັ້ນທຸກສິ່ງທຸກຢ່າງທີ່ຈໍາເປັນທີ່ຈະເອົາອອກ
ການຍົກເລີກທັງໝົດຈະຖືກສ້າງໃໝ່.

ຂ້າມ ສະພາບແວດລ້ອມ ຕົວແປ

ໄຟລ໌ override ສາມາດມີສອງປະເພດຂອງການ overrides. ທໍາອິດແມ່ນສະພາບແວດລ້ອມທີ່ເຂົ້າມາ
ຕົວແປ. ເຫຼົ່ານີ້ແມ່ນປົກກະຕິສາມາດເຂົ້າເຖິງໄດ້ໂດຍ ກໍ່ສ້າງ ໄຟລ໌ຈາກແທັບ `%ENV'
ຕົວແປ. ສິ່ງເຫຼົ່ານີ້ສາມາດ overridden trivally ໃນໄຟລ໌ override ໂດຍການຕັ້ງຄ່າ
ອົງປະກອບທີ່ເຫມາະສົມຂອງ `%ENV' (ສິ່ງເຫຼົ່ານີ້ຍັງສາມາດຖືກລົບລ້າງໃນສະພາບແວດລ້ອມຂອງຜູ້ໃຊ້,
ແນ່​ນອນ).

ໄດ້ Override ຄໍາສັ່ງ

ປະເພດທີສອງຂອງການ override ແມ່ນສໍາເລັດດ້ວຍຄໍາສັ່ງ 'override', ເຊິ່ງເບິ່ງຄືວ່າ
ນີ້:

ລົບລ້າງ , => , => , ... ;

ການສະແດງອອກເປັນປົກກະຕິ regexp ຖືກຈັບຄູ່ກັບທຸກໆໄຟລ໌ທີ່ມາຈາກຜູ້ສະຫມັກ
ສໍາລັບການກໍ່ສ້າງ. ຖ້າໄຟລ໌ທີ່ໄດ້ມາກົງກັນ, ຄູ່ຕົວແປ/ຄ່າຖືກໃຊ້ເພື່ອ
override ຄຸນຄ່າໃນສະພາບແວດລ້ອມການກໍ່ສ້າງທີ່ກ່ຽວຂ້ອງກັບໄຟລ໌ທີ່ໄດ້ມາ.

ສົມມຸດວ່າພວກເຮົາມີສະພາບແວດລ້ອມການກໍ່ສ້າງເຊັ່ນນີ້:

$CONS = ຂໍ້ເສຍໃໝ່(
COPT => '',
CDBG => '-g',
CFLAGS => '%COPT %CDBG',
);

ຫຼັງຈາກນັ້ນ, ຖ້າພວກເຮົາມີໄຟລ໌ override ໃນໄລຍະ ປະກອບດ້ວຍຄໍາສັ່ງນີ້:

ແທນທີ່ '\.o$', COPT => '-O', CDBG => '';

ຫຼັງ​ຈາກ​ນັ້ນ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ "cons​" ທີ່​ມີ "-o over​" ທີ່​ສ້າງ​ .o ໄຟລ໌ໂດຍຜ່ານສະພາບແວດລ້ອມນີ້ຈະ
ເຮັດໃຫ້ພວກມັນຖືກລວບລວມດ້ວຍ `-O 'ແລະບໍ່ມີ `-g'. ການ override ສາມາດ, ແນ່ນອນ, ເປັນ
ຈໍາກັດຢູ່ໃນໄດເລກະທໍລີດຽວໂດຍການຄັດເລືອກທີ່ເຫມາະສົມຂອງການສະແດງຜົນປົກກະຕິ.

ນີ້ແມ່ນສະບັບຕົ້ນສະບັບຂອງ Hello, World! ໂຄງການ, ສ້າງຂຶ້ນດ້ວຍສະພາບແວດລ້ອມນີ້.
ໃຫ້ສັງເກດວ່າ Cons ກໍ່ສ້າງຊິ້ນສ່ວນທີ່ເຫມາະສົມຄືນໃຫມ່ເມື່ອການ override ຖືກນໍາໃຊ້ຫຼືເອົາອອກ:

% cons ສະບາຍດີ
cc -g -c hello.c -o hello.o
cc -o ສະບາຍດີ hello.o
% cons -o ຫຼາຍກວ່າສະບາຍດີ
cc -O -c hello.c -o hello.o
cc -o ສະບາຍດີ hello.o
% cons -o ຫຼາຍກວ່າສະບາຍດີ
cons: "ສະບາຍດີ" ແມ່ນທັນສະໄຫມ.
% cons ສະບາຍດີ
cc -g -c hello.c -o hello.o
cc -o ສະບາຍດີ hello.o

ມັນເປັນສິ່ງສໍາຄັນທີ່ຄໍາສັ່ງ 'Override' ພຽງແຕ່ຖືກນໍາໃຊ້ສໍາລັບການຊົ່ວຄາວ, ໃນເວລາບິນ
overrides ທີ່ຈໍາເປັນສໍາລັບການພັດທະນາເພາະວ່າ overrides ບໍ່ແມ່ນເວທີເອກະລາດແລະ
ເນື່ອງຈາກວ່າພວກເຂົາອີງໃສ່ຄວາມຮູ້ທີ່ໃກ້ຊິດເກີນໄປກ່ຽວກັບການເຮັດວຽກຂອງສະຄິບ. ສໍາລັບ
ການນໍາໃຊ້ຊົ່ວຄາວ, ຢ່າງໃດກໍຕາມ, ພວກເຂົາເຈົ້າແມ່ນແທ້ສິ່ງທີ່ທ່ານຕ້ອງການ.

ໃຫ້ສັງເກດວ່າມັນຍັງເປັນປະໂຫຍດທີ່ຈະສະຫນອງ, ເວົ້າ, ຄວາມສາມາດໃນການສ້າງການເພີ່ມປະສິດທິພາບຢ່າງເຕັມສ່ວນ
ຮຸ່ນຂອງລະບົບສໍາລັບການນໍາໃຊ້ການຜະລິດ - ຈາກ ກໍ່ສ້າງ ແລະ ທະບຽນ ໄຟລ໌. ວິທີນີ້
ທ່ານ​ສາ​ມາດ​ປັບ​ລະ​ບົບ​ທີ່​ເຫມາະ​ສົມ​ກັບ​ເວ​ທີ​. ບ່ອນທີ່ optimizer ການຄ້າ offs ຕ້ອງການ
ເຮັດ (ໄຟລ໌ໂດຍສະເພາະອາດຈະບໍ່ຖືກລວບລວມດ້ວຍການເພີ່ມປະສິດທິພາບເຕັມ, ຕົວຢ່າງ), ຫຼັງຈາກນັ້ນ
ເຫຼົ່ານີ້ສາມາດຖືກບັນທຶກໄວ້ສໍາລັບລູກຫລານ (ແລະການສືບພັນ) ໂດຍກົງໃນສະຄິບ.

ເພີ່ມເຕີມ on ການກໍ່ສ້າງ ສະພາບແວດລ້ອມ

ມາດຕະຖານ ການກໍ່ສ້າງ ຕົວແປ

ພວກເຮົາໄດ້ກ່າວເຖິງ, ແລະນໍາໃຊ້, ແນວຄວາມຄິດຂອງ a ການກໍ່ສ້າງ ສະພາບແວດລ້ອມ, ຫຼາຍຄັ້ງໃນ
ໜ້າກ່ອນໜ້າ. ດຽວນີ້ເຖິງເວລາແລ້ວທີ່ຈະເຮັດອັນນີ້ໃຫ້ກາຍເປັນສີມັງຫຼາຍ. ມີດັ່ງຕໍ່ໄປນີ້
ຖະແຫຼງການ:

$env = new cons();

ການອ້າງອິງເຖິງສະພາບແວດລ້ອມການກໍ່ສ້າງເລີ່ມຕົ້ນໃຫມ່ແມ່ນຖືກສ້າງຂຶ້ນ. ນີ້ປະກອບມີຕົວເລກ
ຂອງຕົວແປການກໍ່ສ້າງແລະບາງວິທີການ. ໃນການຂຽນປະຈຸບັນ, ບັນຊີລາຍຊື່ເລີ່ມຕົ້ນຂອງ
ຕົວແປການກໍ່ສ້າງແມ່ນຖືກກໍານົດດັ່ງຕໍ່ໄປນີ້:

CC => 'cc',
CFLAGS => '',
CCCOM => '%CC %CFLAGS %_IFLAGS -c %< -o %>',
INCDIRPREFIX => '-ຂ້ອຍ',
CXX => '%CC',
CXXFLAGS => '%CFLAGS',
CXXCOM => '%CXX %CXXFLAGS %_IFLAGS -c %< -o %>',
LINK => '%CXX',
LINKCOM => '%LINK %LDFLAGS -o %> %< %_LDIRS %LIBS',
LINKMODULECOM => '%LD -r -o %> %<',
LIBDIRPREFIX => '-L',
AR => 'ອາ',
ARFLAGS => 'r',
ARCOM => "%AR %ARFLAGS %> %<\n%RANLIB %>",
RANLIB => 'ranlib',
AS => 'ເປັນ',
ASFLAGS => '',
ASCOM => '%AS %ASFLAGS %< -o %>',
LD => 'ld',
LDFLAGS => '',
PREFLIB => 'lib',
SUFLIB => '.a',
SUFLIBS => '.so:.a',
SUFOBJ => '.o',
ENV => { 'ເສັ້ນທາງ' => '/ ຖັງ:/ usr / ຖັງ' },

ໃນລະບົບ Win32 (Windows NT), ຕົວແປການກໍ່ສ້າງຕໍ່ໄປນີ້ແມ່ນ overridden ໃນ
default:

CC => 'cl',
CFLAGS => '/ໂນໂລໂກ',
CCCOM => '%CC %CFLAGS %_IFLAGS /c %< /Fo%>',
CXXCOM => '%CXX %CXXFLAGS %_IFLAGS /c %< /Fo%>',
INCDIRPREFIX => '/ຂ້ອຍ',
LINK => 'ເຊື່ອມຕໍ່',
LINKCOM => '%LINK %LDFLAGS /out:%> %< %_LDIRS %LIBS',
LINKMODULECOM => '%LD /r /o %> %<',
LIBDIRPREFIX => '/LIBPATH:',
AR => 'lib',
ARFLAGS => '/ໂນໂລໂກ',
ARCOM => "%AR %ARFLAGS /out:%> %<",
RANLIB => '',
LD => 'ເຊື່ອມຕໍ່',
LDFLAGS => '/nologo ',
PREFLIB => '',
SUFEXE => '.exe',
SUFLIB => '.lib',
SUPLIBS => '.dll:.lib',
SUFOBJ => '.obj',

ຕົວແປເຫຼົ່ານີ້ຖືກນໍາໃຊ້ໂດຍວິທີການຕ່າງໆທີ່ກ່ຽວຂ້ອງກັບສະພາບແວດລ້ອມ, ໃນ
ໂດຍສະເພາະວິທີການໃດນຶ່ງທີ່ສຸດທ້າຍເອີ້ນຄໍາສັ່ງພາຍນອກຈະທົດແທນການເຫຼົ່ານີ້
ຕົວແປເຂົ້າໄປໃນຄໍາສັ່ງສຸດທ້າຍ, ຕາມຄວາມເຫມາະສົມ. ຕົວຢ່າງ, ວິທີການ 'ວັດຖຸ' ໃຊ້ເວລາ
ຈໍາ ນວນ ຂອງ ໄຟລ ໌ ແຫຼ່ງ ແລະ ຈັດ ການ ທີ່ ຈະ ໄດ້ ຮັບ, ຖ້າ ຫາກ ວ່າ ຈໍາ ເປັນ, ຈຸດ ປະ ສົງ ທີ່ ສອດ ຄ້ອງ ກັນ
ໄຟລ໌. ຍົກ​ຕົວ​ຢ່າງ:

ວັດຖຸ $env 'foo.c', 'bar.c';

ນີ້ຈະຈັດການຜະລິດ, ຖ້າຈໍາເປັນ, foo.o ແລະ bar.o. ຄໍາ​ສັ່ງ​ທີ່​ຮຽກ​ຮ້ອງ​ແມ່ນ​ງ່າຍ​ດາຍ​
`%CCCOM', ເຊິ່ງຂະຫຍາຍໂດຍຜ່ານການທົດແທນ, ໄປຫາຄໍາສັ່ງພາຍນອກທີ່ເຫມາະສົມທີ່ຕ້ອງການ
ການກໍ່ສ້າງແຕ່ລະວັດຖຸ. ພວກເຮົາຈະຄົ້ນຫາກົດລະບຽບການທົດແທນຕື່ມອີກພາຍໃຕ້ "ຄໍາສັ່ງ"
ວິທີການ, ຂ້າງລຸ່ມນີ້.

ຕົວແປການກໍ່ສ້າງຍັງຖືກນໍາໃຊ້ເພື່ອຈຸດປະສົງອື່ນໆ. ຕົວຢ່າງ, 'CPPPATH' ແມ່ນ
ໃຊ້ເພື່ອລະບຸເສັ້ນທາງທີ່ຂັ້ນດ້ວຍຈໍ້າສອງເມັດຂອງປະກອບມີໄດເລກະທໍລີ. ເຫຼົ່ານີ້ແມ່ນມີຈຸດປະສົງ
ຜ່ານໄປ C preprocessor ແລະຍັງຖືກນໍາໃຊ້ໂດຍເຄື່ອງຈັກສະແກນໄຟລ໌ C ເພື່ອ
ກໍານົດຄວາມເພິ່ງພາອາໄສທີ່ກ່ຽວຂ້ອງກັບການລວບລວມ C. ຕົວແປທີ່ເລີ່ມຕົ້ນດ້ວຍ
underscore, ຖືກສ້າງຂື້ນໂດຍວິທີການຕ່າງໆ, ແລະປົກກະຕິຄວນຈະຖືກພິຈາລະນາວ່າ "ພາຍໃນ"
ຕົວແປ. ຕົວຢ່າງ, ເມື່ອວິທີການເອີ້ນວ່າທີ່ຮຽກຮ້ອງໃຫ້ມີການສ້າງວັດຖຸ
ຈາກແຫຼ່ງ C, ຕົວແປ `_IFLAGS' ຖືກສ້າງຂື້ນ: ອັນນີ້ກົງກັບປຸ່ມ `-I'
ຕ້ອງການໂດຍ C compiler ເພື່ອເປັນຕົວແທນຂອງໄດເລກະທໍລີທີ່ລະບຸໄວ້ໂດຍ `CPPPATH'.

ໃຫ້ສັງເກດວ່າ, ສໍາລັບສະພາບແວດລ້ອມສະເພາະໃດຫນຶ່ງ, ຄ່າຂອງຕົວແປແມ່ນຖືກກໍານົດຫນຶ່ງຄັ້ງ, ແລະຫຼັງຈາກນັ້ນ
ບໍ່ເຄີຍຣີເຊັດ (ເພື່ອປ່ຽນຕົວແປ, ທ່ານຕ້ອງສ້າງສະພາບແວດລ້ອມໃຫມ່. ວິທີການແມ່ນສະຫນອງໃຫ້
ສໍາລັບການຄັດລອກສະພາບແວດລ້ອມທີ່ມີຢູ່ແລ້ວສໍາລັບຈຸດປະສົງນີ້). ບາງຕົວແປພາຍໃນ, ເຊັ່ນ:
`_IFLAGS' ຖືກສ້າງຂື້ນຕາມຄວາມຕ້ອງການ, ແຕ່ເມື່ອຕັ້ງແລ້ວ, ພວກມັນຍັງຄົງຄົງທີ່ສໍາລັບຊີວິດຂອງ
ສິ່ງແວດລ້ອມ.

ຕົວແປ 'CFLAGS', `LDFLAGS', ແລະ `ARFLAGS' ທັງໝົດແມ່ນສະໜອງສະຖານທີ່ໃຫ້ທາງເລືອກໃນການຖ່າຍທອດ.
compiler, loader, ແລະ archiver, ຕາມລໍາດັບ. ຫນ້ອຍແນ່ນອນ, "INCDIRPREFIX"
variable ກໍານົດ string ທາງເລືອກທີ່ຈະຕໍ່ທ້າຍກັບຈຸດເລີ່ມຕົ້ນຂອງແຕ່ລະປະກອບມີ
ໄດເລກະທໍລີເພື່ອໃຫ້ compiler ຮູ້ບ່ອນທີ່ຈະຊອກຫາ .h ໄຟລ໌. ເຊັ່ນດຽວກັນ, ໄດ້
ຕົວແປ 'LIBDIRPREFIX' ລະບຸສະຕຣິງທາງເລືອກທີ່ຈະຕໍ່ທ້າຍກັບຈຸດເລີ່ມຕົ້ນຂອງ
ແຕ່ລະໄດເລກະທໍລີທີ່ຜູ້ເຊື່ອມຕໍ່ຄວນຄົ້ນຫາຫ້ອງສະຫມຸດ.

ຕົວແປອື່ນ, `ENV', ຖືກນໍາໃຊ້ເພື່ອກໍານົດສະພາບແວດລ້ອມຂອງລະບົບໃນລະຫວ່າງການປະຕິບັດ
ຂອງ​ຄໍາ​ສັ່ງ​ພາຍ​ນອກ​. ໂດຍຄ່າເລີ່ມຕົ້ນ, ຕົວແປສະພາບແວດລ້ອມດຽວທີ່ຖືກກໍານົດແມ່ນ 'PATH',
ຊຶ່ງເປັນເສັ້ນທາງປະຕິບັດສໍາລັບຄໍາສັ່ງ UNIX. ສໍາລັບການສືບພັນສູງສຸດ, ທ່ານຄວນ
ກໍ່ຈັດວາງເສັ້ນທາງການປະຕິບັດຂອງທ່ານເອງ, ໃນລະດັບສູງສຸດຂອງເຈົ້າ ກໍ່ສ້າງ ໄຟລ໌ (ຫຼື
ບາງທີໂດຍການນໍາເຂົ້າຊຸດການກໍ່ສ້າງທີ່ເຫມາະສົມກັບຄໍາສັ່ງ Perl `use'). ໄດ້
ຕົວແປເລີ່ມຕົ້ນມີຈຸດປະສົງເພື່ອເຮັດໃຫ້ທ່ານອອກຈາກພື້ນດິນ.

Interpolating ການກໍ່ສ້າງ ຕົວແປ

ຕົວແປສະພາບແວດລ້ອມການກໍ່ສ້າງອາດຈະຖືກ interpolated ໃນແຫຼ່ງແລະຊື່ໄຟລ໌ເປົ້າຫມາຍ
ໂດຍການນຳໜ້າຊື່ຕົວແປການກໍ່ສ້າງດ້ວຍ `%'.

$env = ຂໍ້ເສຍໃໝ່(
DESTDIR => 'ລາຍການ',
SRCDIR => 'src',
);
ໂຄງການ $env '%DESTDIR/hello', '%SRCDIR/hello.c';

ການຂະຫຍາຍຕົວຂອງຕົວແປການກໍ່ສ້າງແມ່ນ recursive - ນັ້ນແມ່ນ, ໄຟລ໌ ຊື່(s) ຈະ​ເປັນ​ຄືນ​ໃຫມ່
ຂະຫຍາຍອອກໄປຈົນກ່ວາບໍ່ສາມາດປ່ຽນແທນໄດ້. ຖ້າຕົວແປການກໍ່ສ້າງບໍ່ແມ່ນ
ກຳນົດໄວ້ໃນສະພາບແວດລ້ອມ, ຈາກນັ້ນສະຕຣິງ null ຈະຖືກປ່ຽນແທນ.

ມາດຕະຖານ ການກໍ່ສ້າງ ວິທີການ

ບັນຊີລາຍຊື່ຂອງວິທີການກໍ່ສ້າງໃນຕອນຕົ້ນປະກອບມີດັ່ງຕໍ່ໄປນີ້:

ໄດ້ `ໃຫມ່' ຜູ້ກໍ່ສ້າງ

ວິທີການ 'ໃໝ່' ແມ່ນຕົວສ້າງວັດຖຸ Perl. ນັ້ນແມ່ນ, ມັນບໍ່ໄດ້ຖືກເອີ້ນຜ່ານເອກະສານອ້າງອີງ
ກັບສະພາບແວດລ້ອມການກໍ່ສ້າງທີ່ມີຢູ່ແລ້ວ ອ້າງອິງ, ແຕ່, ແທນທີ່ຈະເປັນສະຖິຕິ, ການນໍາໃຊ້ຊື່
ຂອງ Perl ໄດ້ ຊຸດ ບ່ອນທີ່ constructor ຖືກກໍານົດ. ວິ​ທີ​ການ​ແມ່ນ​ຮຽກ​ຮ້ອງ​ໃຫ້​ມີ​ດັ່ງ​ນີ້​:

$env = ຂໍ້ເສຍໃໝ່( );

ສະພາບແວດລ້ອມທີ່ທ່ານໄດ້ຮັບກັບຄືນໄປບ່ອນໄດ້ຮັບພອນເຂົ້າໄປໃນຊຸດ 'cons', ຊຶ່ງຫມາຍຄວາມວ່າມັນຈະ
ໄດ້ເຊື່ອມໂຍງກັບມັນວິທີການເລີ່ມຕົ້ນທີ່ອະທິບາຍຂ້າງລຸ່ມນີ້. ການກໍ່ສ້າງສ່ວນບຸກຄົນ
ຕົວແປສາມາດຖືກລົບລ້າງໂດຍການໃຫ້ຊື່/ຄ່າຄູ່ໃນລາຍການແທນທີ່. ໃຫ້ສັງເກດວ່າ
ເພື່ອ override ຕົວແປສະພາບແວດລ້ອມຄໍາສັ່ງໃດໆ (ເຊັ່ນສິ່ງທີ່ຢູ່ພາຍໃຕ້ `ENV'), ທ່ານຈະຕ້ອງ
override ທັງຫມົດຂອງພວກເຂົາ. ທ່ານ​ສາ​ມາດ​ໄດ້​ຮັບ​ປະ​ມານ​ຄວາມ​ຫຍຸ້ງ​ຍາກ​ນີ້​ໂດຍ​ການ​ນໍາ​ໃຊ້​ວິ​ທີ​ການ 'ສໍາ​ເນົາ​' ໃນ​
ສະພາບແວດລ້ອມການກໍ່ສ້າງທີ່ມີຢູ່ແລ້ວ.

ໄດ້ `ໂຄນ' ວິທີການ

ວິທີການ 'clone' ສ້າງ clone ຂອງສະພາບແວດລ້ອມການກໍ່ສ້າງທີ່ມີຢູ່ແລ້ວ, ແລະສາມາດເປັນ
ເອີ້ນວ່າໃນຕົວຢ່າງຕໍ່ໄປນີ້:

$env2 = $env1->ໂຄນ( );

ທ່ານສາມາດສະຫນອງການ overrides ໃນລັກສະນະປົກກະຕິເພື່ອສ້າງສະພາບແວດລ້ອມທີ່ແຕກຕ່າງກັນຈາກ
ຕົ້ນສະບັບ. ຖ້າຫາກວ່າທ່ານພຽງແຕ່ຕ້ອງການຊື່ໃຫມ່ສໍາລັບສະພາບແວດລ້ອມດຽວກັນ (ຊຶ່ງອາດຈະເປັນປະໂຫຍດໃນເວລາທີ່
ສະພາບແວດລ້ອມສົ່ງອອກໄປຍັງອົງປະກອບທີ່ມີຢູ່ແລ້ວ), ທ່ານພຽງແຕ່ສາມາດນໍາໃຊ້ການມອບຫມາຍງ່າຍດາຍ.

ໄດ້ `ສຳເນົາ' ວິທີການ

ວິທີການ 'ສໍາເນົາ' ສະກັດຕົວແປການກໍ່ສ້າງທີ່ກໍານົດພາຍນອກຈາກ an
ສະ​ພາບ​ແວດ​ລ້ອມ​ແລະ​ກັບ​ຄືນ​ພວກ​ເຂົາ​ເປັນ​ບັນ​ຊີ​ລາຍ​ຊື່​ຂອງ​ຄູ່ / ມູນ​ຄ່າ​. Overrides ຍັງສາມາດເປັນ
ສະຫນອງໃຫ້, ໃນກໍລະນີນີ້, ຄ່າ overridden ຈະຖືກສົ່ງຄືນ, ຕາມຄວາມເຫມາະສົມ. ໄດ້
ບັນຊີລາຍຊື່ທີ່ສົ່ງຄືນສາມາດຖືກມອບຫມາຍໃຫ້ເປັນ hash, ດັ່ງທີ່ສະແດງຢູ່ໃນຕົວແບບ, ຂ້າງລຸ່ມນີ້, ແຕ່ມັນກໍ່ສາມາດເຮັດໄດ້
ໄດ້​ຮັບ​ການ​ຈັດ​ການ​ໃນ​ວິ​ທີ​ການ​ອື່ນໆ​:

%env = $env1->ສຳເນົາ( );

ຄ່າຂອງ 'ENV', ເຊິ່ງເປັນຕົວຂອງມັນເອງເປັນ hash, ຍັງຖືກຄັດລອກໄປທີ່ hash ໃໝ່, ດັ່ງນັ້ນນີ້ອາດຈະເປັນ.
ປ່ຽນແປງໂດຍບໍ່ມີຄວາມຢ້ານກົວທີ່ຈະສົ່ງຜົນກະທົບຕໍ່ສະພາບແວດລ້ອມເດີມ. ດັ່ງນັ້ນ, ສໍາລັບການຍົກຕົວຢ່າງ, ຖ້າຫາກວ່າທ່ານແທ້
ຕ້ອງການ override ພຽງແຕ່ຕົວແປ 'PATH' ໃນສະພາບແວດລ້ອມເລີ່ມຕົ້ນ, ທ່ານສາມາດເຮັດໄດ້
ຕໍ່ໄປນີ້:

%cons = new cons()->copy();
$cons{ENV}{PATH} = " ";
$cons = new cons(%cons);

ນີ້ຈະປ່ອຍໃຫ້ສິ່ງອື່ນທີ່ອາດຈະຢູ່ໃນສະພາບແວດລ້ອມການດໍາເນີນການເລີ່ມຕົ້ນ
ບໍ່ລົບກວນ.

ໄດ້ 'ຕິດຕັ້ງ' ວິທີການ

ວິທີການ 'ຕິດຕັ້ງ' ຈັດແຈງໄຟລ໌ທີ່ລະບຸໄວ້ເພື່ອຕິດຕັ້ງໃນທີ່ກໍານົດໄວ້
ໄດເລກະທໍລີ. ການຕິດຕັ້ງໄດ້ຖືກປັບປຸງໃຫ້ເຫມາະສົມ: ໄຟລ໌ບໍ່ໄດ້ຖືກຄັດລອກຖ້າມັນສາມາດເຊື່ອມຕໍ່ໄດ້. ຖ້າ
ນີ້ບໍ່ແມ່ນພຶດຕິກໍາທີ່ຕ້ອງການ, ທ່ານຈະຕ້ອງໃຊ້ວິທີທີ່ແຕກຕ່າງກັນເພື່ອຕິດຕັ້ງ
ໄຟລ໌. ມັນຖືກເອີ້ນວ່າ:

ຕິດຕັ້ງ $env , ;

ໃຫ້ສັງເກດວ່າ, ໃນຂະນະທີ່ໄຟລ໌ທີ່ຈະຕິດຕັ້ງອາດຈະຕັ້ງຊື່ arbitrarily, ພຽງແຕ່ສຸດທ້າຍ
ອົງປະກອບຂອງແຕ່ລະຊື່ແມ່ນໃຊ້ສໍາລັບຊື່ເປົ້າຫມາຍທີ່ຕິດຕັ້ງ. ດັ່ງນັ້ນ, ສໍາລັບການຍົກຕົວຢ່າງ, ຖ້າຫາກວ່າທ່ານ
ຈັດ​ການ​ຕິດ​ຕັ້ງ​ foo/bar in ຖານ, ນີ້ຈະສ້າງເປັນ ພາທະນາຍຄວາມ ໄຟລ໌ໃນ ຖານ ໄດເລກະທໍລີ (ບໍ່
foo/bar).

ໄດ້ 'ຕິດຕັ້ງ' ວິທີການ

ວິທີການ 'InstallAs' ຈັດຫາແຫຼ່ງທີ່ລະບຸໄວ້ ເອກະສານ(s​) ການ​ຕິດ​ຕັ້ງ​ເປັນ​
ເປົ້າ​ຫມາຍ​ທີ່​ກໍາ​ນົດ​ໄວ້​ ເອກະສານ(ສ). ຫຼາຍໆໄຟລ໌ຄວນຖືກລະບຸເປັນລາຍການໄຟລ໌. ໄດ້
ການ​ຕິດ​ຕັ້ງ​ແມ່ນ​ເຫມາະ​ສົມ​: ໄຟລ​໌​ບໍ່​ໄດ້​ຖືກ​ຄັດ​ລອກ​ຖ້າ​ຫາກ​ວ່າ​ມັນ​ສາ​ມາດ​ເຊື່ອມ​ຕໍ່​ໄດ້​. ຖ້ານີ້ບໍ່ແມ່ນ
ພຶດຕິກໍາທີ່ຕ້ອງການ, ທ່ານຈະຕ້ອງໃຊ້ວິທີທີ່ແຕກຕ່າງກັນເພື່ອຕິດຕັ້ງໄຟລ໌. ມັນ​ແມ່ນ
ເອີ້ນດັ່ງນີ້:

'ຕິດຕັ້ງ' ເຮັດວຽກໃນສອງວິທີ:

ການຕິດຕັ້ງໄຟລ໌ດຽວ:

ຕິດຕັ້ງAs $env TgtFile, SrcFile;

ການ​ຕິດ​ຕັ້ງ​ຫຼາຍ​ໄຟລ​໌​:

InstallAs $env ['tgt1', 'tgt2'], ['src1', 'src2'];

ຫຼື, ເຖິງແມ່ນວ່າ:

@srcs = qw(src1 src2 src3);
@tgts = qw(tgt1 tgt2 tgt3);
ຕິດຕັ້ງAs $env [@tgts], [@srcs];

ທັງເປົ້າໝາຍ ແລະລາຍການແຫຼ່ງຕ່າງໆຄວນມີຄວາມຍາວດຽວກັນ.

ໄດ້ 'ມີຄ່າ' ວິທີການ

ວິທີການ 'ມີຄ່າ' ຂໍ cons ບໍ່ໃຫ້ລຶບໄຟລ໌ທີ່ລະບຸໄວ້ຫຼືບັນຊີລາຍຊື່ຂອງໄຟລ໌ກ່ອນ
ການກໍ່ສ້າງໃຫ້ເຂົາເຈົ້າອີກເທື່ອຫນຶ່ງ. ມັນ​ຖືກ​ເອີ້ນ​ເປັນ​:

ມີຄ່າ ;

ອັນນີ້ເປັນປະໂຫຍດໂດຍສະເພາະສໍາລັບການອະນຸຍາດໃຫ້ມີການປັບປຸງເພີ່ມເຕີມຕໍ່ກັບຫ້ອງສະໝຸດ ຫຼືດີບັກ
ໄຟລ໌ຂໍ້ມູນຂ່າວສານທີ່ຖືກປັບປຸງແທນທີ່ຈະສ້າງໃຫມ່ໃນແຕ່ລະຄັ້ງ. ຂໍ້ເສຍຍັງຈະຢູ່
ລຶບໄຟລ໌ເມື່ອທຸງ `-r' ຖືກລະບຸ.

ໄດ້ 'ຄໍາສັ່ງ' ວິທີການ

ວິທີການ 'ຄໍາສັ່ງ' ແມ່ນວິທີການ catchall ທີ່ສາມາດຖືກນໍາໃຊ້ເພື່ອຈັດແຈງພາຍນອກ
ຄໍາສັ່ງທີ່ຈະເອີ້ນວ່າການປັບປຸງເປົ້າຫມາຍ. ສໍາລັບຄໍາສັ່ງນີ້, ໄຟລ໌ເປົ້າຫມາຍແລະບັນຊີລາຍຊື່ຂອງ
ວັດສະດຸປ້ອນແມ່ນສະຫນອງໃຫ້. ນອກຈາກນັ້ນ, ເສັ້ນຄໍາສັ່ງການກໍ່ສ້າງ, ຫຼືສາຍ, ແມ່ນສະຫນອງໃຫ້ເປັນ
string (string ນີ້​ອາດ​ຈະ​ມີ​ຫຼາຍ​ຄໍາ​ສັ່ງ​ທີ່​ຝັງ​ຢູ່​ໃນ​ມັນ​, ແຍກ​ໂດຍ​ໃຫມ່​
ສາຍ). 'ຄໍາສັ່ງ' ເອີ້ນວ່າດັ່ງຕໍ່ໄປນີ້:

ຄໍາສັ່ງ $env , , ;

ເປົ້າຫມາຍແມ່ນຂຶ້ນກັບບັນຊີລາຍຊື່ຂອງໄຟລ໌ທີ່ລະບຸໄວ້, ແລະວັດສະດຸປ້ອນຕ້ອງ
ໄດ້​ຮັບ​ການ​ສ້າງ​ສໍາ​ເລັດ​ຫຼື Cons ຈະ​ບໍ່​ພະ​ຍາ​ຍາມ​ທີ່​ຈະ​ສ້າງ​ເປົ້າ​ຫມາຍ.

ພາຍໃນຄໍາສັ່ງການກໍ່ສ້າງ, ການປ່ຽນແປງໃດໆຈາກສະພາບແວດລ້ອມການກໍ່ສ້າງອາດຈະເປັນ
ແນະນຳໂດຍການນຳໜ້າຊື່ຂອງຕົວແປການກໍ່ສ້າງດ້ວຍ `%'. ນີ້ແມ່ນ recursive:
ຄໍາສັ່ງຖືກຂະຫຍາຍອອກໄປຈົນກ່ວາບໍ່ມີການປ່ຽນແທນຫຼາຍ. ຖ້າ​ຫາກ​ວ່າ​ການ​ກໍ່​ສ້າງ​
ຕົວແປບໍ່ໄດ້ຖືກກໍານົດໄວ້ໃນສະພາບແວດລ້ອມ, ຈາກນັ້ນສະຕຣິງ null ຈະຖືກປ່ຽນແທນ. ກ
ສອງເທົ່າ `%%' ຈະຖືກແທນທີ່ດ້ວຍ `%' ດຽວໃນຄໍາສັ່ງກໍ່ສ້າງ.

ມີຫຼາຍຕົວແປ pseudo ທີ່ຈະຖືກຂະຫຍາຍອອກ:

%> ຊື່ໄຟລ໌ເປົ້າຫມາຍ (ໃນຄໍາສັ່ງຫຼາຍເປົ້າຫມາຍ, ນີ້ແມ່ນເປົ້າຫມາຍທໍາອິດສະເຫມີ
ກ່າວ).

%0 ຄືກັນກັບ `%>'.

%1, %2, ..., %9
ເຫຼົ່ານີ້ຫມາຍເຖິງໄຟລ໌ປ້ອນຂໍ້ມູນທໍາອິດຜ່ານເກົ້າ, ຕາມລໍາດັບ.

%< ຊຸດເຕັມຂອງວັດສະດຸປ້ອນ. ຖ້າອັນໃດອັນໜຶ່ງອັນໃດອັນໜຶ່ງເຫຼົ່ານີ້ໄດ້ນຳໃຊ້ຢູ່ບ່ອນອື່ນໃນ
ເສັ້ນຄໍາສັ່ງປະຈຸບັນ (ຜ່ານ `%1', `%2', ແລະອື່ນໆ), ຫຼັງຈາກນັ້ນເຫຼົ່ານັ້ນຈະຖືກລຶບອອກຈາກ
ລາຍການສະໜອງໃຫ້ໂດຍ `%<'. ພິຈາລະນາຄໍາສັ່ງຕໍ່ໄປນີ້ພົບໃນ a ທະບຽນ ເອກະສານ
ໃນ ການທົດສອບ ໄດເລກະທໍລີ:

ຄໍາສັ່ງ $env 'tgt', qw(foo bar baz), qq(
echo %< -i %1 > %>
echo %< -i %2 >> %>
echo %< -i %3 >> %>
);

If tgt ຈໍາເປັນຕ້ອງໄດ້ຮັບການປັບປຸງ, ຫຼັງຈາກນັ້ນນີ້ຈະເຮັດໃຫ້ການປະຕິບັດຂອງ
ປະຕິບັດຕາມຄໍາສັ່ງ, ສົມມຸດວ່າບໍ່ມີການ remapping ໄດ້ຖືກສ້າງຕັ້ງຂຶ້ນສໍາລັບ ການທົດສອບ
ໄດເລກະທໍລີ:

echo test/bar test/baz -i test/foo > test/tgt
echo test/foo test/baz -i test/bar >> test/tgt
echo test/foo test/bar -i test/baz >> test/tgt

ໃດໆຂອງຕົວແປ pseudo ຂ້າງເທິງອາດຈະຖືກປະຕິບັດຕາມທັນທີໂດຍຫນຶ່ງໃນດັ່ງຕໍ່ໄປນີ້
ຄໍາຕໍ່ທ້າຍເພື່ອເລືອກສ່ວນຫນຶ່ງຂອງຊື່ເສັ້ນທາງທີ່ຂະຫຍາຍ:

:a ເສັ້ນທາງຢ່າງແທ້ຈິງໄປຫາຊື່ໄຟລ໌
:b ໄດເລກະທໍລີບວກກັບຊື່ໄຟລ໌ທີ່ຖອດອອກຂອງຄໍາຕໍ່ທ້າຍໃດໆ
:d ໄດເລກະທໍລີ
:f ຊື່ໄຟລ໌
:s ຊື່ໄຟລ໌ຕໍ່ທ້າຍ
:F ຊື່ໄຟລ໌ຖືກຖອດອອກຂອງຄຳຕໍ່ທ້າຍອັນໃດນຶ່ງ

ສືບຕໍ່ກັບຕົວຢ່າງຂ້າງເທິງ, `%<:f' ຈະຂະຫຍາຍເປັນ `foo bar baz', ແລະ `%':d> ຈະ
ຂະຫຍາຍໄປຫາ 'ທົດສອບ'.

ມັນເປັນໄປໄດ້ທີ່ຈະຂຽນຄືນສ່ວນຫນຶ່ງຂອງຄໍາສັ່ງໂດຍການຂຽນໂປຼແກຼມໂດຍການປິດບາງສ່ວນຂອງມັນ
ລະຫວ່າງ `%[' ແລະ `%]'. ນີ້ຈະໂທຫາຕົວແປການກໍ່ສ້າງທີ່ມີຊື່ເປັນຄໍາທໍາອິດ
enclosed ໃນວົງເລັບເປັນການອ້າງອິງລະຫັດ Perl; ຜົນໄດ້ຮັບຂອງການໂທນີ້ຈະຖືກນໍາໃຊ້
ເພື່ອທົດແທນເນື້ອໃນຂອງວົງເລັບໃນແຖວຄໍາສັ່ງ. ສໍາລັບຕົວຢ່າງ, ໃຫ້
ໄຟລ໌ປ້ອນຂໍ້ມູນທີ່ມີຢູ່ແລ້ວທີ່ມີຊື່ tgt.in:

@keywords = qw(foo bar baz);
$env = new cons(X_COMMA => sub { join(",", @_) });
ຄໍາສັ່ງ $env 'tgt', 'tgt.in', qq(
echo '# ຄໍາສໍາຄັນ: %[X_COMMA @keywords %]' > %>
cat %< >> %>
);

ນີ້ຈະດໍາເນີນການ:

echo '# ຄໍາສໍາຄັນ: foo,bar,baz'> tgt
cat tgt.in >> tgt

ຫຼັງ​ຈາກ​ການ​ທົດ​ແທນ​ທີ່​ເກີດ​ຂຶ້ນ​, ຊ່ອຍ​ແນ່​ຂອງ​ຊ່ອງ​ຂາວ​ແມ່ນ​ປ່ຽນ​ເປັນ​ຊ່ອງ​ຫວ່າງ​ດຽວ​, ແລະ​
ພື້ນທີ່ສີຂາວຊັ້ນນໍາແລະທາງຫລັງຖືກລົບລ້າງ. ດັ່ງນັ້ນຈຶ່ງບໍ່ສາມາດແນະນໍາໄດ້
ຊ່ອງຫວ່າງສີຂາວທີ່ມີຄວາມຍາວປ່ຽນແປງໄດ້ໃນສະຕຣິງທີ່ຜ່ານເຂົ້າໄປໃນຄໍາສັ່ງ, ໂດຍບໍ່ມີການໃຊ້ບາງອັນ
ການຈັດລຽງຂອງວົງຢືມ shell.

ຖ້າສະຕຣິງຄຳສັ່ງຫຼາຍແຖວຖືກສະໜອງໃຫ້, ຄຳສັ່ງຈະຖືກດຳເນີນການຕາມລຳດັບ. ຖ້າ​ມີ
ຂອງຄໍາສັ່ງລົ້ມເຫລວ, ຫຼັງຈາກນັ້ນບໍ່ມີສ່ວນທີ່ເຫຼືອຖືກປະຕິບັດ, ແລະເປົ້າຫມາຍບໍ່ໄດ້ຖືກຫມາຍເປັນ
ປັບປຸງ, ie ລາຍເຊັນໃຫມ່ບໍ່ໄດ້ເກັບຮັກສາໄວ້ສໍາລັບເປົ້າຫມາຍ.

ໂດຍປົກກະຕິ, ຖ້າຄໍາສັ່ງທັງຫມົດປະສົບຜົນສໍາເລັດ, ແລະສົ່ງຄືນສະຖານະສູນ (ຫຼືເວທີໃດກໍ່ຕາມ,
ຕົວຊີ້ບອກສະເພາະຂອງຄວາມສໍາເລັດແມ່ນຕ້ອງການ), ຫຼັງຈາກນັ້ນ, ລາຍເຊັນໃຫມ່ຈະຖືກເກັບໄວ້ສໍາລັບ
ເປົ້າ​ຫມາຍ. ຖ້າຄໍາສັ່ງຜິດພາດລາຍງານຄວາມສໍາເລັດເຖິງແມ່ນວ່າຫຼັງຈາກຄວາມລົ້ມເຫລວ, ຫຼັງຈາກນັ້ນ Cons ຈະ
ສົມມຸດວ່າໄຟລ໌ເປົ້າຫມາຍທີ່ສ້າງຂຶ້ນໂດຍຄໍາສັ່ງນັ້ນແມ່ນຖືກຕ້ອງແລະທັນສະໄຫມ.

ຄໍາທໍາອິດຂອງແຕ່ລະສາຍຄໍາສັ່ງ, ຫຼັງຈາກການຂະຫຍາຍ, ຖືວ່າສາມາດປະຕິບັດໄດ້
ຄໍາສັ່ງຊອກຫາຢູ່ໃນຕົວແປສະພາບແວດລ້ອມ 'PATH' (ເຊິ່ງແມ່ນ, ໃນທາງກັບກັນ, ກໍານົດໂດຍ
'ENV' ຕົວແປການກໍ່ສ້າງ). ຖ້າຄໍາສັ່ງນີ້ຖືກພົບເຫັນຢູ່ໃນເສັ້ນທາງ, ຫຼັງຈາກນັ້ນເປົ້າຫມາຍຈະ
ຂຶ້ນກັບມັນ: ຄໍາສັ່ງຈະຖືກສ້າງໂດຍອັດຕະໂນມັດ, ຕາມຄວາມຈໍາເປັນ. ມັນ
ເປັນໄປໄດ້ທີ່ຈະຂຽນຄໍາສັ່ງຫຼາຍສ່ວນກັບບາງ shells, ແຍກໂດຍເຄິ່ງຈໍ້າສອງເມັດ. ພຽງແຕ່
ຄໍາຄໍາສັ່ງທໍາອິດຈະຂຶ້ນກັບ, ຢ່າງໃດກໍຕາມ, ດັ່ງນັ້ນຖ້າທ່ານຂຽນສາຍຄໍາສັ່ງຂອງທ່ານ
ດ້ວຍວິທີນີ້, ເຈົ້າຕ້ອງຕັ້ງການເພິ່ງພາອາໄສຢ່າງຈະແຈ້ງ (ດ້ວຍວິທີ 'ຂຶ້ນກັບ'), ຫຼື
ໃຫ້ແນ່ໃຈວ່າຄໍາສັ່ງທີ່ທ່ານກໍາລັງໃຊ້ແມ່ນຄໍາສັ່ງລະບົບທີ່ຄາດວ່າຈະເປັນ
ມີໃຫ້. ຖ້າມັນບໍ່ສາມາດໃຊ້ໄດ້, ແນ່ນອນ, ທ່ານຈະໄດ້ຮັບຄວາມຜິດພາດ.

ຖ້າຄໍາສັ່ງໃດໆ (ແມ້ແຕ່ຫນຶ່ງໃນຄໍາສັ່ງຫຼາຍແຖວ) ເລີ່ມຕົ້ນດ້ວຍ `[perl]', ສ່ວນທີ່ເຫຼືອ
ຂອງເສັ້ນຄໍາສັ່ງນັ້ນຈະຖືກປະເມີນໂດຍ Perl ແລ່ນແທນທີ່ຈະຖືກ forked ໂດຍ
ແກະ. ຖ້າມີຂໍ້ຜິດພາດເກີດຂຶ້ນໃນການວິເຄາະ Perl ຫຼືຖ້າການສະແດງຜົນ Perl ກັບຄືນ 0 ຫຼື
undef, ຄໍາສັ່ງຈະຖືກພິຈາລະນາວ່າລົ້ມເຫລວ. ຕົວຢ່າງ, ນີ້ແມ່ນງ່າຍດາຍ
ຄໍາສັ່ງທີ່ສ້າງໄຟລ໌ 'foo' ໂດຍກົງຈາກ Perl:

$env = new cons();
ຄໍາສັ່ງ $env 'foo',
qq([perl] open(FOO,'>foo');ພິມ FOO "hi\n"; close(FOO); 1);

ໃຫ້ສັງເກດວ່າເມື່ອຄໍາສັ່ງຖືກປະຕິບັດ, ທ່ານຢູ່ໃນຊຸດດຽວກັນກັບເວລາທີ່ ກໍ່ສ້າງ
or ທະບຽນ ໄຟລ໌ໄດ້ຖືກອ່ານ, ດັ່ງນັ້ນທ່ານສາມາດໂທຫາຫນ້າທີ່ Perl ທີ່ທ່ານໄດ້ກໍານົດໄວ້ໃນອັນດຽວກັນ
ກໍ່ສ້າງ or ທະບຽນ ໄຟລ໌ທີ່ 'ຄໍາສັ່ງ' ປາກົດ:

$env = new cons();
sub create_file {
$file ຂອງຂ້ອຍ = shift;
ເປີດ(FILE, ">$file");
ພິມ FILE "hi\n";
ປິດ(FILE);
return 1
}
ຄໍາສັ່ງ $env 'foo', "[perl] &create_file('%>')";

ສະຕຣິງ Perl ຈະຖືກນໍາໃຊ້ເພື່ອສ້າງລາຍເຊັນສໍາລັບໄຟລ໌ທີ່ໄດ້ມາ, ດັ່ງນັ້ນຖ້າທ່ານ
ປ່ຽນສະຕຣິງ, ໄຟລ໌ຈະຖືກສ້າງໃຫມ່. ເນື້ອ​ໃນ​ຂອງ subroutines ໃດ​ຫນຶ່ງ​ທີ່​ທ່ານ​ໂທ​ຫາ​,
ແນວໃດກໍ່ຕາມ, ບໍ່ແມ່ນສ່ວນຫນຶ່ງຂອງລາຍເຊັນ, ດັ່ງນັ້ນຖ້າທ່ານດັດແປງ subroutine ທີ່ເອີ້ນວ່າ
`create_file' ຂ້າງເທິງ, ເປົ້າຫມາຍຈະ ບໍ່ ໄດ້​ຮັບ​ການ​ສ້າງ​ໃຫມ່​. ຜູ້ໃຊ້ Caveat.

Cons ປົກກະຕິພິມຄໍາສັ່ງກ່ອນທີ່ຈະປະຕິບັດມັນ. ພຶດຕິກໍານີ້ຖືກສະກັດກັ້ນຖ້າຫາກວ່າ
ລັກສະນະທໍາອິດຂອງຄໍາສັ່ງແມ່ນ `@'. ໃຫ້ສັງເກດວ່າທ່ານອາດຈະຈໍາເປັນຕ້ອງແຍກ `@' ຈາກ
ຊື່ຄໍາສັ່ງຫຼືຫນີມັນເພື່ອປ້ອງກັນບໍ່ໃຫ້ `@cmd' ເບິ່ງຄືວ່າ array ກັບ Perl quote
ຜູ້ປະກອບການທີ່ປະຕິບັດ interpolation:

# ຄໍາສັ່ງທໍາອິດແມ່ນບໍ່ຖືກຕ້ອງ,
# ເນື່ອງຈາກວ່າ "@cp" ຄ້າຍຄື array
# ໄປຫາ Perl qq // ຟັງຊັນ.
# ໃຊ້ຮູບແບບທີສອງແທນ.
ຄໍາສັ່ງ $env 'foo', 'foo.in', qq(
@cp %< tempfile
@ cp tempfile %>
);

ຖ້າມີຕົວອັກສອນເມຕາຂອງແກະຢູ່ບ່ອນໃດກໍໄດ້ໃນແຖວຄຳສັ່ງທີ່ຂະຫຍາຍ, ເຊັ່ນ: `<',
`>', quotes, ຫຼື semi-colon, ຫຼັງຈາກນັ້ນຄໍາສັ່ງຈະຖືກປະຕິບັດໂດຍການເອີ້ນ a
ແກະ. ນີ້ຫມາຍຄວາມວ່າຄໍາສັ່ງເຊັ່ນ:

cd foo

ໂດຍທົ່ວໄປແລ້ວຄົນດຽວຈະລົ້ມເຫລວ, ເພາະວ່າບໍ່ມີຄໍາສັ່ງ 'cd' ຢູ່ໃນເສັ້ນທາງ. ແຕ່ຄໍາສັ່ງ
ຊ່ອຍແນ່:

cd $<:d; tar cf $>:f $<:f

ເມື່ອຂະຫຍາຍອອກຈະຍັງບັນຈຸ Shell meta character semi-colon, ແລະ shell ຈະເປັນ
ຮຽກ​ຮ້ອງ​ໃຫ້​ຕີ​ຄວາມ​ຫມາຍ​ຄໍາ​ສັ່ງ​. ເນື່ອງຈາກວ່າ 'cd' ຖືກຕີຄວາມໂດຍ sub-shell ນີ້, ຄໍາສັ່ງ
ຈະ​ດຳ​ເນີນ​ການ​ຕາມ​ທີ່​ຄາດ​ໄວ້.

ເພື່ອກໍານົດຄໍາສັ່ງທີ່ມີເປົ້າຫມາຍຫຼາຍ, ທ່ານສາມາດກໍານົດການອ້າງອີງເຖິງບັນຊີລາຍຊື່ຂອງ
ເປົ້າໝາຍ. ໃນ Perl, ການອ້າງອີງລາຍຊື່ສາມາດຖືກສ້າງຂື້ນໂດຍການປິດບັນຊີລາຍຊື່ໃນວົງເລັບສີ່ຫຼ່ຽມ.
ດັ່ງນັ້ນຄໍາສັ່ງຕໍ່ໄປນີ້:

ຄໍາສັ່ງ $env ['foo.h', 'foo.c'], 'foo.template', q(
gen %1
);

ສາມາດຖືກນໍາໃຊ້ໃນກໍລະນີທີ່ຄໍາສັ່ງ 'gen' ສ້າງສອງໄຟລ໌, ທັງສອງ foo.h ແລະ foo.c.

ໄດ້ 'ວັດຖຸ' ວິທີການ

ວິທີການ 'objects' ຈັດເພື່ອສ້າງໄຟລ໌ວັດຖຸທີ່ກົງກັບທີ່ລະບຸ
ໄຟລ໌ແຫຼ່ງ. ມັນ​ຖືກ​ຮຽກ​ຮ້ອງ​ດັ່ງ​ທີ່​ສະ​ແດງ​ໃຫ້​ເຫັນ​ຂ້າງ​ລຸ່ມ​ນີ້​:

@files = ວັດຖຸ $env ;

ພາຍໃຕ້ Unix, ແຫຼ່ງໄຟລ໌ທີ່ລົງທ້າຍດ້ວຍ .s ແລະ .c ປະຈຸບັນໄດ້ຮັບການສະຫນັບສະຫນູນ, ແລະຈະຖືກລວບລວມ
ເຂົ້າໄປໃນຊື່ຂອງໄຟລ໌ດຽວກັນທີ່ລົງທ້າຍດ້ວຍ .o. ໂດຍຄ່າເລີ່ມຕົ້ນ, ໄຟລ໌ທັງຫມົດແມ່ນຖືກສ້າງຂຶ້ນໂດຍການເອີ້ນ
ຄໍາສັ່ງພາຍນອກທີ່ເປັນຜົນມາຈາກການຂະຫຍາຍຕົວແປການກໍ່ສ້າງ 'CCCOM', ກັບ
`%<' ແລະ `%>' ຕັ້ງເປັນໄຟລ໌ແຫຼ່ງ ແລະວັດຖຸ, ຕາມລໍາດັບ (ເບິ່ງວິທີການ 'ຄໍາສັ່ງ'
ສໍາລັບລາຍລະອຽດການຂະຫຍາຍ). ຕົວແປ 'CPPPATH' ຍັງຖືກໃຊ້ໃນເວລາສະແກນໄຟລ໌ແຫຼ່ງ
ສໍາລັບການເພິ່ງພາອາໄສ. ນີ້ແມ່ນບັນຊີລາຍຊື່ເສັ້ນທາງທີ່ແຍກອອກຈາກຈໍ້າສອງເມັດ, ແລະຍັງຖືກນໍາໃຊ້ເພື່ອສ້າງ
ຕົວແປການກໍ່ສ້າງ `_IFLAGS,' ເຊິ່ງຈະມີລາຍຊື່ທີ່ເຫມາະສົມຂອງ -`I'
ທາງເລືອກສໍາລັບການລວບລວມ. ທຸກຊື່ເສັ້ນທາງທີ່ກ່ຽວຂ້ອງໃນ 'CPPPATH' ແມ່ນຖືກຕີຄວາມເປັນພີ່ນ້ອງກັນ
ໄປຫາໄດເລກະທໍລີທີ່ສະພາບແວດລ້ອມການກໍ່ສ້າງທີ່ກ່ຽວຂ້ອງໄດ້ຖືກສ້າງຂື້ນ (ຢ່າງແທ້ຈິງ
ແລະ​ຊື່​ພີ່​ນ້ອງ​ເທິງ​ອາດ​ຈະ​ໄດ້​ຮັບ​ການ​ນໍາ​ໃຊ້). ຕົວແປນີ້ຖືກໃຊ້ໂດຍ 'CCCOM'. ພຶດຕິກຳ
ຄໍາສັ່ງນີ້ສາມາດຖືກດັດແກ້ໂດຍການປ່ຽນແປງໃດໆຂອງຕົວແປທີ່ interpolated
ເຂົ້າໄປໃນ `CCCOM', ເຊັ່ນ: `CC', `CFLAGS', ແລະ, ທາງອ້ອມ, `CPPPATH'. ມັນກໍ່ເປັນໄປໄດ້
ແທນຄ່າຂອງ 'CCCOM', ຕົວຂອງມັນເອງ. ເພື່ອຄວາມສະດວກ, ໄຟລ໌ນີ້ສົ່ງຄືນບັນຊີລາຍຊື່ຂອງ
ຊື່ໄຟລ໌ວັດຖຸ.

ໄດ້ `ໂຄງການ' ວິທີການ

ວິທີການ 'ໂຄງການ' ຈັດລຽງເພື່ອເຊື່ອມຕໍ່ໂຄງການທີ່ລະບຸໄວ້ກັບວັດຖຸທີ່ລະບຸ
ໄຟລ໌. ມັນ​ຖືກ​ຮຽກ​ຮ້ອງ​ໃນ​ລັກ​ສະ​ນະ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

ໂຄງການ $env , ;

ຊື່ໂຄງການຈະມີມູນຄ່າຂອງຕົວແປການກໍ່ສ້າງ 'SUFEXE' ຕໍ່ທ້າຍ (ໂດຍ
ຄ່າເລີ່ມຕົ້ນ, `.exe' ໃນລະບົບ Win32, ບໍ່ມີຫຍັງຢູ່ໃນລະບົບ Unix) ຖ້າຄໍາຕໍ່ທ້າຍບໍ່ແມ່ນແລ້ວ.
ປະຈຸບັນ.

ໄຟລ໌ຕົ້ນສະບັບອາດຈະຖືກລະບຸແທນໄຟລ໌ວັດຖຸ -- ວິທີການ 'ວັດຖຸ' ຈະເປັນ
invoked ການ​ຈັດ​ແຈງ​ການ​ປ່ຽນ​ໄຟລ​໌​ທັງ​ຫມົດ​ເຂົ້າ​ໄປ​ໃນ​ໄຟລ​໌​ວັດ​ຖຸ​, ແລະ​ເພາະ​ສະ​ນັ້ນ​ທັງ​ຫມົດ​
ການສັງເກດການກ່ຽວກັບວິທີ 'ວັດຖຸ', ຂ້າງເທິງ, ຍັງໃຊ້ກັບວິທີການນີ້.

ການເຊື່ອມໂຍງຕົວຈິງຂອງໂຄງການຈະຖືກຈັດການໂດຍຄໍາສັ່ງພາຍນອກເຊິ່ງຜົນໄດ້ຮັບ
ຈາກ​ການ​ຂະ​ຫຍາຍ​ຕົວ​ປ່ຽນ​ການ​ກໍ່​ສ້າງ `LINKCOM​, ກັບ `%<​' ຕັ້ງ​ໄຟລ​໌​ວັດ​ຖຸ​ເປັນ​
ຖືກເຊື່ອມຕໍ່ (ໃນຄໍາສັ່ງທີ່ນໍາສະເຫນີ), ແລະ `%>' ກໍານົດເປົ້າຫມາຍ (ເບິ່ງວິທີການ 'ຄໍາສັ່ງ'
ສໍາລັບລາຍລະອຽດການຂະຫຍາຍ). ຜູ້ໃຊ້ອາດຈະກໍານົດຕົວແປເພີ່ມເຕີມໃນການກໍ່ສ້າງ
ສະພາບແວດລ້ອມ, ລວມທັງ `LINK', ເພື່ອກໍານົດໂຄງການທີ່ຈະໃຊ້ສໍາລັບການເຊື່ອມໂຍງ, `LIBPATH', a
ບັນຊີລາຍຊື່ທີ່ແຍກອອກຈາກຈໍ້າສອງເມັດຂອງເສັ້ນທາງຄົ້ນຫາຫ້ອງສະຫມຸດ, ສໍາລັບການນໍາໃຊ້ສະເພາະຫ້ອງສະຫມຸດຂອງ
ຮູບແບບ - ລີບ, ແລະ `LIBS', ລະບຸລາຍຊື່ຫ້ອງສະໝຸດເພື່ອເຊື່ອມຕໍ່ (ໃນທັງສອງ - ລີບ
ແບບຟອມຫຼືພຽງແຕ່ເປັນຊື່ເສັ້ນທາງ. ຊື່ເສັ້ນທາງທີ່ກ່ຽວຂ້ອງໃນທັງ 'LIBPATH' ແລະ 'LIBS' ຖືກຕີຄວາມໝາຍ
ກ່ຽວຂ້ອງກັບໄດເລກະທໍລີທີ່ສະພາບແວດລ້ອມການກໍ່ສ້າງທີ່ກ່ຽວຂ້ອງຖືກສ້າງຂື້ນ
(ຊື່ສົມມຸດຕິຖານ ແລະຊື່ທີ່ກ່ຽວຂ້ອງອາດຈະຖືກໃຊ້ເຊັ່ນກັນ). Cons ຕັ້ງຄ່າອັດຕະໂນມັດ
ການຂື້ນກັບຫ້ອງສະຫມຸດໃດໆທີ່ໄດ້ກ່າວໄວ້ໃນ `LIBS': ຫ້ອງສະຫມຸດເຫຼົ່ານັ້ນຈະຖືກສ້າງຂື້ນກ່ອນ
ຄໍາສັ່ງຖືກເຊື່ອມຕໍ່.

ໄດ້ ຫໍສະໝຸດ ວິທີການ

ວິທີການ 'ຫ້ອງສະຫມຸດ' ຈັດແຈງເພື່ອສ້າງຫ້ອງສະຫມຸດທີ່ລະບຸຈາກວັດຖຸທີ່ລະບຸ
ໄຟລ໌. ມັນ​ຖືກ​ຮຽກ​ຮ້ອງ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

ຫ້ອງສະໝຸດ $env , ;

ຊື່ຫ້ອງສະໝຸດຈະມີມູນຄ່າຂອງຕົວແປການກໍ່ສ້າງ 'SUFLIB' ຕໍ່ທ້າຍ (ໂດຍ
ຄ່າເລີ່ມຕົ້ນ, `.lib' ໃນລະບົບ Win32, `.a' ໃນລະບົບ Unix) ຖ້າຄຳຕໍ່ທ້າຍບໍ່ແມ່ນແລ້ວ
ປະຈຸບັນ.

ໄຟລ໌ຕົ້ນສະບັບອາດຈະຖືກລະບຸແທນໄຟລ໌ວັດຖຸ -- ວິທີການ 'ວັດຖຸ' ຈະເປັນ
invoked ການ​ຈັດ​ແຈງ​ການ​ປ່ຽນ​ໄຟລ​໌​ທັງ​ຫມົດ​ເຂົ້າ​ໄປ​ໃນ​ໄຟລ​໌​ວັດ​ຖຸ​, ແລະ​ເພາະ​ສະ​ນັ້ນ​ທັງ​ຫມົດ​
ການສັງເກດການກ່ຽວກັບວິທີ 'ວັດຖຸ', ຂ້າງເທິງ, ຍັງໃຊ້ກັບວິທີການນີ້.

ການສ້າງຫ້ອງສະຫມຸດຕົວຈິງຈະຖືກຈັດການໂດຍຄໍາສັ່ງພາຍນອກເຊິ່ງຜົນໄດ້ຮັບ
ຈາກ​ການ​ຂະ​ຫຍາຍ​ຕົວ​ປ່ຽນ​ການ​ກໍ່​ສ້າງ `ARCOM​, ກັບ `%<​' ຕັ້ງ​ເປັນ​ສະ​ມາ​ຊິກ​ຫ້ອງ​ສະ​ຫມຸດ (ໃນ
ຄໍາ​ສັ່ງ​ທີ່​ນໍາ​ສະ​ເຫນີ​)​, ແລະ `%​>​' ກັບ​ຫ້ອງ​ສະ​ຫມຸດ​ທີ່​ຈະ​ສ້າງ​ຕັ້ງ​ຂຶ້ນ (ເບິ່ງ​ວິ​ທີ​ການ "ຄໍາ​ສັ່ງ​" ສໍາ​ລັບ​ການ​
ລາຍລະອຽດການຂະຫຍາຍ). ຜູ້ໃຊ້ອາດຈະກໍານົດຕົວແປໃນສະພາບແວດລ້ອມການກໍ່ສ້າງທີ່ຈະ
ຜົນກະທົບຕໍ່ການເຮັດວຽກຂອງຄໍາສັ່ງ. ເຫຼົ່ານີ້ລວມມີ `AR', ໂປຣແກຣມເກັບຂໍ້ມູນເພື່ອໃຊ້,
`ARFLAGS', ເຊິ່ງສາມາດຖືກໃຊ້ເພື່ອດັດແປງທຸງທີ່ມອບໃຫ້ກັບໂຄງການທີ່ລະບຸໄວ້ໂດຍ `AR',
ແລະ 'RANLIB', ຊື່ຂອງໂປຣແກຣມສ້າງດັດສະນີເກັບມ້ຽນ, ຖ້າຕ້ອງການ (ຖ້າສະເພາະ
ຄວາມຕ້ອງການບໍ່ຈໍາເປັນຕ້ອງມີຫນ້າທີ່ສຸດທ້າຍ, ຫຼັງຈາກນັ້ນ 'ARCOM' ຕ້ອງໄດ້ຮັບການກໍານົດໃຫມ່ເພື່ອບໍ່
ອ້າງອິງ `RANLIB').

ວິທີການ 'ຫ້ອງສະຫມຸດ' ອະນຸຍາດໃຫ້ຫ້ອງສະຫມຸດດຽວກັນຖືກລະບຸໄວ້ໃນຫຼາຍວິທີ
ຄຳຮຽກຮ້ອງ. ທັງໝົດຂອງວັດຖຸປະກອບສ່ວນຈາກການຮຽກຮ້ອງທັງໝົດ (ເຊິ່ງອາດຈະມາຈາກ
ໄດເລກະທໍລີທີ່ແຕກຕ່າງກັນ) ຖືກລວມເຂົ້າກັນແລະສ້າງຂຶ້ນໂດຍຄໍາສັ່ງເກັບຂໍ້ມູນດຽວ. ຫມາຍ​ເຫດ​,
ຢ່າງໃດກໍຕາມ, ວ່າຖ້າທ່ານຕັດການກໍ່ສ້າງເພື່ອໃຫ້ພຽງແຕ່ສ່ວນຫນຶ່ງຂອງຫ້ອງສະຫມຸດໄດ້ຖືກລະບຸ, ຫຼັງຈາກນັ້ນພຽງແຕ່
ສ່ວນຂອງຫ້ອງສະໝຸດນັ້ນຈະຖືກສ້າງຂື້ນ (ສ່ວນທີ່ເຫຼືອຈະຫາຍໄປ!).

ໄດ້ `ໂມດູນ' ວິທີການ

ວິທີການ 'ໂມດູນ' ແມ່ນການປະສົມປະສານຂອງວິທີການ 'ໂຄງການ' ແລະ 'ຄໍາສັ່ງ'. ແທນ​ທີ່​ຈະ
ການສ້າງໂຄງການທີ່ສາມາດປະຕິບັດໄດ້ໂດຍກົງ, ຄໍາສັ່ງນີ້ຊ່ວຍໃຫ້ທ່ານສາມາດກໍານົດຂອງທ່ານເອງ
ຄໍາສັ່ງທີ່ຈະສ້າງໂມດູນຕົວຈິງ. ວິ​ທີ​ການ​ແມ່ນ​ຮຽກ​ຮ້ອງ​ໃຫ້​ມີ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

ໂມດູນ $env , , ;

ຄໍາສັ່ງນີ້ແມ່ນເປັນປະໂຫຍດໃນກໍລະນີທີ່ທ່ານຕ້ອງການສ້າງ, ຕົວຢ່າງ, ແບບເຄື່ອນໄຫວ
ໂມດູນທີ່ໂຫລດ, ຫຼືຫ້ອງສະຫມຸດລະຫັດທີ່ເຊື່ອມໂຍງແບບຄົງທີ່.

ໄດ້ ຂຶ້ນກັບ ວິທີການ

ວິທີການ 'Depends' ອະນຸຍາດໃຫ້ທ່ານລະບຸການເພິ່ງພາອາໄສເພີ່ມເຕີມສໍາລັບເປົ້າຫມາຍໃດຫນຶ່ງ. ມັນ​ແມ່ນ
ຮຽກ​ຮ້ອງ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

ຂຶ້ນກັບ $env , ;

ອັນນີ້ອາດຈະເປັນປະໂຫຍດເປັນບາງໂອກາດ, ໂດຍສະເພາະໃນກໍລະນີທີ່ບໍ່ມີເຄື່ອງສະແກນຢູ່ (ຫຼື
ຂຽນໄດ້) ສໍາລັບປະເພດສະເພາະຂອງໄຟລ໌. ໂດຍປົກກະຕິ, ການເພິ່ງພາອາໄສແມ່ນຄິດໄລ່
ອັດຕະໂນມັດຈາກການລວມກັນຂອງການຂຶ້ນກັບຢ່າງຊັດເຈນທີ່ຕັ້ງຂຶ້ນໂດຍວິທີການ
invocation ຫຼືໂດຍການສະແກນໄຟລ໌ແຫຼ່ງ.

ຊຸດຂອງຕົວອ້າງອິງທີ່ຄືກັນສຳລັບຫຼາຍເປົ້າໝາຍອາດຈະຖືກລະບຸໂດຍໃຊ້ການອ້າງອີງເຖິງ
ບັນ​ຊີ​ລາຍ​ຊື່​ຂອງ​ເປົ້າ​ຫມາຍ​. ໃນ Perl, ການອ້າງອີງລາຍຊື່ສາມາດຖືກສ້າງຂື້ນໂດຍການປິດບັນຊີລາຍຊື່ເປັນສີ່ຫຼ່ຽມມົນ
ວົງເລັບ. ດັ່ງນັ້ນຄໍາສັ່ງຕໍ່ໄປນີ້:

ຂຶ້ນກັບ $env ['foo', 'bar'], 'input_file_1', 'input_file_2';

ກໍານົດວ່າທັງສອງ ຟູ ແລະ ພາທະນາຍຄວາມ ໄຟລ໌ແມ່ນຂຶ້ນກັບໄຟລ໌ປ້ອນຂໍ້ມູນທີ່ມີລາຍຊື່.

ໄດ້ 'ບໍ່ສົນໃຈ' ວິທີການ

ວິທີການ 'ບໍ່ສົນໃຈ' ຊ່ວຍໃຫ້ທ່ານບໍ່ສົນໃຈກັບຄວາມເພິ່ງພາອາໄສຢ່າງຊັດເຈນທີ່ Cons infers ກ່ຽວກັບມັນ.
ຂອງຕົນເອງ. ມັນ​ຖືກ​ຮຽກ​ຮ້ອງ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

ບໍ່ສົນໃຈ ;

ນີ້ສາມາດຖືກນໍາໃຊ້ເພື່ອຫຼີກເວັ້ນການ recompilation ເນື່ອງຈາກການປ່ຽນແປງໃນໄຟລ໌ header ລະບົບຫຼື
ຜົນປະໂຫຍດທີ່ຮູ້ວ່າບໍ່ມີຜົນກະທົບຕໍ່ເປົ້າຫມາຍທີ່ສ້າງຂຶ້ນ.

ສໍາລັບຕົວຢ່າງ, ໂປຣແກຣມຖືກສ້າງຢູ່ໃນໄດເລກະທໍລີທີ່ຕິດຢູ່ກັບ NFS ໃນຫຼາຍລະບົບທີ່
ມີສໍາເນົາທີ່ແຕກຕ່າງກັນຂອງ stdio.h, ຄວາມແຕກຕ່າງຈະສົ່ງຜົນກະທົບຕໍ່ລາຍເຊັນຂອງທັງຫມົດ
ໄດ້ມາຈາກເປົ້າຫມາຍທີ່ສ້າງຂຶ້ນຈາກໄຟລ໌ແຫຼ່ງທີ່ `#include '. ນີ້ຈະເຮັດໃຫ້ເກີດທັງຫມົດ
ເປົ້າຫມາຍເຫຼົ່ານັ້ນຈະຖືກສ້າງໃຫມ່ໃນເວລາທີ່ມີການປ່ຽນແປງລະບົບ. ຖ້າ​ຫາກ​ວ່າ​ນີ້​ບໍ່​ແມ່ນ​ພຶດ​ຕິ​ກໍາ​ທີ່​ຕ້ອງ​ການ​,
ຫຼັງ​ຈາກ​ນັ້ນ​, ເສັ້ນ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​ຈະ​ເອົາ​ການ​ຂຶ້ນ​ກັບ​ການ​ stdio.h file:

ບໍ່ສົນໃຈ '^/usr/include/stdio\.h$';

ໃຫ້ສັງເກດວ່າການໂຕ້ຖຽງກັບວິທີການ 'ບໍ່ສົນໃຈ' ແມ່ນການສະແດງອອກເປັນປົກກະຕິ, ພິເສດ
ຕົວອັກສອນຕ້ອງຖືກຫລົບຫນີແລະເຈົ້າອາດຈະຕ້ອງການສະມໍຈຸດເລີ່ມຕົ້ນຫຼືສິ້ນສຸດຂອງ
ສະແດງອອກດ້ວຍຕົວອັກສອນ `^' ຫຼື `$'.

ໄດ້ ເກືອ ວິທີການ

ວິທີການ 'ເກືອ' ຈະເພີ່ມມູນຄ່າຄົງທີ່ໃນການຄິດໄລ່ລາຍເຊັນສໍາລັບທຸກໆທີ່ໄດ້ມາ
ໄຟລ໌. ມັນ​ຖືກ​ຮຽກ​ຮ້ອງ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

ເກືອ $string;

ການປ່ຽນຄ່າຂອງເກືອຈະບັງຄັບໃຫ້ມີການສ້າງໃຫມ່ທີ່ສົມບູນຂອງທຸກໄຟລ໌ທີ່ໄດ້ມາ. ນີ້ສາມາດເປັນ
ໃຊ້ເພື່ອບັງຄັບໃຫ້ສ້າງຄືນໃຫມ່ໃນສະຖານະການທີ່ຕ້ອງການ. ຍົກ​ຕົວ​ຢ່າງ,

ເກືອ `uname -s`;

ຈະບັງຄັບໃຫ້ສ້າງຄືນໃຫມ່ຢ່າງສົມບູນຂອງທຸກໄຟລ໌ທີ່ໄດ້ມາທຸກຄັ້ງທີ່ລະບົບປະຕິບັດການເປີດ
ເຊິ່ງການກໍ່ສ້າງແມ່ນປະຕິບັດ (ຕາມການລາຍງານໂດຍ `uname -s') ການປ່ຽນແປງ.

ໄດ້ 'ໃຊ້ແຄດ' ວິທີການ

ວິທີການ 'UseCache' ແນະນໍາ Cons ເພື່ອຮັກສາ cache ຂອງໄຟລ໌ທີ່ໄດ້ມາ, ເພື່ອແບ່ງປັນ.
ໃນບັນດາຕົ້ນໄມ້ກໍ່ສ້າງແຍກຕ່າງຫາກຂອງໂຄງການດຽວກັນ.

UseCache("cache/ ") ⎪⎪ ເຕືອນ("ບໍ່ພົບ cache directory");

ໄດ້ 'ເສັ້ນທາງແຫຼ່ງ' ວິທີການ

ຄະນິດສາດ 'SourcePath' ຕອບຊື່ເສັ້ນທາງແຫຼ່ງທີ່ແທ້ຈິງຂອງໄຟລ໌, ກົງກັນຂ້າມກັບ
ຊື່ເສັ້ນທາງພາຍໃນໄດເລກະທໍລີສ້າງ. ມັນ​ຖືກ​ຮຽກ​ຮ້ອງ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

$path = SourcePath ;

ໄດ້ ເສັ້ນທາງ ConsPath ວິທີການ

ວິທີການ 'ConsPath' ກັບຄືນມາເປັນຄວາມຈິງຖ້າເສັ້ນທາງທີ່ສະຫນອງໃຫ້ເປັນໄຟລ໌ທີ່ມາຈາກ, ແລະສົ່ງຄືນ
undef (false) ຖ້າບໍ່ດັ່ງນັ້ນ. ມັນ​ຖືກ​ຮຽກ​ຮ້ອງ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

$result = ConsPath ;

ໄດ້ `ທາງແຍກ' ວິທີການ

ວິທີການ 'SplitPath' ຊອກຫາຊື່ເສັ້ນທາງຫຼາຍອັນໃນສະຕຣິງທີ່ແຍກອອກເປັນຄ່າເລີ່ມຕົ້ນ
ຕົວແຍກເສັ້ນທາງສໍາລັບລະບົບປະຕິບັດການ (':' ໃນລະບົບ UNIX, ';' ໃນ Windows NT), ແລະ
ສົ່ງຄືນຊື່ທີ່ມີຄຸນສົມບັດຄົບຖ້ວນ. ມັນ​ຖືກ​ຮຽກ​ຮ້ອງ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

@paths = SplitPath ;

ວິທີການ 'SplitPath' ຈະປ່ຽນຊື່ທີ່ນຳໜ້າ '#' ໄປສູ່ການສ້າງລະດັບສູງສຸດທີ່ເໝາະສົມ.
name (ບໍ່ມີ '#') ແລະຈະປ່ຽນຊື່ພີ່ນ້ອງເປັນຊື່ລະດັບເທິງ.

ໄດ້ "DirPath" ວິທີການ

ວິທີການ 'DirPath' ກັບຄືນເສັ້ນທາງການກໍ່ສ້າງ ຊື່(s) ຂອງໄດເລກະທໍລີຫຼືບັນຊີລາຍຊື່ຂອງໄດເລກະທໍລີ.
ມັນ​ຖືກ​ຮຽກ​ຮ້ອງ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

$cwd = DirPath ;

ການນໍາໃຊ້ທົ່ວໄປທີ່ສຸດສໍາລັບວິທີການ 'DirPath' ແມ່ນ:

$cwd = DirPath '.';

ເພື່ອເອົາເສັ້ນທາງໄປຫາໄດເລກະທໍລີປະຈຸບັນຂອງບໍລິສັດຍ່ອຍ ທະບຽນ ຍື່ນ.

ໄດ້ `ເສັ້ນທາງໄຟລ໌' ວິທີການ

ວິທີການ 'FilePath' ຕອບເສັ້ນທາງການກໍ່ສ້າງ ຊື່(s) ຂອງໄຟລ໌ຫຼືບັນຊີລາຍຊື່ຂອງໄຟລ໌. ມັນ​ແມ່ນ
ຮຽກ​ຮ້ອງ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

$file = FilePath ;

ໄດ້ `ຊ່ວຍ' ວິທີການ

ວິທີການ 'ການຊ່ວຍເຫຼືອ' ລະບຸຂໍ້ຄວາມຊ່ວຍເຫຼືອທີ່ຈະສະແດງເມື່ອຜູ້ໃຊ້ຮຽກຮ້ອງ `cons
-ຊ'. ນີ້ສາມາດຖືກນໍາໃຊ້ເພື່ອສະຫນອງເອກະສານຂອງເປົ້າຫມາຍສະເພາະ, ມູນຄ່າ, ການກໍ່ສ້າງ
ທາງເລືອກ, ແລະອື່ນໆສໍາລັບການກໍ່ສ້າງຕົ້ນໄມ້. ມັນ​ຖືກ​ຮຽກ​ຮ້ອງ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

ຊ່ວຍເຫຼືອ ;

ວິທີການ 'ການຊ່ວຍເຫຼືອ' ອາດຈະຖືກເອີ້ນພຽງແຕ່ຄັ້ງດຽວ, ແລະໂດຍປົກກະຕິຄວນຈະຖືກລະບຸໄວ້ໃນດ້ານເທິງ.
ລະດັບ ກໍ່ສ້າງ ຍື່ນ.

ການຂະຫຍາຍ cons

ຂ້າມ ການກໍ່ສ້າງ ຕົວແປ

ມີຫຼາຍວິທີຂອງການຂະຫຍາຍ Cons, ເຊິ່ງແຕກຕ່າງກັນໃນລະດັບຄວາມຫຍຸ້ງຍາກ. ງ່າຍ​ທີ່​ສຸດ​
ວິທີການແມ່ນກໍານົດສະພາບແວດລ້ອມການກໍ່ສ້າງຂອງທ່ານເອງ, ໂດຍອີງໃສ່ສະພາບແວດລ້ອມເລີ່ມຕົ້ນ,
ແຕ່ດັດແກ້ເພື່ອສະທ້ອນຄວາມຕ້ອງການສະເພາະຂອງເຈົ້າ. ນີ້ມັກຈະພຽງພໍສໍາລັບ C-based
ຄໍາຮ້ອງສະຫມັກ. ທ່ານສາມາດນໍາໃຊ້ 'ໃຫມ່' constructor, ແລະ 'clone' ແລະ 'copy' ວິທີການ
ສ້າງສະພາບແວດລ້ອມປະສົມ. ການປ່ຽນແປງເຫຼົ່ານີ້ສາມາດມີຄວາມໂປ່ງໃສທັງໝົດຕໍ່ກັບພື້ນຖານ
ທະບຽນ ໄຟລ໌.

ເພີ່ມຕື່ມ ໃຫມ່ ວິທີການ

ສໍາລັບການປ່ຽນແປງທີ່ຕ້ອງການເລັກນ້ອຍ, ທ່ານອາດຈະຕ້ອງການເພີ່ມວິທີການໃຫມ່ໃຫ້ກັບ 'ຂໍ້ເສຍ'.
ຊຸດ. ນີ້ແມ່ນຕົວຢ່າງຂອງສ່ວນຂະຫຍາຍທີ່ງ່າຍດາຍຫຼາຍ, 'InstallScript', ເຊິ່ງຕິດຕັ້ງ a
tcl script ໃນສະຖານທີ່ທີ່ຮ້ອງຂໍ, ແຕ່ແກ້ໄຂສະຄິບທໍາອິດເພື່ອສະທ້ອນໃຫ້ເຫັນເວທີ-
ເສັ້ນທາງທີ່ຂຶ້ນກັບທີ່ຕ້ອງການຕິດຕັ້ງໃນສະຄຣິບ:

# cons::InstallScript - ສ້າງເວີຊັນທີ່ຂຶ້ນກັບເວທີຂອງ shell
# ສະຄຣິບໂດຍການປ່ຽນສະຕຣິງ ``#!your-path-here'' ດ້ວຍເວທີສະເພາະ
# ເສັ້ນທາງ $BIN_DIR.

sub cons::InstallScript {
ຂອງຂ້ອຍ ($env, $dst, $src) = @_;
ຄໍາສັ່ງ $env $dst, $src, qq(
sed s+your-path-here+$BIN_DIR+ %< > %>
chmod oug+x %>
);
}

ສັງເກດເຫັນວ່າວິທີການນີ້ຖືກກໍານົດໂດຍກົງໃນຊຸດ 'cons' (ໂດຍການນໍາຫນ້າຊື່
ກັບ `cons::'). ການ​ປ່ຽນ​ແປງ​ໃນ​ລັກ​ສະ​ນະ​ນີ້​ຈະ​ເຫັນ​ໄດ້​ໃນ​ທົ່ວ​ໂລກ​ກັບ​ສະ​ພາບ​ແວດ​ລ້ອມ​ທັງ​ຫມົດ​,
ແລະສາມາດເອີ້ນໄດ້ໃນຕົວຢ່າງຕໍ່ໄປນີ້:

InstallScript $env "$BIN/foo", "foo.tcl";

ສໍາລັບການປັບປຸງເລັກນ້ອຍໂດຍທົ່ວໄປ, ຕົວແປ 'BINDIR' ສາມາດຖືກສົ່ງຜ່ານເປັນ
ການໂຕ້ຖຽງ ຫຼືເອົາມາຈາກສະພາບແວດລ້ອມການກໍ່ສ້າງ -- ເປັນ `%BINDIR'.

ຂ້າມ ວິທີການ

ແທນທີ່ຈະເພີ່ມວິທີການໃສ່ຊ່ອງຊື່ 'ຂໍ້ເສຍ', ທ່ານສາມາດກໍານົດຊຸດໃຫມ່
ເຊິ່ງສືບທອດວິທີການທີ່ມີຢູ່ແລ້ວຈາກຊຸດ 'cons' ແລະ overrides ຫຼືເພີ່ມອື່ນໆ. ນີ້
ສາມາດເຮັດໄດ້ໂດຍໃຊ້ກົນໄກການສືບທອດຂອງ Perl.

ຕົວຢ່າງຕໍ່ໄປນີ້ກໍານົດຊຸດໃຫມ່ 'cons::switch' ເຊິ່ງ overrides ມາດຕະຖານ
ວິທີການ 'ຫ້ອງສະຫມຸດ'. ວິທີການ overridden ກໍ່ສ້າງໂມດູນຫ້ອງສະຫມຸດເຊື່ອມຕໍ່, ແທນທີ່ຈະເປັນຫ້ອງສະຫມຸດ
ຮວບຮວມ. ມີຜູ້ກໍ່ສ້າງໃໝ່ໃຫ້. ສິ່ງ​ແວດ​ລ້ອມ​ທີ່​ສ້າງ​ຂຶ້ນ​ກັບ constructor ນີ້​ຈະ​
ມີວິທີການຫ້ອງສະຫມຸດໃຫມ່; ຄົນອື່ນຈະບໍ່.

package cons::ສະຫຼັບ;
BEGIN {@ISA = 'cons'}

ຍ່ອຍໃຫມ່ {
ປ່ຽນ;
ເປັນພອນໃຫ້ແກ່ cons ໃຫມ່(@_);
}

ຫ້ອງສະໝຸດຍ່ອຍ {
my($env) = shift;
my($lib) = shift;
my(@objs) = ວັດຖຸ $env @_;
ຄໍາສັ່ງ $env $lib, @objs, q(
%LD -r %LDFLAGS %< -o %>
);
}

ຫນ້າທີ່ນີ້ສາມາດຖືກເອີ້ນໃນຕົວຢ່າງຕໍ່ໄປນີ້:

$env = new cons::switch(@overrides);
...
ຫໍສະໝຸດ $env 'lib.o', 'foo.c', 'bar.c';

ການຂໍ cons

ຄໍາສັ່ງ 'cons' ມັກຈະຖືກເອີ້ນຈາກຮາກຂອງຕົ້ນໄມ້ກໍ່ສ້າງ. ກ ກໍ່ສ້າງ ເອກະສານ
ຕ້ອງມີຢູ່ໃນໄດເລກະທໍລີນັ້ນ. ຖ້າອາກິວເມັນ `-f' ຖືກນໍາໃຊ້, ຫຼັງຈາກນັ້ນເປັນທາງເລືອກ ກໍ່ສ້າງ
ໄຟລ​໌​ອາດ​ຈະ​ໄດ້​ຮັບ​ການ​ນໍາ​ໃຊ້ (ແລະ​, ເປັນ​ໄປ​ໄດ້​, ເປັນ​ຮາກ​ສະ​ຫຼັບ​, ນັບ​ຕັ້ງ​ແຕ່ 'cons​' ຈະ cd ກັບ ກໍ່ສ້າງ
ໄຟລ໌ທີ່ປະກອບດ້ວຍໄດເລກະທໍລີ).

ຖ້າ 'ຂໍ້ເສຍ' ຖືກເອີ້ນຈາກລູກຂອງຮາກຂອງຕົ້ນໄມ້ກໍ່ສ້າງດ້ວຍການໂຕ້ຖຽງ '-t', ມັນ.
ຈະຍ່າງຂຶ້ນລໍາດັບຊັ້ນຂອງໄດເລກະທໍລີກໍາລັງຊອກຫາ a ກໍ່ສ້າງ ໄຟລ໌. (ຊື່ສຳຮອງອາດຈະ
ຍັງຖືກລະບຸດ້ວຍ `-f'.) ເປົ້າໝາຍທີ່ສະໜອງໃຫ້ຢູ່ໃນແຖວຄຳສັ່ງຈະຖືກດັດແກ້
ເປັນພີ່ນ້ອງກັບການຄົ້ນພົບ ກໍ່ສ້າງ ໄຟລ໌. ຕົວຢ່າງ, ຈາກໄດເລກະທໍລີທີ່ມີ
ລະດັບສູງສຸດ ກໍ່ສ້າງ ໄຟລ໌, ການຮຽກຮ້ອງຕໍ່ໄປນີ້:

% cd libfoo/subdir
% cons -t ເປົ້າຫມາຍ

ເທົ່າກັບ:

% cons libfoo/subdir/target

ຖ້າມີເປົ້າໝາຍ 'ມາດຕະຖານ' ທີ່ລະບຸໄວ້ໃນລຳດັບຂອງໄດເລກະທໍລີ ກໍ່ສ້າງ or
ທະບຽນ ໄຟລ໌, ພຽງແຕ່ເປົ້າຫມາຍເລີ່ມຕົ້ນຢູ່ຫຼືຂ້າງລຸ່ມນີ້ໄດເລກະທໍລີທີ່ 'cons -t'
ໄດ້ invoked ຈະ ໄດ້ ຮັບ ການ ກໍ່ ສ້າງ.

ຄໍາ​ສັ່ງ​ແມ່ນ​ເອີ້ນ​ວ່າ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

ຂໍ້ເສຍ --

ບ່ອນທີ່ ກະທູ້ທີ່ ສາມາດເປັນອັນໃດອັນໜຶ່ງຕໍ່ໄປນີ້, ໃນລຳດັບໃດນຶ່ງ:

ເປົ້າ​ຫມາຍ ສ້າງເປົ້າຫມາຍທີ່ກໍານົດໄວ້. ຖ້າ ເປົ້າ​ຫມາຍ ເປັນໄດເລກະທໍລີ, ຫຼັງຈາກນັ້ນສ້າງ recursively
ທຸກຢ່າງພາຍໃນໄດເລກະທໍລີນັ້ນ.

+ ຮູບແບບ ຈໍາກັດການ ທະບຽນ ໄຟລ​໌​ທີ່​ພິ​ຈາ​ລະ​ນາ​ພຽງ​ແຕ່​ທີ່​ກົງ​ກັນ​ ຮູບແບບ, ເຊິ່ງແມ່ນ
ການສະແດງອອກປົກກະຕິ Perl. ຍອມຮັບອາກິວເມັນ `+' ຫຼາຍອັນ.

ຊື່=
ຊຸດ ຊື່ ມູນຄ່າ h ໃນ hash `ARG' ຜ່ານໄປໃນລະດັບສູງສຸດ ກໍ່ສ້າງ ຍື່ນ.

`-cc' ສະແດງຄໍາສັ່ງທີ່ຈະຖືກປະຕິບັດ, ເມື່ອດຶງຂໍ້ມູນຈາກ cache. ບໍ່
ການຊີ້ບອກວ່າໄຟລ໌ໄດ້ຖືກດຶງອອກມາແລ້ວ; ນີ້ແມ່ນເປັນປະໂຫຍດສໍາລັບ
ການສ້າງບັນທຶກການສ້າງທີ່ສາມາດປຽບທຽບກັບບັນທຶກການກໍ່ສ້າງທີ່ແທ້ຈິງ.

`-cd' ປິດການເກັບຂໍ້ມູນທັງໝົດ. ຢ່າດຶງຂໍ້ມູນຈາກ cache ຫຼື flush ໄປ cache.

`-cr' ສ້າງຄວາມເພິ່ງພາອາໄສໃນລໍາດັບແບບສຸ່ມ. ນີ້ແມ່ນເປັນປະໂຫຍດໃນເວລາທີ່ການກໍ່ສ້າງຫຼາຍ
ຕົ້ນໄມ້ທີ່ຄ້າຍຄືກັນທີ່ມີການເປີດໃຊ້ cache.

`-cs' synchronize ເປົ້າຫມາຍການກໍ່ສ້າງທີ່ມີຢູ່ແລ້ວທີ່ພົບວ່າມີຄວາມທັນສະໄຫມກັບ cache.
ອັນນີ້ເປັນປະໂຫຍດຖ້າການປິດການນຳໃຊ້ການເກັບຂໍ້ມູນຈາກ -cc ຫຼືຫາກໍເປີດໃຊ້ເມື່ອບໍ່ດົນມານີ້
ດ້ວຍ UseCache.

`-d' ເປີດໃຊ້ການດີບັກການເພິ່ງພາອາໄສ.

`-f'
ໃຊ້ໄຟລ໌ທີ່ລະບຸໄວ້ແທນ ກໍ່ສ້າງ (ແຕ່ທໍາອິດປ່ຽນເປັນບັນຈຸ
ໄດເລກະທໍລີຂອງ ເອກະສານ).

`-h' ສະແດງຂໍ້ຄວາມຊ່ວຍເຫຼືອໃນທ້ອງຖິ່ນຕໍ່ກັບການສ້າງປະຈຸບັນຖ້າອັນໃດນຶ່ງຖືກກຳນົດ, ແລະອອກ.

`-k' ສືບຕໍ່ໄປເທົ່າທີ່ເປັນໄປໄດ້ຫຼັງຈາກຄວາມຜິດພາດ.

`-o'
ອ່ານໄຟລ໌ override ເອກະສານ.

`-p' ສະແດງຜະລິດຕະພັນກໍ່ສ້າງໃນຕົ້ນໄມ້ທີ່ລະບຸ. ບໍ່ມີການພະຍາຍາມກໍ່ສ້າງ.

`-pa' ສະແດງຜະລິດຕະພັນກໍ່ສ້າງແລະການປະຕິບັດທີ່ກ່ຽວຂ້ອງ. ບໍ່ມີການພະຍາຍາມກໍ່ສ້າງ.

`-pw' ສະແດງຜະລິດຕະພັນແລະບ່ອນທີ່ພວກມັນຖືກກໍານົດ. ບໍ່ມີການພະຍາຍາມກໍ່ສ້າງ.

`-q' ຢ່າເວົ້າຫຼາຍກ່ຽວກັບການຕິດຕັ້ງ ແລະລຶບເປົ້າໝາຍ.

`-r' ເອົາຜະລິດຕະພັນກໍ່ສ້າງທີ່ກ່ຽວຂ້ອງກັບ . ບໍ່ມີການພະຍາຍາມກໍ່ສ້າງ.

`-R'
ຊອກຫາໄຟລ໌ໃນ ສ່ວນທີ່ເຫຼືອ. ຫຼາຍ -R ສ່ວນທີ່ເຫຼືອ ໄດເລກະທໍລີຖືກຄົ້ນຫາຢູ່ໃນ
ຄໍາ​ສັ່ງ​ທີ່​ລະ​ບຸ​ໄວ້​.

`-t' ຂ້າມໄປຕາມລໍາດັບຊັ້ນຂອງໄດເລກະທໍລີຊອກຫາ a ກໍ່ສ້າງ ໄຟລ໌, ຖ້າບໍ່ມີ
ໃນ​ລະ​ບົບ​ປະ​ຈຸ​ບັນ​. ເປົ້າໝາຍຈະຖືກດັດແກ້ໃຫ້ສົມທຽບກັບ
ກໍ່ສ້າງ ຍື່ນ.

`-v' ສະແດງສະບັບ `cons' ແລະສືບຕໍ່ການປະມວນຜົນ.

`-V' ສະແດງ `cons' ຮຸ່ນແລະອອກ.

`-wf'
ຂຽນຊື່ໄຟລ໌ທັງຫມົດພິຈາລະນາເຂົ້າໄປໃນ ເອກະສານ.

`-x' ສະແດງຂໍ້ຄວາມຊ່ວຍເຫຼືອທີ່ຄ້າຍຄືກັນກັບອັນນີ້, ແລະອອກ.

ແລະ construct-args ສາມາດເປັນຂໍ້ໂຕ້ແຍ້ງທີ່ທ່ານຕ້ອງການທີ່ຈະດໍາເນີນການໃນ ກໍ່ສ້າງ ຍື່ນ.
ໃຫ້ສັງເກດວ່າຄວນຈະມີ a -- ແຍກການໂຕ້ຖຽງກັບ cons ແລະການໂຕ້ຖຽງທີ່ທ່ານ
ຕ້ອງການປຸງແຕ່ງຢູ່ໃນ ກໍ່ສ້າງ ຍື່ນ.

ການປຸງແຕ່ງຂອງ construct-args ສາມາດເຮັດໄດ້ໂດຍຊຸດມາດຕະຖານເຊັ່ນ Getopt ຫຼືຂອງມັນ
variants, ຫຼືຊຸດທີ່ຜູ້ໃຊ້ກໍານົດ. cons ຈະຜ່ານໃນ construct-args as @ARGV ແລະ
ຈະບໍ່ພະຍາຍາມຕີຄວາມຫມາຍຫຍັງຫຼັງຈາກ --.

% cons -R /usr/local/repository -d os=solaris +driver -- -c test -f DEBUG

ຈະຜ່ານດັ່ງຕໍ່ໄປນີ້ກັບ cons

-R /usr/local/repository -d os=solaris +driver

ແລະຕໍ່ໄປນີ້, ໃນລະດັບສູງສຸດ ກໍ່ສ້າງ ໄຟລ໌ເປັນ @ARGV

-c ການທົດສອບ -f DEBUG

ໃຫ້ສັງເກດວ່າ `cons -r .' ແມ່ນເທົ່າກັບການ recursive ເຕັມທີ່ 'ເຮັດໃຫ້ສະອາດ', ແຕ່ຮຽກຮ້ອງໃຫ້ມີບໍ່ມີ
ສະຫນັບສະຫນູນໃນ ກໍ່ສ້າງ ໄຟລ​໌​ຫຼື​ໃດໆ​ ທະບຽນ ໄຟລ໌. ນີ້ແມ່ນເປັນປະໂຫຍດທີ່ສຸດຖ້າທ່ານເປັນ
ການລວບລວມໄຟລ໌ເຂົ້າໄປໃນໄດເລກະທໍລີແຫຼ່ງ (ຖ້າທ່ານແຍກ ການກໍ່ສ້າງ ແລະ ການສົ່ງອອກ ລາຍການ,
ຫຼັງຈາກນັ້ນທ່ານພຽງແຕ່ສາມາດເອົາໄດເລກະທໍລີ).

ຕົວເລືອກ `-p', `-pa', ແລະ `-pw' ແມ່ນເປັນປະໂຫຍດທີ່ສຸດເພື່ອໃຊ້ເປັນຕົວຊ່ວຍໃນການອ່ານ.
scripts ຫຼື debugging ເຂົາເຈົ້າ. ຖ້າທ່ານຕ້ອງການຮູ້ວ່າ script ຕິດຕັ້ງແນວໃດ ສົ່ງອອກ/include/foo.h,
ຕົວຢ່າງ, ພຽງແຕ່ພິມ:

% cons -pw export/include/foo.h

ການນໍາໃຊ້ ແລະ ລາຍລັກອັກສອນ ການເພິ່ງພາອາໄສ ເຄື່ອງສະແກນເນີ

QuickScan ອະ​ນຸ​ຍາດ​ໃຫ້​ເຄື່ອງ​ສະ​ແກນ​ເປົ້າ​ຫມາຍ​ທີ່​ເປັນ​ເອ​ກະ​ລາດ​ງ່າຍ​ດາຍ​ທີ່​ຈະ​ໄດ້​ຮັບ​ການ​ຕັ້ງ​ຄ່າ​ສໍາ​ລັບ​ໄຟລ​໌​ທີ່​ມາ​. ເທົ່ານັ້ນ
ເຄື່ອງສະແກນ QuickScan ອັນໜຶ່ງອາດຈະກ່ຽວຂ້ອງກັບໄຟລ໌ແຫຼ່ງໃດກໍໄດ້ ແລະສະພາບແວດລ້ອມທີ່ໃຫ້ມາ.

QuickScan ຖືກເອີ້ນດັ່ງນີ້:

QuickScan CONSENV CODEREF, FILENAME [, PATH]

ກຳນົດການຍ່ອຍທີ່ອ້າງອີງໂດຍ CODEREF ຄາດວ່າຈະສົ່ງຄືນລາຍຊື່ຂອງຊື່ໄຟລ໌ທີ່ຮວມຢູ່ນຳ
ໂດຍກົງໂດຍ FILE. ຊື່ໄຟລ໌ເຫຼົ່ານີ້ຈະຖືກສະແກນ. ການໂຕ້ຖຽງ PATH ທາງເລືອກ
ສະໜອງເສັ້ນທາງການຊອກຫາເພື່ອຊອກຫາ FILENAME ແລະ/ຫຼືໄຟລ໌ທີ່ສົ່ງຄືນໂດຍຜູ້ໃຊ້ສະໜອງໃຫ້
ປະຈຳຍ່ອຍ. PATH ອາດຈະເປັນການອ້າງອີງເຖິງ array ຂອງຊື່ directory ຊອກຫາ, ຫຼື a
ສະຕຣິງຂອງຊື່ທີ່ແຍກດ້ວຍຕົວແຍກຂອງລະບົບ (':' ໃນລະບົບ UNIX, ';' ສຸດ
Windows NT).

ກຳນົດການຍ່ອຍຖືກເອີ້ນເທື່ອດຽວສຳລັບແຕ່ລະແຖວໃນໄຟລ໌, ດ້ວຍ $_ ຕັ້ງເປັນແຖວປັດຈຸບັນ.
ຖ້າ subroutine ຕ້ອງການເບິ່ງເສັ້ນເພີ່ມເຕີມ, ຫຼື, ສໍາລັບເລື່ອງນັ້ນ, ໄຟລ໌ທັງຫມົດ,
ຫຼັງຈາກນັ້ນ, ມັນອາດຈະອ່ານພວກມັນເອງ, ຈາກ filehandle SCAN. ມັນຍັງອາດຈະຢຸດເຊົາການ loop, ຖ້າ
ມັນຮູ້ວ່າບໍ່ມີການລວມເອົາຂໍ້ມູນຕື່ມອີກ, ໂດຍການປິດຕົວຈັດການໄຟລ໌.

ບໍ່ວ່າຈະມີເສັ້ນທາງຊອກຫາຫຼືບໍ່, QuickScan ທໍາອິດພະຍາຍາມຊອກຫາໄຟລ໌
ກ່ຽວຂ້ອງກັບໄດເລກະທໍລີປະຈຸບັນ (ສໍາລັບໄຟລ໌ລະດັບສູງສຸດທີ່ສະຫນອງໂດຍກົງກັບ QuickScan),
ຫຼືຈາກໄດເລກະທໍລີທີ່ມີໄຟລ໌ທີ່ອ້າງອີງໄຟລ໌. ນີ້ບໍ່ແມ່ນຫຼາຍ
ໂດຍທົ່ວໄປ, ແຕ່ເບິ່ງຄືວ່າດີພຽງພໍ - ໂດຍສະເພາະຖ້າທ່ານມີຄວາມຫລູຫລາຂອງການຂຽນຂອງທ່ານເອງ
utilities ແລະສາມາດຄວບຄຸມການນໍາໃຊ້ເສັ້ນທາງຄົ້ນຫາໃນວິທີການມາດຕະຖານ. ສຸດທ້າຍ, ໄດ້
ເສັ້ນທາງຄົ້ນຫາແມ່ນ, ໃນປັດຈຸບັນ, ຈໍ້າສອງເມັດແຍກອອກ. ນີ້ອາດຈະບໍ່ເຮັດໃຫ້ camp NT ມີຄວາມສຸກ.

ນີ້ແມ່ນຕົວຢ່າງທີ່ແທ້ຈິງ, ເອົາມາຈາກ a ກໍ່ສ້າງ ໄຟລ໌ທີ່ນີ້:

ຂໍ້ເສຍຍ່ອຍ::SMFgen {
my($env, @tables) = @_;
foreach $t (@tables) {
$env->QuickScan(ຍ່ອຍ { /\b\S*?\.smf\b/g }, "$t.smf",
$env->{SMF_INCLUDE_PATH});
$env->ຄໍາສັ່ງ(
["$t.smdb.cc","$t.smdb.h","$t.snmp.cc","$t.ami.cc", "$t.http.cc"],
"$t.smf",
q(
smfgen %( %SMF_INCLUDE_OPT %) %
)
);
}
}

[ໃຫ້ສັງເກດວ່າແບບຟອມ `$env->QuickScan ...' ແລະ `$env->Command ...' ບໍ່ຄວນເປັນ.
ມີຄວາມຈໍາເປັນ, ແຕ່, ສໍາລັບເຫດຜົນບາງຢ່າງ, ແມ່ນຈໍາເປັນສໍາລັບການຮຽກຮ້ອງໂດຍສະເພາະນີ້. ອັນນີ້ປາກົດ
to be a bug in Perl ຫຼື​ຄວາມ​ເຂົ້າ​ໃຈ​ຜິດ​ໃນ​ພາກ​ສ່ວນ​ຂອງ​ຂ້າ​ພະ​ເຈົ້າ​; ຮູບແບບການເອີ້ນນີ້ບໍ່ໄດ້
ເບິ່ງຄືວ່າມີຄວາມຈໍາເປັນສະ ເໝີ ໄປ.]

ນີ້ຊອກຫາຊື່ທັງຫມົດຂອງແບບຟອມ .smf ໃນໄຟລ໌. ມັນຈະສົ່ງຄືນຊື່ເຖິງແມ່ນວ່າ
ເຂົາເຈົ້າໄດ້ຖືກພົບເຫັນຢູ່ໃນຄໍາເຫັນ, ແຕ່ວ່າມັນແມ່ນ OK (ກົນໄກແມ່ນການໃຫ້ອະໄພຂອງໄຟລ໌ເພີ່ມເຕີມ;
ພວກ​ເຂົາ​ເຈົ້າ​ພຽງ​ແຕ່​ລະ​ເລີຍ​ກັບ​ສົມ​ມຸດ​ຕິ​ຖານ​ວ່າ​ໄຟລ​໌​ທີ່​ຂາດ​ຫາຍ​ໄປ​ຈະ​ໄດ້​ຮັບ​ການ​ສັງ​ເກດ​ເຫັນ​ໃນ​ເວ​ລາ​ທີ່​
ໂຄງການ, ໃນຕົວຢ່າງນີ້, smfgen, ຖືກເອີ້ນຕົວຈິງ).

A scanner ແມ່ນ invoked ພຽງ ແຕ່ ສໍາ ລັບ ໄຟລ ໌ ແຫຼ່ງ ທີ່ ໄດ້ ຮັບ ຖ້າ ຫາກ ວ່າ ມັນ ເປັນ ຕ້ອງ ການ ໂດຍ ບາງ ເປົ້າ ຫມາຍ ໃນ
ຕົ້ນໄມ້. ມັນໄດ້ຖືກເອີ້ນພຽງແຕ່ຄັ້ງດຽວສໍາລັບໄຟລ໌ແຫຼ່ງທີ່ໃຫ້.

ນີ້ແມ່ນວິທີອື່ນໃນການສ້າງເຄື່ອງສະແກນດຽວກັນ. ອັນນີ້ໃຊ້ການອ້າງອີງລະຫັດທີ່ຊັດເຈນ,
ແລະຍັງ (ບໍ່ຈໍາເປັນ, ໃນກໍລະນີນີ້) ອ່ານໄຟລ໌ທັງຫມົດຂອງມັນເອງ:

sub myscan {
ຂອງຂ້ອຍ(@ລວມທັງ);
ເຮັດ {
push(@includes, /\b\S*?\.smf\b/g);
} ໃນຂະນະທີ່ ;
@ລວມທັງ
}

ໃຫ້ສັງເກດວ່າຄໍາສັ່ງຂອງ loop ແມ່ນປີ້ນກັບກັນ, ມີການທົດສອບ loop ໃນຕອນທ້າຍຂອງ. ນີ້​ແມ່ນ
ເພາະວ່າແຖວທໍາອິດແມ່ນໄດ້ອ່ານແລ້ວສໍາລັບທ່ານ. ເຄື່ອງສະແກນນີ້ສາມາດຕິດກັບແຫຼ່ງໃດຫນຶ່ງ
ໄຟລ໌ໂດຍ:

QuickScan $env \myscan, "$_.smf";

ສະຫນັບສະຫນູນ ແລະ ຂໍ້ສະ ເໜີ ແນະ

Cons ແມ່ນຮັກສາໄວ້ໂດຍຊຸມຊົນຜູ້ໃຊ້. ເພື່ອສະໝັກ, ສົ່ງອີເມວຫາ cons-ສົນທະນາ-
[email protected] ກັບຮ່າງກາຍ ຈອງ.

ກະລຸນາລາຍງານຄໍາແນະນໍາໃດໆໂດຍຜ່ານ [email protected] ບັນຊີລາຍຊື່ທາງໄປສະນີ.

ໃຊ້ cons ອອນໄລນ໌ໂດຍໃຊ້ບໍລິການ onworks.net