makepp_repositories - ອອນລາຍໃນຄລາວ

ໂຄງການ:

NAME

makepp_repositories -- ວິທີການໃຊ້ repositories ສໍາລັບ variant builds, ສໍາລັບການຮັກສາ a
ແຫຼ່ງສູນກາງ, ແລະສິ່ງອື່ນໆ

ລາຍລະອຽດ

A repository ແມ່ນໄດເຣັກທໍຣີ ຫຼືລຳດັບຊັ້ນຂອງໄດເຣັກທໍຣີທີ່ຢູ່ນອກໄດເຣັກທໍຣີເລີ່ມຕົ້ນທີ່
ມີໄຟລ໌ທີ່ makefile ຕ້ອງການຢູ່ໃນໄດເລກະທໍລີຕົ້ນໄມ້ປະຈຸບັນ. Makepp ສາມາດ
ເຊື່ອມຕໍ່ໄຟລ໌ອັດຕະໂນມັດຈາກບ່ອນເກັບມ້ຽນເຂົ້າໄປໃນຕົ້ນໄມ້ໄດເລກະທໍລີປະຈຸບັນຖ້າພວກມັນຢູ່
ຕ້ອງການ. Repositories ໃຫ້ການເຮັດວຽກທີ່ຄ້າຍຄືກັນກັບຕົວແປ "VPATH", ແຕ່ (ບໍ່ຄືກັບ
"VPATH" ໃນສະບັບອື່ນໆຂອງ make) ທ່ານບໍ່ຈໍາເປັນຕ້ອງເຮັດຫຍັງພິເສດກັບ makefile ຂອງທ່ານ
ເພື່ອໃຫ້ພວກເຂົາເຮັດວຽກ.

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

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

Repositories ແມ່ນເປັນປະໂຫຍດໃນສະຖານະການທີ່ແຕກຕ່າງກັນຫຼາຍ:

·ເມື່ອທ່ານຕ້ອງການຈັດວາງວັດຖຸແລະໄຟລ໌ທີ່ປະຕິບັດໄດ້ຂອງທ່ານໃນໄດເລກະທໍລີແຍກຕ່າງຫາກ, ແຕ່
makefile ຖືກຂຽນເພື່ອຈັດວາງພວກມັນຢູ່ໃນໄດເລກະທໍລີດຽວກັນກັບແຫຼ່ງ.

· ເມື່ອທ່ານຕ້ອງການສ້າງໂຄງການດຽວກັນສອງວິທີທີ່ແຕກຕ່າງກັນ (ຕົວຢ່າງ: ມີສອງອັນແຕກຕ່າງກັນ
ຊຸດຂອງທາງເລືອກການລວບລວມ, ຫຼືສໍາລັບສອງສະຖາປັດຕະທີ່ແຕກຕ່າງກັນ).

· ເມື່ອທ່ານບໍ່ມີການເຂົ້າເຖິງການຂຽນທັງໝົດ ຫຼືບາງສ່ວນຂອງຕົ້ນໄມ້ແຫຼ່ງ.

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

ການປະຕິບັດຂອງ Makepp ຂອງ repositories ບໍ່ຈໍາເປັນຕ້ອງຂຽນຄືນໃຫມ່ຂອງຄໍາສັ່ງສ້າງ
ທັງຫມົດ, ບໍ່ເຫມືອນກັບ (ຕົວຢ່າງ) repositories ໃນ cons. Makepp ເອົາການເຊື່ອມຕໍ່ສັນຍາລັກເຂົ້າໄປໃນ
ໄດເລກະທໍລີທີ່ຄໍາສັ່ງຄາດວ່າຈະມີມັນ. ຕາບໃດທີ່ຄໍາສັ່ງບໍ່ໄດ້ອ້າງເຖິງ
ໄດເລກະທໍລີຢ່າງແທ້ຈິງ, ຄໍາສັ່ງ shell ດຽວກັນຄືກັນອ້ອຍຕ້ອຍຈະເຮັດວຽກກັບໄຟລ໌ຈາກ repository.
ນີ້ຫມາຍຄວາມວ່າມັນເຮັດວຽກບໍ່ພຽງແຕ່ສໍາລັບຄໍາສັ່ງການລວບລວມ, ແຕ່ປະເພດຂອງຄໍາສັ່ງໃດໆທີ່ທ່ານ
ສາມາດຄິດທີ່ຈະໃສ່ໃນ makefile ຂອງທ່ານ.

Makepp ມີກົນໄກອື່ນທີ່ເອີ້ນວ່າ a ການກໍ່ສ້າງ ຖານຄວາມຈໍາ ເຊິ່ງແກ້ໄຂບາງອັນດຽວກັນ
ປະເພດຂອງບັນຫາເປັນ repositories ໃນວິທີການທີ່ແຕກຕ່າງກັນ. ອີງຕາມບັນຫາຂອງທ່ານ, ການກໍ່ສ້າງ
cache ອາດຈະເປັນປະໂຫຍດຫຼາຍກ່ວາ repository. ເບິ່ງ makepp_build_cache ສໍາລັບຂໍ້ມູນກ່ຽວກັບ
ສ້າງຖານຄວາມຈໍາແລະການປຽບທຽບການສ້າງຖານຄວາມຈໍາແລະບ່ອນເກັບມ້ຽນ.

ຕົວຢ່າງ
Repositories ໄດ້ຖືກອະທິບາຍທີ່ດີທີ່ສຸດໂດຍຕົວຢ່າງຈໍານວນຫນຶ່ງຂອງສິ່ງທີ່ທ່ານສາມາດເຮັດໄດ້.

ທີ່ແຕກຕ່າງກັນ ການລວບລວມ ທາງເລືອກໃນການ

ສົມມຸດວ່າທ່ານມີໂຄງການງ່າຍດາຍທີ່ມີ makefile ທີ່ມີລັກສະນະເຊັ່ນນີ້:

CFLAGS = -O2
OBJECTS = ao bo co
my_program: $(OBJECTS)
cc $(inputs) -o $(output)

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

makefile ນີ້ຈັດວາງໄຟລ໌ "ao", "bo", "co", ແລະ "my_program" ໃນໄດເລກະທໍລີດຽວກັນ
ເປັນໄຟລ໌ແຫຼ່ງ.

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

ຢ່າງໃດກໍຕາມ, ກັບ repository, ທ່ານບໍ່ຈໍາເປັນຕ້ອງແຕະ makefile ຂອງທ່ານທັງຫມົດ. ພິຈາລະນາ
ລໍາດັບຕໍ່ໄປນີ້ຂອງຄໍາສັ່ງ:

% cd my_program_source
% makepp # ກໍ່ສ້າງໂດຍໃຊ້ makefile ຂ້າງເທິງ, ແລະ
# ໄຟລ໌ວັດຖຸເຂົ້າໄປໃນໄດເລກະທໍລີ
# my_program_source.
% cd..
% mkdir binary-debug # ສ້າງໄດເລກະທໍລີທີ່ສະອາດສໍາລັບການກໍ່ສ້າງ
%cd binary-debug # ໂປຣແກຣມດຽວກັນກັບຕົວເລືອກຕ່າງໆ.
% makepp -R ../my_program_source CFLAGS=-g
# ໃນປັດຈຸບັນ objects ເຂົ້າໄປໃນ binary-debug.

ຄໍາສັ່ງ makepp ທໍາອິດລວບລວມໄຟລ໌ຕົ້ນສະບັບດ້ວຍການເພີ່ມປະສິດທິພາບແລະວາງວັດຖຸ
ເຂົ້າໄປໃນໄດເລກະທໍລີ "my_program_source", ເພາະວ່ານັ້ນແມ່ນສິ່ງທີ່ makefile ຄວນຈະເປັນ
ເຮັດ. ໃນປັດຈຸບັນພວກເຮົາຕ້ອງການທີ່ຈະສ້າງໂຄງການໃຫມ່, ແຕ່ພວກເຮົາຕ້ອງການປ່ຽນມູນຄ່າຂອງ "CFLAGS" ເປັນ
ລວບລວມສໍາລັບ debug. ພວກເຮົາລະບຸຄ່າໃຫມ່ຂອງ "CFLAGS" ໃນເສັ້ນຄໍາສັ່ງ, ແລະພວກເຮົາຍັງ
ບອກ makepp ວ່າໄດເລກະທໍລີ "my_program_source" ແມ່ນບ່ອນເກັບມ້ຽນໂດຍໃຊ້ຕົວເລືອກ "-R".

ທຸກໆຄັ້ງ makepp ຮູ້ວ່າມັນຕ້ອງການໄຟລ໌ທີ່ມັນບໍ່ມີຢູ່ໃນປະຈຸບັນ
directory, ມັນເບິ່ງຢູ່ໃນ repository. ໃນກໍລະນີນີ້, ມັນທໍາອິດຊອກຫາ makefile,
ເຊິ່ງບໍ່ມີຢູ່ໃນໄດເລກະທໍລີຍ່ອຍ "binary-debug". ສະນັ້ນມັນສ້າງການເຊື່ອມຕໍ່ສັນຍາລັກກັບ
ມັນມາຈາກ makefile ໃນ "my_program_source", ແລະຫຼັງຈາກນັ້ນອ່ານໃນ makefile. ຫຼັງຈາກນັ້ນມັນ
ສັງເກດເຫັນວ່າມັນຕ້ອງການໄຟລ໌ "ac" ເພື່ອສ້າງ "ao", ແລະດັ່ງນັ້ນມັນເຊື່ອມໂຍງໃນ "ac"
ຈາກ repository ໄດ້. ຖ້າ "ac" ປະກອບມີໄຟລ໌ໃດໆທີ່ມີຢູ່ໃນ "my_program_source", ຫຼັງຈາກນັ້ນ
ສິ່ງເຫຼົ່ານີ້ຈະຖືກເຊື່ອມຕໍ່ໂດຍອັດຕະໂນມັດ. ຫມາຍເຫດ: ການເຊື່ອມຕໍ່ເຫຼົ່ານັ້ນເປັນປະໂຫຍດສໍາລັບສິ່ງຕ່າງໆ
ຄືກັບການດີບັກ, ແຕ່ຖ້າທ່ານບໍ່ມັກພວກມັນ, "makeppclean -R" ສາມາດເອົາພວກມັນອອກໄດ້.

ການດໍາເນີນການຄໍາສັ່ງ build ໃນ "binary-debug" ຈະບໍ່ແຕະໃດໆຂອງໄຟລ໌ໃນ
"my_program_source". ດັ່ງນັ້ນຈາກຊຸດດຽວກັນຂອງໄຟລ໌ແຫຼ່ງ, ໃນປັດຈຸບັນທ່ານມີສອງທີ່ແຕກຕ່າງກັນ
ສໍາ​ເນົາ​ຂອງ​ໂຄງ​ການ​, ຫນຶ່ງ​ໃນ​ການ​ສັງ​ລວມ​ທີ່​ມີ​ການ​ປັບ​ປຸງ​ແລະ​ການ​ສັງ​ລວມ​ເພື່ອ debug​. ແລະ
ນີ້ເກີດຂຶ້ນໂດຍບໍ່ມີການສໍາຜັດກັບ makefile ເລີຍ.

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

ການກໍ່ສ້າງ ໃໝ່ ຫນຶ່ງ ເອກະສານ ກັບ a ເລັກນ້ອຍ ດັດແກ້ to ໄດ້ ການລວບລວມ ຄໍາສັ່ງ

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

CFLAGS := -O2
A_CFLAGS := -O6 -funroll-loops

ຈຸດປະສົງ := ao bo co

my_program: $(OBJECTS)
cc $(inputs) -o $(output)

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

ao: ac
cc $(A_CFLAGS) -c $(input) -o $(output)

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

% cd my_program_source
% makepp # ກໍ່ສ້າງໂດຍໃຊ້ makefile ຂ້າງເທິງ, ແລະ
# ໄຟລ໌ວັດຖຸເຂົ້າໄປໃນໄດເລກະທໍລີ
# my_program_source.
% cd..
% mkdir no-unrolling # ສ້າງໄດເລກະທໍລີທີ່ສະອາດສໍາລັບການກໍ່ສ້າງ
%cd no-unrolling # ໂປຣແກຣມດຽວກັນກັບຕົວເລືອກຕ່າງໆ.
% makepp -R ../my_program_source A_CFLAGS=-O2
% cd..
%time no-unrolling/my_program # Benchmark ທັງສອງລຸ້ນຂອງໂຄງການ.
% ເວລາ my_program_source/my_program

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

ການກໍ່ສ້າງ ໃໝ່ ກັບ a ເລັກນ້ອຍ ດັດແກ້ to ໄດ້ ແຫຼ່ງ

ຕອນນີ້ສົມມຸດວ່າພວກເຮົາຕ້ອງການປ່ຽນເປັນ "ac" ແລະ benchmark ໂຄງການກ່ອນແລະຫຼັງ
ການປ່ຽນແປງ. Repositories ສາມາດຊ່ວຍອີກເທື່ອຫນຶ່ງ. ພິຈາລະນາລໍາດັບຂອງຄໍາສັ່ງນີ້:

% mkdir ດັດແກ້-a
% cp my_program_source/ac modified-a
%cd ດັດແກ້-a
% emacs ac # ເຮັດການດັດແກ້ບາງອັນສະເພາະກັບໂມດູນນີ້.
% makepp -R ../my_program_source

ໃນ​ທີ່​ນີ້​ພວກ​ເຮົາ​ໄດ້​ສ້າງ​ລະ​ບົບ​ໃຫມ່​ທີ່​ພຽງ​ແຕ່​ປະ​ກອບ​ດ້ວຍ​ໄຟລ​໌​ແຫຼ່ງ​ດຽວ​ທີ່​ພວກ​ເຮົາ​ຕ້ອງ​ການ​ທີ່​ຈະ​
ປັບປຸງແກ້ໄຂ. ຕອນນີ້ Makepp ໃຊ້ "ac" ຈາກໄດເລກະທໍລີຍ່ອຍ "ດັດແກ້ -a", ແຕ່ໃຊ້ສໍາເນົາຂອງ
"b" ແລະ "c" ຈາກໄດເລກະທໍລີ "my_program_source". ໂດຍບໍ່ມີການປ່ຽນແປງໃດໆຂອງຖານສອງ
ໄຟລ໌ໃນ "my_program_source", ພວກເຮົາໄດ້ສ້າງສໍາເນົາແຍກຕ່າງຫາກຂອງໂຄງການທີ່
ລວມເອົາການປ່ຽນແປງຂອງພວກເຮົາກັບ "ac". ຖ້າມີຜູ້ພັດທະນາອື່ນໃຊ້ແຫຼ່ງຂໍ້ມູນໃນ
"my_program_source", ພວກມັນຈະບໍ່ໄດ້ຮັບຜົນກະທົບຈາກການປ່ຽນແປງຂອງພວກເຮົາ.

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

ການນໍາໃຊ້ a ລະບົບ ລຳ ດັບຊັ້ນ

A repository ແມ່ນຕົວຈິງແລ້ວບໍ່ພຽງແຕ່ເປັນໄດເລກະທໍລີດຽວ, ມັນເປັນລໍາດັບຊັ້ນຂອງໄດເລກະທໍລີທັງຫມົດ.
ສົມມຸດວ່າທ່ານໃຊ້ /our/library ເປັນບ່ອນເກັບມ້ຽນ. ດຽວນີ້ /our/library ອາດ​ຈະ​ປະ​ກອບ​ດ້ວຍ​ຈໍາ​ນວນ​ຫຼາຍ​
ໄດເລກະທໍລີຍ່ອຍ, ຕົວຢ່າງ, /our/library/gui ແລະ /our/library/network. ພິຈາລະນາຄໍາສັ່ງນີ້:

% makepp -R /our/library

ຄໍາສັ່ງໃດໆໃນ makefile ທີ່ຫມາຍເຖິງໄຟລ໌ໃນໄດເລກະທໍລີ ./ເຄືອຂ່າຍ ຕົວຈິງແລ້ວຈະ
ໄດ້​ຮັບ​ໄຟລ​໌​ຈາກ​ /our/library/network, ແລະເຊັ່ນດຽວກັນສໍາລັບ ./gui. Makepp ອັດຕະໂນມັດ
ສ້າງໄດເລກະທໍລີໃດໆທີ່ມີຢູ່ໃນ repository ແຕ່ບໍ່ແມ່ນຢູ່ໃນໄດເລກະທໍລີປະຈຸບັນ.

ການເຊື່ອມໂຍງ to ໃດ ສະຖານທີ່ in ໄດ້ ເອກະສານ ລະບົບ

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

ຕົວຢ່າງ, ບາງຄັ້ງມັນໜ້າເບື່ອເລັກນ້ອຍທີ່ຈະພິມຕໍ່ໄປນີ້:

mkdir alternate-build
cd alternate-build
makepp -R..

ທ່ານສາມາດເຮັດໄດ້ທັງຫມົດດ້ວຍຄໍາສັ່ງດຽວ, ເຊັ່ນນີ້:

makepp -R alternate-build=. -F alternate-build

"-F" ຫຼື "-makeppfile" ປ່ຽນແປງກັບໄດເລກະທໍລີນັ້ນກ່ອນທີ່ຈະໂຫລດ makefile. ເຈົ້າ​ຕ້ອງ
ລະບຸ "-R" ກ່ອນ "-F". ໃຫ້ສັງເກດວ່າຕົວຢ່າງນີ້ເຮັດໃຫ້ຕົ້ນໄມ້ກໍ່ສ້າງໃຫມ່ພາຍໃນ
ຄັງເກັບມ້ຽນ. ມັນຈະບໍ່ເຮັດວຽກຖ້າທ່ານໃຊ້ a RootMakeppfile ເນື່ອງຈາກວ່າ makepp ປົກປ້ອງ
ຕໍ່ກັບຕົ້ນໄມ້ທີ່ຕັ້ງຮັງ. ມັນຍັງບໍ່ແມ່ນຄວາມຄິດທີ່ດີຖ້າທ່ານໃຊ້ **, ເນື່ອງຈາກວ່າຖ້າຫາກວ່າທ່ານເຄີຍສ້າງ
ໃນ repository ມັນຍັງຈະພົບເຫັນໄຟລ໌ທີ່ຖືກດັດແກ້ແລະສ້າງຢູ່ໃນຕົ້ນໄມ້ຍ່ອຍນີ້.

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

% makepp -R test-build/seescape=/src/seescape \
-R test-build/HLib=/src/HLib \
-R test-build/H5pp=/src/H5pp \
-R qwt=/src/external_libraries/qwt \
-F test-build/seescape

ຄໍາສັ່ງນີ້ໂຫລດຢູ່ໃນໄຟລ໌ຈາກສີ່ repositories ທີ່ແຕກຕ່າງກັນ, ແລະຫຼັງຈາກນັ້ນ cds ກັບ the
./test-build/seescape ໄດເລກະທໍລີແລະປະຕິບັດ makefile ຢູ່ທີ່ນັ້ນ. ໄຟລ໌ທີ່ບັນຈຸຢູ່ໃນ
ໄດເລກະທໍລີຕົ້ນໄມ້ເລີ່ມຕົ້ນດ້ວຍ /src/seescape ຖືກເຊື່ອມຕໍ່ເຂົ້າໄປໃນ ./test-build/seescape. ໃນ
ຄໍາສັບຕ່າງໆອື່ນໆ, makepp ຈະເຊື່ອມຕໍ່ໄຟລ໌ຊົ່ວຄາວ /src/seescape/gui/image_canvas.cxx to
./test-build/seescape/gui/image_canvas.cxx ໃນເວລາທີ່ມັນເປັນສິ່ງຈໍາເປັນ. ຄໍາສັ່ງນີ້ຈະເຮັດວຽກເຖິງແມ່ນວ່າ
ຖ້າໄດເລກະທໍລີ "test-build" ຍັງບໍ່ທັນມີ; makepp ຈະສ້າງມັນສໍາລັບທ່ານ. (ແຕ່​ວ່າ​ເຈົ້າ
ຕ້ອງລະບຸຕົວເລືອກ "-R" ກ່ອນຕົວເລືອກ "-F" ໃນແຖວຄໍາສັ່ງ.)

ຫຼາຍ ທຽບເທົ່າ repositories

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

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

$ makepp -R/path/to/group/repository -R/path/to/production/repository

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

-R/path/to/group/repository -R/path/to/production/repository

ຫຼື, ໂດຍສົມມຸດວ່າມັນມີເສັ້ນທາງຄົງທີ່, ທ່ານສາມາດຂຽນເຂົ້າໄປໃນ makefile ຂອງທ່ານ:

repository /path/to/production/repository

ແລະ, ເນື່ອງຈາກວ່າທາງເລືອກແມ່ນເຫັນໄດ້ກ່ອນທີ່ makefiles ຖືກອ່ານ, ຫຼັງຈາກນັ້ນທ່ານສາມາດໂທຫາພຽງແຕ່

$ makepp -R/path/to/group/repository

ບັນດາຫໍປະຊຸມ as ຄົງ ສ່ວນ of ຂອງ​ທ່ານ ການກໍ່ສ້າງ ລະບົບ

ຖ້າທ່ານຮູ້ວ່າທ່ານໃຊ້ບ່ອນເກັບມ້ຽນບາງບ່ອນຢູ່ສະ ເໝີ ທ່ານສາມາດນໍາໃຊ້ "repository" ຫຼື "vpath"
ຖະແຫຼງການໃນ makefile ຂອງທ່ານ.

Caveats ກັບ repositories
ເມື່ອ​ໃດ​ ໄດ້ ການ​ເຊື່ອມ​ຕໍ່ ໄດ້ຮັບ in ໄດ້ ວິທີການ

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

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

ມີກົນລະຍຸດສອງສາມຢ່າງເພື່ອເອົາຊະນະສິ່ງນີ້:

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

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

$ delink() { { rm $1 && cat >$1; } <$1; }
% alias delink '( rm \!:1 && cat >\!:1; ) <\!:1'

· ຖ້າ​ຫາກ​ວ່າ​ທ່ານ​ຮູ້​ສຶກ​ວ່າ​ທ່ານ​ບໍ່​ຕ້ອງ​ການ​ໃຫ້​ເຂົາ​ເຈົ້າ​, ທ່ານ​ສາ​ມາດ​ລຶບ​ມັນ​ທັງ​ຫມົດ​, ທຸກ​ຄັ້ງ​ທີ່​ທ່ານ​ຕ້ອງ​ການ​, ເຊັ່ນ​:​
ຫຼັງ​ຈາກ​ການ​ແລ່ນ makepp ທຸກ​ຄັ້ງ​, ອາດ​ຈະ​ເປັນ​ພື້ນ​ຖານ (ທັງ​ຮູບ​ແບບ​ສັ້ນ​ຫຼື​ຍາວ​)​:

makeppclean --recurse --only-repository-links
mppc -rR

ເຮັດບໍ່ໄດ້ ການກໍ່ສ້າງ in a repository ໃນລະຫວ່າງການ ການນໍາໃຊ້

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

ຖ້າທ່ານຕ້ອງການ repository ທີ່ມີການປ່ຽນແປງໃນຂະນະທີ່ທ່ານສ້າງ, ທ່ານອາດຈະຕ້ອງການພິຈາລະນາ makepp's
ສ້າງກົນໄກການ cache (ເບິ່ງ makepp_build_cache). ອີກທາງເລືອກ, ທ່ານສາມາດນໍາໃຊ້ "ຜູ້ຊາຍທີ່ທຸກຍາກ
repository": ທ່ານສາມາດວາງກົດລະບຽບທີ່ຊັດເຈນເຂົ້າໄປໃນ makefile ຂອງເຈົ້າເພື່ອສ້າງລິ້ງທີ່ອ່ອນໆ, ເຊັ່ນ
ນີ້:

%.c : $(directory_I_wish_was_a_repository)/%.c
&ln -fs $(input) $(output)

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

ການນໍາໃຊ້ ພຽງແຕ່ ພີ່ນ້ອງ ຊື່ໄຟລ໌

Repositories ເຮັດວຽກຢ່າງສົມບູນແບບໂປ່ງໃສ if ໄດ້ makefiles ການນໍາໃຊ້ ພຽງແຕ່ ພີ່ນ້ອງ ຊື່ໄຟລ໌.
ໃນຕົວຢ່າງຂ້າງເທິງ, ມັນບໍ່ເປັນຫຍັງຖ້າ makefile ໃນ /src/seescape ຫມາຍເຖິງ ../HLib, ແຕ່
ຄໍາສັ່ງຂ້າງເທິງຈະບໍ່ເຮັດວຽກຕາມທີ່ຄາດໄວ້ຖ້າມັນຫມາຍເຖິງ /src/HLib. ຖ້າທ່ານຕ້ອງການໃຊ້
ຊື່ໄຟລ໌ຢ່າງແທ້ຈິງ, ທ່ານສາມາດເອົາໃຫ້ເຂົາເຈົ້າເຂົ້າໄປໃນຕົວແປແລະຫຼັງຈາກນັ້ນ override ເຂົາເຈົ້າກ່ຽວກັບ
ເສັ້ນຄໍາສັ່ງ, ເຊັ່ນນີ້:

% makepp -R test-build/seescape=/src/seescape SEESCAPE=/home/holt/test-build/seescape \
-R test-build/HLib=/src/HLib HLIB=/home/holt/test-build/HLib \
-R test-build/H5pp=/src/H5pp H5pp=/home/holt/test-build/H5pp \
-R qwt=/src/external_libraries/qwt QWT=/home/holt/test-build/qwt \
-F test-build/seescape

ຂ້າງເທິງຈະເຮັດວຽກໄດ້ຕາບໃດທີ່ໄດເລກະທໍລີ "HLib" ຖືກເອີ້ນວ່າ "$(HLIB)" ໃນທັງຫມົດ.
makefiles. ໃຫ້ສັງເກດວ່າທ່ານຕ້ອງລະບຸເສັ້ນທາງຢ່າງແທ້ຈິງສໍາລັບໄດເລກະທໍລີ, ເພາະວ່າ
makepp cd's ກັບ "test-build/seescape" ກ່ອນທີ່ຈະອ່ານ makefile. ນີ້ນໍາໄປສູ່ການຍາວແລະ
ສັບສົນເຮັດໃຫ້ຄໍາສັ່ງ; ໃຊ້ເສັ້ນທາງພີ່ນ້ອງເມື່ອເປັນໄປໄດ້.

ເມັກປ ຕ້ອງ ຮູ້ ກ່ຽວກັບ ທັງຫມົດ dependencies

Repositories ຈະບໍ່ເຮັດວຽກຖ້າມີການອ້າງອິງທີ່ເຊື່ອງໄວ້ທີ່ makepp ບໍ່ຮູ້
ກ່ຽວກັບ. (ໃນ​ຄວາມ​ເປັນ​ຈິງ, ການ​ສ້າງ​ໂດຍ​ການ​ນໍາ​ໃຊ້ repositories, ແມ່ນ​ຫນຶ່ງ​ໃນ​ການ​ກວດ​ສອບ​ການ​ລືມ
ການເພິ່ງພາອາໄສ. ແຕ່, ພຽງແຕ່ສໍາລັບການກວດສອບນີ້, ຢ່າສົມທົບມັນກັບການກໍ່ສ້າງ cache, ນັບຕັ້ງແຕ່
ການດຶງເອົາບາງສິ່ງບາງຢ່າງຢູ່ທີ່ນັ້ນ, ແທນທີ່ຈະສ້າງມັນ, ອາດຈະເຊື່ອງການເພິ່ງພາອາໄສທີ່ລືມ.)
ບາງຄັ້ງການເພິ່ງພາອາໄສເຫຼົ່ານີ້ສາມາດເປັນເລື່ອງເລັກນ້ອຍ. ສໍາລັບຕົວຢ່າງ, ໄດ້ libtool ຄໍາສັ່ງຈະ
ບໍ່ພຽງແຕ່ສ້າງໄຟລ໌ ".lo" ແລະ ".la" ຕາມລາຍຊື່ຢູ່ໃນເສັ້ນຄໍາສັ່ງ, ແຕ່ມັນກໍ່ອາດຈະ
ສ້າງໄດເລກະທໍລີຍ່ອຍທີ່ເອີ້ນວ່າ ".libs" ເຊິ່ງປະກອບດ້ວຍໄຟລ໌ວັດຖຸຕົວຈິງ. ເພື່ອປ້ອງກັນ
ສ້າງຄວາມຜິດພາດ, makepp ປະຕິເສດການເຊື່ອມຕໍ່ໃນໄຟລ໌ ".la" ຈາກ repository. ຫວັງເປັນຢ່າງຍິ່ງໃນ
libtool ໃນອະນາຄົດຈະໄດ້ຮັບການສະຫນັບສະຫນູນທີ່ດີກວ່າ.

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

ການວາງ ຢ່າງແທ້ຈິງ ຊື່ໄຟລ໌ ເຂົ້າໄປໃນ ໂຄງການ

Repositories ຈະບໍ່ເຮັດວຽກຖ້າໄຟລ໌ໃດນຶ່ງທີ່ສ້າງຂຶ້ນມີຊື່ໄຟລ໌ຢ່າງແທ້ຈິງໃນ
ພວກມັນ (ຕົວຢ່າງ, ຖ້າຄໍາສັ່ງສ້າງໃດໆຂອງເຈົ້າຂຽນຊື່ໄຟລ໌ຢ່າງແທ້ຈິງ). ຍົກ​ຕົວ​ຢ່າງ,
ມັນ turns ໃຫ້ເຫັນວ່າໄຟລ໌ ".la" ຜະລິດໂດຍ libtool ມີຊັບສິນນີ້. (ຖ້າທ່ານເບິ່ງ
ເນື້ອໃນຂອງໄຟລ໌ ".la" ທ່ານຈະເຫັນວ່າບັນຊີລາຍຊື່ການເພິ່ງພາອາໄສປະກອບດ້ວຍຢ່າງແທ້ຈິງ
filenames.) ເພື່ອແກ້ໄຂບັນຫາສະເພາະນີ້, makepp ຈະບໍ່ເຊື່ອມຕໍ່ໄຟລ໌ ".la".
ຈາກ repository; ມັນຈະຮຽກຮ້ອງໃຫ້ພວກເຂົາສ້າງຄືນໃຫມ່.

ຫຼີກເວັ້ນການ ເຊື່ອມຕໍ່ in ບໍ່ຈໍາເປັນ ໄດເລກະທໍລີ

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

ເກີນໄປ ຫຼາຍ​ຄົນ ໄຟ

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

ຂ້າມ repository ສໍາເນົາ
ຖ້າ​ຫາກ​ວ່າ​ທ່ານ​ເຮັດ​ການ​ດັດ​ແກ້​ໄຟລ​໌​ໃດ​ຫນຶ່ງ​ໃນ​ທ້ອງ​ຖິ່ນ​, makepp ຈະ​ໄດ້​ຮັບ​ການ​ປົກ​ກະ​ຕິ​ແລະ​
recompile ໄຟລ໌ໂດຍໃຊ້ສໍາເນົາທ້ອງຖິ່ນແທນທີ່ຈະເປັນສໍາເນົາ repository.

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

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

chmod a-rw file-to-be-excluded

ນີ້ຈະປ້ອງກັນບໍ່ໃຫ້ makepp ຈາກການລວມເອົາມັນຈາກບ່ອນເກັບມ້ຽນ. Makepp ຍັງປະກອບມີ
ລະຫັດພິເສດເພື່ອໃຫ້ໄຟລ໌ທີ່ບໍ່ສາມາດອ່ານໄດ້ບໍ່ກົງກັບສັນຍາລັກແທນຫຼືກົດລະບຽບຮູບແບບ.

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

ວິທີອື່ນທີ່ຈະເຮັດຄືການໂທຫາ makepp ດ້ວຍທາງເລືອກການຍົກເວັ້ນໜຶ່ງ ຫຼືຫຼາຍກວ່ານັ້ນ:

mpp -R /path/to/rep --dont-read=/path/to/rep/file-to-be-excluded

ເຮັດບໍ່ໄດ້ ການນໍາໃຊ້ repositories ສໍາລັບການ ໄຟ ທີ່ ສາມາດເຮັດໄດ້ ປ່ຽນ!
ຢ່າພະຍາຍາມໃຊ້ repository ສໍາລັບໄຟລ໌ທີ່ເປັນສ່ວນຫນຶ່ງຂອງການກໍ່ສ້າງຂອງທ່ານ. ຕົວຢ່າງ, ເຈົ້າ
ອາດຈະຖືກລໍ້ລວງໃຫ້ພະຍາຍາມໃຊ້ repositories ເພື່ອເຮັດໃຫ້ໄຟລ໌ .h ສາທາລະນະທັງໝົດຂອງເຈົ້າຢູ່ໃນອັນດຽວກັນ
ໄດເລກະທໍລີ, ເຊັ່ນນີ້:

# makefile ລະດັບສູງສຸດ
repository include=module1/include
repository include=module2/include
repository include=module3/include
repository include=module4/include

ນີ້ອາດຈະບໍ່ເປັນຄວາມຄິດທີ່ດີຖ້າ ໃດ ຂອງ .h ໄຟລ໌ແມ່ນຕົວຂອງມັນເອງຜົນຜະລິດຂອງ a
ໂຄງການ (ຕົວຢ່າງ, yacc ຫຼືບາງໂຄງການອື່ນໆທີ່ spits ລະຫັດແຫຼ່ງ C), ເນື່ອງຈາກວ່າ makepp
ສົມມຸດວ່າໄຟລ໌ໃນ repositories ບໍ່ເຄີຍມີການປ່ຽນແປງ. ຖ້າຫາກວ່າການກໍ່ສ້າງຕ້ອງການ include/xyz.h, ແລະ
module2/include/xyz.h ຕົວຈິງແລ້ວຕ້ອງໄດ້ຮັບການຜະລິດໂດຍບາງໂຄງການ, makepp ຈະບໍ່ຮູ້
ເພື່ອດໍາເນີນການໂຄງການ. ມັນດີກວ່າທີ່ຈະໃຊ້ເຕັກນິກເຊັ່ນນີ້ເພື່ອເອົາທັງຫມົດຂອງເຈົ້າ .h ໄຟ
ເຂົ້າໄປໃນບັນຊີທົ່ວໄປປະກອບມີ:

# module1/Makeppfile
../include/%.h : include/%.h
&cp $(input) $(output)
# ເຈົ້າສາມາດ (ມີປະສິດທິພາບກວ່າແຕ່ມີບັນຫາໃນ Windows) ເຮັດສິ່ງຕໍ່ໄປນີ້:
# &ln -r $(input) $(output)

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

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

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