makepp_repositories - ออนไลน์ใน Cloud

โครงการ:

ชื่อ

makepp_repositories -- วิธีใช้ที่เก็บข้อมูลสำหรับบิลด์ตัวแปร สำหรับการบำรุงรักษา a
แหล่งรวมกลาง และสิ่งอื่น ๆ

DESCRIPTION

A กรุ เป็นไดเร็กทอรีหรือไดเร็กทอรีลำดับชั้นนอกไดเร็กทอรีดีฟอลต์ที่
มีไฟล์ที่ makefile ต้องการในแผนผังไดเร็กทอรีปัจจุบัน Makepp can
ลิงก์ไฟล์จากที่เก็บโดยอัตโนมัติไปยังแผนผังไดเร็กทอรีปัจจุบันหากไฟล์เป็น
จำเป็น ที่เก็บมีฟังก์ชันที่คล้ายกับตัวแปร "VPATH" แต่ (ไม่เหมือน
"VPATH" ใน make เวอร์ชันอื่น) คุณไม่จำเป็นต้องทำอะไรเป็นพิเศษกับ makefile ของคุณ
เพื่อให้พวกเขาทำงาน

ที่เก็บถูกระบุด้วยตัวเลือกบรรทัดคำสั่ง "-R" หรือ "--repository" หรือด้วย
คำสั่ง "repository" ใน makefile สังเกตว่าถ้าคุณมีนิสัยชอบโทรหา makepp
ในไดเร็กทอรีย่อยต่างๆ ของแผนผังการสร้างของคุณ คุณสามารถนำเข้าใหม่โดยไม่ได้ตั้งใจได้ง่ายๆ
ที่เก็บข้อมูลที่อื่น เพื่อเป็นการป้องกันสิ่งนี้ หากคุณใช้ ไฟล์ RootMakepp, เมคอัพ
จะปฏิเสธที่จะเริ่มต้นหากพบหนึ่งด้านบนหรือด้านล่างที่จะนำเข้า

นี่ค่อนข้างจะเทียบได้กับระบบปฏิบัติการ union filesystems (unionfs...) The
ไดเร็กทอรีปัจจุบันเป็นเหมือนเลเยอร์ที่เขียนได้ระดับสูงสุด ที่เก็บทั้งหมดเป็นเหมือน
เลเยอร์แบบอ่านอย่างเดียวที่ต่ำกว่า

ที่เก็บมีประโยชน์ในสถานการณ์ที่แตกต่างกันหลายประการ:

· เมื่อคุณต้องการวางวัตถุและไฟล์เรียกทำงานของคุณในไดเร็กทอรีแยกต่างหาก แต่
makefile ถูกเขียนขึ้นเพื่อวางไว้ในไดเร็กทอรีเดียวกันกับแหล่งที่มา

· เมื่อคุณต้องการสร้างโปรแกรมเดียวกันสองวิธีที่แตกต่างกัน (เช่น มีสองวิธีที่แตกต่างกัน
ชุดของตัวเลือกการคอมไพล์ หรือสำหรับสถาปัตยกรรมที่แตกต่างกันสองแบบ)

· เมื่อคุณไม่มีสิทธิ์เขียนในทรีต้นทางทั้งหมดหรือบางส่วน

· เมื่อนักพัฒนาหลายคนกำลังทำงานในโครงการเดียวกันและมีแหล่งที่มาร่วมกัน
ที่เก็บที่มีแหล่งที่มาทั้งหมดสำหรับโครงการ ผู้พัฒนาแต่ละรายสามารถแก้ไขได้เท่านั้น
ไฟล์ที่เขาต้องเปลี่ยนในไดเร็กทอรีท้องถิ่นของเขาโดยไม่กระทบกับไฟล์อื่น
นักพัฒนาและ makepp จะดึงไฟล์ที่ไม่ได้แก้ไขจากแหล่งที่มาโดยอัตโนมัติ
กรุ

การใช้งานที่เก็บของ Makepp ไม่จำเป็นต้องเขียนคำสั่ง build ใหม่
เลยไม่เหมือนกับที่เก็บ (ตัวอย่าง) ที่มีข้อเสีย Makepp ใส่ลิงก์สัญลักษณ์ลงใน
ไดเร็กทอรีที่คำสั่งคาดหวัง ตราบใดที่คำสั่งไม่ได้อ้างถึง
ไดเร็กทอรีที่แน่นอน คำสั่งเชลล์เดียวกันจะทำงานกับไฟล์จากที่เก็บ
ซึ่งหมายความว่ามันทำงานไม่เพียงแต่สำหรับคำสั่งการคอมไพล์, แต่คำสั่งประเภทใดๆ ของคุณ
สามารถคิดที่จะใส่ใน makefile ของคุณ

Makepp มีกลไกอีกแบบหนึ่งที่เรียกว่า a สร้าง แคช ซึ่งแก้บางอย่างได้เหมือนกัน
ประเภทของปัญหาเป็นที่เก็บในลักษณะที่แตกต่างกัน ขึ้นอยู่กับปัญหาของคุณ บิลด์
แคชอาจมีประโยชน์มากกว่าที่เก็บ ดู makepp_build_cache สำหรับข้อมูลเกี่ยวกับ
บิลด์แคชและการเปรียบเทียบบิลด์แคชและที่เก็บ

ตัวอย่าง
ที่เก็บจะอธิบายได้ดีที่สุดด้วยตัวอย่างหลายๆ อย่างเกี่ยวกับสิ่งที่คุณทำได้

ต่าง การรวบรวม ตัวเลือก

สมมติว่าคุณมีโปรแกรมง่ายๆ ที่มี makefile ที่มีลักษณะดังนี้:

CFLAGS = -O2
วัตถุ = ao bo co
my_program: $(วัตถุ)
ซีซี $(อินพุต) -o $(เอาต์พุต)

%.o: %.ค
ซีซี $(CFLAGS) -c $(อินพุต) -o $(เอาต์พุต)

makefile นี้วางไฟล์ "ao", "bo", "co" และ "my_program" ไว้ในไดเร็กทอรีเดียวกัน
เป็นไฟล์ต้นฉบับ

บางครั้งคุณต้องการวางไฟล์ไบนารีลงในไดเร็กทอรีแยกต่างหาก ตัวอย่างเช่น คุณ
อาจสร้างโปรแกรมของคุณบนสถาปัตยกรรมที่แตกต่างกันหลายแบบ และคุณไม่ต้องการไบนารี
ไฟล์บนสถาปัตยกรรมหนึ่งจะถูกแทนที่ด้วยไฟล์ไบนารีในอีกอันหนึ่ง หรือคุณอาจจะ
ต้องการเปลี่ยนแปลงชั่วคราวและคอมไพล์ใหม่โดยไม่ต้องลบการคอมไพล์ก่อนหน้าออก
ผลลัพธ์. หากไม่มีที่เก็บ คุณจะต้องแก้ไข makefile ของคุณเพื่อวาง
วัตถุที่อื่น

อย่างไรก็ตาม ด้วยพื้นที่เก็บข้อมูล คุณไม่จำเป็นต้องแตะ makefile ของคุณเลย พิจารณา
ลำดับของคำสั่งดังต่อไปนี้:

% ซีดี my_program_source
% makepp # สร้างโดยใช้ makefile ด้านบนและ
# ไฟล์อ็อบเจ็กต์ไปที่ไดเร็กทอรี
# my_program_source
% ซีดี ..
% mkdir binary-debug # สร้างไดเร็กทอรีที่สะอาดสำหรับสร้าง
% cd binary-debug # โปรแกรมเดียวกันกับตัวเลือกที่แตกต่างกัน
% makepp -R ../my_program_source CFLAGS=-g
# ตอนนี้วัตถุเข้าสู่การดีบักไบนารี

คำสั่ง makepp แรกจะคอมไพล์ซอร์สไฟล์ด้วยการเพิ่มประสิทธิภาพและวางอ็อบเจกต์
ลงในไดเร็กทอรี "my_program_source" เพราะนั่นคือสิ่งที่ makefile ควรจะเป็น
ทำ. ตอนนี้เราต้องการสร้างโปรแกรมใหม่ แต่เราต้องการเปลี่ยนค่าของ "CFLAGS" เป็น
คอมไพล์สำหรับการดีบัก เราระบุค่าใหม่ของ "CFLAGS" บนบรรทัดคำสั่งและเราด้วย
บอก makepp ว่าไดเร็กทอรี "my_program_source" เป็นที่เก็บข้อมูลโดยใช้ตัวเลือก "-R"

ทุกครั้งที่ makepp รู้ตัวว่าต้องการไฟล์ที่ยังไม่มีอยู่ในปัจจุบัน
ไดเร็กทอรีจะดูอยู่ในที่เก็บ ในกรณีนี้ อันดับแรกจะค้นหา makefile
ซึ่งไม่มีอยู่ในไดเร็กทอรีย่อย "binary-debug" ดังนั้นจึงสร้างลิงค์สัญลักษณ์ไปยัง
จาก makefile ใน "my_program_source" แล้วอ่านใน makefile แล้วก็
สังเกตว่าต้องใช้ไฟล์ "ac" เพื่อสร้าง "ao" ดังนั้นจึงลิงก์ใน "ac"
จากที่เก็บ หาก "ac" รวมไฟล์ใด ๆ ที่มีอยู่ใน "my_program_source" ดังนั้น
สิ่งเหล่านี้จะถูกเชื่อมโยงโดยอัตโนมัติเช่นกัน หมายเหตุ: ลิงค์เหล่านั้นมีประโยชน์สำหรับสิ่งต่าง ๆ
เช่นการดีบัก แต่ถ้าคุณไม่ชอบพวกเขา "makeppclean -R" สามารถลบออกได้

การรันคำสั่ง build ใน "binary-debug" จะไม่แตะต้องไฟล์ใดๆ ใน
"my_program_source" ดังนั้นจากไฟล์ต้นฉบับชุดเดียวกัน ตอนนี้คุณมีสองไฟล์ที่แตกต่างกัน
สำเนาของโปรแกรม ชุดหนึ่งคอมไพล์ด้วยการเพิ่มประสิทธิภาพ และอีกชุดที่คอมไพล์สำหรับการดีบัก และ
สิ่งนี้เกิดขึ้นโดยไม่แตะต้อง makefile เลย

ข้อดีของการใช้ที่เก็บแทนการคอมไพล์ใหม่และเขียนทับ
ไบนารีดั้งเดิมคือตอนนี้ถ้าเราแก้ไขข้อผิดพลาดของเราและต้องการกลับไปสู่การปรับให้เหมาะสม
เวอร์ชัน เราไม่ต้องคอมไพล์ใหม่ทั้งหมด เนื่องจากไฟล์อ็อบเจ็กต์ดั้งเดิมยังคงอยู่
รอบ ๆ และส่วนใหญ่ยังคงใช้ได้ เราสามารถประหยัดเวลาในการคอมไพล์ใหม่ได้มาก
สิ่งนี้ไม่ได้สร้างความแตกต่างอย่างมากเมื่อมีไฟล์ต้นทางเพียงสามไฟล์ที่เกี่ยวข้อง แต่สำหรับ a
บิลด์ที่ใหญ่ขึ้นซึ่งใช้เวลาไม่กี่นาทีหรือชั่วโมงจึงจะเสร็จสมบูรณ์ ช่วยประหยัดเวลาของโปรแกรมเมอร์และ
ความผิดหวังอาจมีนัยสำคัญ

สร้างใหม่ หนึ่ง ไฟล์ สีสดสวย a ผู้เยาว์ การดัดแปลง ไปยัง การรวบรวม คำสั่ง

Makepp ไม่ได้ดึงเฉพาะไฟล์ต้นฉบับจากที่เก็บ หากไฟล์อ็อบเจ็กต์ใน
ที่เก็บข้อมูลไม่จำเป็นต้องสร้างใหม่ มันจะใช้ ตัวอย่างเช่น พิจารณาเล็กน้อย
แก้ไข makefile ด้านบน:

CFLAGS := -O2
A_CFLAGS := -O6 -funroll-ลูป

วัตถุ := อ่าวบ่อ co

my_program: $(วัตถุ)
ซีซี $(อินพุต) -o $(เอาต์พุต)

%.o: %.ค
ซีซี $(CFLAGS) -c $(อินพุต) -o $(เอาต์พุต)

ao: ac
ซีซี $(A_CFLAGS) -c $(อินพุต) -o $(เอาต์พุต)

แนวคิดคือ "ao" มีรหัสเวลาที่สำคัญ ดังนั้นจึงรวบรวมด้วยค่าที่สูงกว่า
การปรับให้เหมาะสมกว่าวัตถุที่เหลือ สมมติว่าเราต้องการทดสอบว่าแตกต่างกันอย่างไร
เวลาจะมีตัวเลือกการรวบรวมที่แตกต่างกัน ที่เก็บสามารถช่วยในเรื่องนี้ได้เช่นกัน:

% ซีดี my_program_source
% makepp # สร้างโดยใช้ makefile ด้านบนและ
# ไฟล์อ็อบเจ็กต์ไปที่ไดเร็กทอรี
# my_program_source
% ซีดี ..
% mkdir no-unrolling # สร้างไดเร็กทอรีที่สะอาดสำหรับสร้าง
% cd no-unrolling # โปรแกรมเดียวกันกับตัวเลือกที่แตกต่างกัน
% makepp -R ../my_program_source A_CFLAGS=-O2
% ซีดี ..
% เวลาที่ไม่มีการคลี่ออก/my_program # เปรียบเทียบสองเวอร์ชันของโปรแกรม
% เวลา my_program_source/my_program

Makepp ดำเนินการเหมือนเดิม โดยเชื่อมโยงในสำเนาของ makefile แล้วตรวจสอบวัตถุ
ไฟล์. ตอนนี้มีเพียงโมดูล "ao" เท่านั้นที่ต้องการการคอมไพล์ใหม่ เนื่องจากตัวเลือกสำหรับ "bo" และ "co"
ไม่ได้เปลี่ยน Makepp สังเกตว่าสามารถใช้ "bo" และ "co" จากที่เก็บได้ ดังนั้น
มันแค่เชื่อมโยงสิ่งเหล่านั้นเข้าไป อย่างไรก็ตาม มันจะคอมไพล์ "ao" ใหม่ในไดเร็กทอรี "no-unrolling"
เมื่อการคอมไพล์เสร็จสิ้น โปรแกรมทั้งสองเวอร์ชันที่แตกต่างกันจะเป็น
สอบเทียบ

สร้างใหม่ สีสดสวย a ผู้เยาว์ การดัดแปลง ไปยัง แหล่ง

ตอนนี้ สมมติว่าเราต้องการเปลี่ยนแปลง "ac" และเปรียบเทียบโปรแกรมก่อนและหลัง
การเปลี่ยนแปลง. ที่เก็บสามารถช่วยได้อีกครั้ง พิจารณาลำดับของคำสั่งนี้:

% mkdir แก้ไข-a
% cp my_program_source/ac modified-a
% cd ดัดแปลง-ก
% emacs ac # ทำการปรับเปลี่ยนเฉพาะโมดูลนี้
% makepp -R ../my_program_source

ที่นี่เราได้สร้างไดเร็กทอรีใหม่ที่มีไฟล์ต้นฉบับเพียงไฟล์เดียวที่เราต้องการ
แก้ไข. Makepp ตอนนี้ใช้ "ac" จากไดเรกทอรีย่อย "modified-a" แต่ใช้สำเนาของ
"b" และ "c" จากไดเร็กทอรี "my_program_source" โดยไม่ต้องเปลี่ยนไบนารีใด ๆ
ไฟล์ใน "my_program_source" เราได้สร้างสำเนาของโปรแกรมที่
รวมการเปลี่ยนแปลงของเราเป็น "ac" หากมีนักพัฒนารายอื่นใช้แหล่งที่มาใน
"my_program_source" จะไม่ได้รับผลกระทบจากการเปลี่ยนแปลงของเรา

ที่เก็บสามารถใช้เป็นวิธีที่รวดเร็วในการสร้างตัวแปรของโปรแกรมโดยไม่ต้อง
เพิ่มเงื่อนไขที่ซับซ้อนให้กับ makefile ไม่มีไฟล์ใดในต้นฉบับ
ไดเร็กทอรีถูกแก้ไข; พวกมันถูกใช้ตามความจำเป็น

การใช้ a ไดเรกทอรี ลำดับชั้น

ที่จริงแล้วที่เก็บไม่ได้เป็นเพียงไดเร็กทอรีเดียว แต่เป็นลำดับชั้นของไดเร็กทอรีทั้งหมด
สมมติว่าคุณใช้ /ของเรา/ห้องสมุด เป็นที่เก็บข้อมูล ตอนนี้ /ของเรา/ห้องสมุด อาจมีมากมาย
ไดเรกทอรีย่อย เช่น /ของเรา/ห้องสมุด/gui และ /ของเรา/ห้องสมุด/เครือข่าย. พิจารณาคำสั่งนี้:

% makepp -R /ของเรา/library

คำสั่งใดๆ ใน makefile ที่อ้างถึงไฟล์ในไดเร็กทอรี ./เครือข่าย จะจริง
รับไฟล์จาก /ของเรา/ห้องสมุด/เครือข่ายและในทำนองเดียวกันสำหรับ ./กุย. Makepp โดยอัตโนมัติ
สร้างไดเร็กทอรีใด ๆ ที่มีอยู่ในที่เก็บ แต่ไม่มีอยู่ในไดเร็กทอรีปัจจุบัน

การเชื่อมโยง ไปยัง ใด สถานที่ in ไฟล์ ระบบ

ตัวอย่างทั้งหมดข้างต้นแสดงไฟล์จากที่เก็บที่ลิงก์กับ current
ไดเร็กทอรีหรือไดเร็กทอรีย่อย แต่คุณสามารถให้ makepp เชื่อมโยงไปยังที่ใดก็ได้
ในระบบไฟล์ที่คุณมีสิทธิ์เขียน ทำได้โดยระบุ
"-R new-location=old-location".

ตัวอย่างเช่น บางครั้งการพิมพ์ข้อความต่อไปนี้อาจดูน่าเบื่อหน่ายเล็กน้อย

mkdir ทางเลือก-build
cd ทางเลือก-build
เมคอัพ -R ..

คุณสามารถทำทุกอย่างได้ด้วยคำสั่งเดียว ดังนี้:

makepp -R ทางเลือก-build=. -F ทางเลือก-สร้าง

"-F" หรือ "-makeppfile" เปลี่ยนเป็นไดเร็กทอรีนั้นก่อนที่จะโหลด makefile คุณต้อง
ระบุ "-R" ก่อน "-F" โปรดทราบว่าตัวอย่างนี้วางโครงสร้างโครงสร้างใหม่ไว้ใน
ที่เก็บ นั่นจะไม่ทำงานหากคุณใช้ a ไฟล์ RootMakepp เพราะเมคพปกป้อง
กับต้นไม้ที่ซ้อนกัน ก็ไม่ใช่ความคิดที่ดีเช่นกันถ้าคุณใช้ **, เพราะถ้าคุณเคยสร้าง
ในที่เก็บจะยังพบไฟล์ที่แก้ไขและสร้างในทรีย่อยนี้

การกำหนดตำแหน่งอื่นในระบบไฟล์อาจเป็นประโยชน์สำหรับความซับซ้อนมากขึ้น
builds ซึ่งมีไดเร็กทอรีย่อยของไลบรารีหลายไดเร็กทอรี ตัวอย่างเช่น นี่คือคำสั่ง 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 ทดสอบสร้าง/ซีสเคป

คำสั่งนี้โหลดไฟล์จากที่เก็บสี่แห่งที่แตกต่างกัน จากนั้น cds ไปยัง
./test-build/seescape ไดเร็กทอรีและรัน makefile ที่นั่น ไฟล์ที่มีอยู่ใน
ไดเร็กทอรีทรีที่ขึ้นต้นด้วย /src/ซีสเคป มีการเชื่อมโยงเข้าสู่ ./test-build/seescape. ใน
กล่าวอีกนัยหนึ่ง makepp จะเชื่อมโยงไฟล์ชั่วคราว /src/seescape/gui/image_canvas.cxx ไปยัง
./test-build/seescape/gui/image_canvas.cxx เมื่อมีความจำเป็น คำสั่งนี้จะใช้ได้แม้กระทั่ง
ถ้าไดเร็กทอรี "test-build" ยังไม่มีอยู่ makepp จะสร้างให้คุณ (แต่คุณ
ต้องระบุตัวเลือก "-R" ก่อนตัวเลือก "-F" ในบรรทัดคำสั่ง)

แพลตฟอร์มที่หลากหลาย เท่ากัน ที่เก็บ

สมมติว่าโครงการของคุณดูแลโดยกลุ่มอิสระหลายกลุ่ม คุณสามารถมีได้หนึ่งตัว
พื้นที่เก็บข้อมูลที่สมบูรณ์พร้อมแหล่งที่มาทั้งหมดในขณะที่กำลังใช้งานจริงหรืออย่างน้อย
ทดสอบสำเร็จแล้ว ทุกกลุ่มสามารถมีที่เก็บที่ว่างเปล่าเป็นส่วนใหญ่ด้วย (ส่วนหนึ่งของ) the
โครงสร้างเดียวกันประกอบด้วยสมาชิกกลุ่มไฟล์ที่พัฒนาเสร็จแล้ว

ไดเร็กทอรีปัจจุบันของนักพัฒนาจะมีไฟล์ที่กำลังทำงานอยู่ กลุ่ม
ที่เก็บข้อมูลจะเป็นอันแรกที่ได้รับ และพื้นที่เก็บข้อมูลจริงจะเป็นอันสุดท้าย ดังนั้น
มันจัดเตรียมไฟล์ที่ไม่พบในที่เก็บกลุ่ม:

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

เนื่องจากไดเร็กทอรีนี้ค่อนข้างคงที่ คุณอาจต้องการใส่ file
.makepprc ที่รูทของมันด้วยเนื้อหาต่อไปนี้:

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

หรือ สมมติว่ามีเส้นทางที่แน่นอน คุณสามารถเขียนลงใน makefile ของคุณ:

ที่เก็บ /path/to/production/repository

และเนื่องจากเห็นตัวเลือกก่อนที่จะอ่าน makefile คุณจึงสามารถเรียก just

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

คลัง as การแก้ไข ส่วนหนึ่ง of ธุรกิจ สร้าง ระบบ

หากคุณรู้ว่าคุณใช้พื้นที่เก็บข้อมูลอยู่เสมอ คุณสามารถใช้ "ที่เก็บ" หรือ "vpath"
คำสั่งใน makefile ของคุณ

คำเตือน สีสดสวย ที่เก็บ
เมื่อ การเชื่อมโยง ได้รับ in ทาง

สำหรับการค้นหาลำดับชั้นของไฟล์และการอนุญาตให้ดีบักเกอร์ค้นหา
แหล่งข้อมูลที่เป็นประโยชน์ในการมีลิงก์ที่ใช้ในขณะสร้าง แต่เมื่อคุณต้องการแก้ไข a
ไฟล์หรือซิงค์ใหม่ด้วยการควบคุมเวอร์ชันของคุณ ลิงก์อาจขัดขวางได้ นั่นคือ
เนื่องจากระบบจะข้ามลิงก์และเขียนไปยังไฟล์ในที่เก็บ เว้นแต่
เป็นที่เก็บส่วนตัวของคุณ ใช้สำหรับแยกสิ่งของออกจากกัน นั่นอาจไม่ใช่สิ่งที่คุณ
ต้องการ.

เพื่อเป็นการป้องกันการเขียนทับไฟล์สาธารณะโดยไม่ได้ตั้งใจ ขอแนะนำให้ทำ
แหล่งที่มาในที่เก็บไม่สามารถเขียนได้ มันอาจจะไม่เพียงพอที่จะลบการเขียน
บิตเพราะระบบควบคุมเวอร์ชันที่ยืนยันการล็อกไฟล์เพื่อแก้ไข
อาจทำเช่นนั้น แต่ทำให้ไฟล์สามารถเขียนได้ชั่วคราวในขณะที่ทำการซิงค์ใหม่ ถ้านั่นคือ
กรณีของคุณ พื้นที่เก็บข้อมูลควรเป็นของผู้ใช้รายอื่น

มีกลวิธีสองสามข้อที่จะเอาชนะสิ่งนี้:

· เก็บแหล่งที่มาที่คุณแก้ไขไว้ในที่เก็บ แยกจากแผนผังการสร้างของคุณ เมื่อไหร่ก็ได้
คุณใส่ไฟล์ซึ่งก่อนหน้านี้ถูกดึงมาจากที่เก็บอื่น ลงใน this
แก้ไขที่เก็บ makepp จะสังเกตและดึงมันจากที่นั่น หากเป็น
ที่เก็บแรกที่คุณระบุ

· อย่าลืมลบไฟล์ใดๆ ก่อนสร้างสำเนาเพื่อเขียน หากคุณปฏิบัติตาม
คำแนะนำการป้องกันด้านบน ลืมทำเช่นนี้จะมีข้อความแสดงข้อผิดพลาดเมื่อ
การเขียน. เพื่อช่วยคุณ ฟังก์ชันต่อไปนี้ "delink" จะแทนที่หนึ่งลิงก์ด้วยสำเนา
ของไฟล์ที่เชื่อมโยง ตัวแปรแรกสำหรับ Bournish Shells ทุกประเภท ตัวที่สอง
หนึ่งสำหรับ csh (หรืออย่างน้อย tcsh):

$ delink() { { rm $1 && cat >$1; } <$1; }
% delink นามแฝง '( rm \!:1 && cat >\!:1; ) <\!:1'

· หากคุณรู้สึกว่าไม่ต้องการมัน คุณสามารถลบมันทั้งหมดได้ทุกเมื่อที่คุณต้องการ เช่น
หลังจากรัน makepp ทุกครั้ง อาจมีพื้นหลัง (แบบสั้นหรือแบบยาว):

makeppclean --recurse -- ลิงก์ที่เก็บข้อมูลเท่านั้น
mppc -rR

อย่า สร้าง in a กรุ ในระหว่าง ใช้

ที่เก็บมีไว้เพื่อให้อ่านอย่างเดียวในขณะที่ถูกใช้เป็นที่เก็บข้อมูล Makepp will
ไม่ ทำงานได้อย่างถูกต้องหากคุณเปลี่ยนไฟล์ในที่เก็บของคุณระหว่างการสร้าง
บิลด์ทุกคืนอาจใช้ได้สำหรับคุณ หากไม่มีใครใช้พื้นที่เก็บข้อมูลในขณะนั้น ก่อน
มันเริ่มบิลด์ makepp รับรายการไฟล์ทั้งหมดที่มีอยู่ในที่เก็บและ
ไม่เคยอัปเดตรายการ ยกเว้นไฟล์ที่คาดว่าจะปรากฏ

หากคุณต้องการที่เก็บที่เปลี่ยนแปลงในขณะที่คุณสร้าง คุณอาจต้องการพิจารณา makepp's
สร้างกลไกแคช (ดู makepp_build_cache) หรือใช้คำว่า "คนจน" ก็ได้
repository": คุณสามารถใส่กฎที่ชัดเจนลงใน makefile ของคุณเพื่อสร้างซอฟต์ลิงก์ เช่น
นี้:

%.c : $(ไดเรกทอรี_I_wish_was_a_repository)/%.c
&ln -fs $(อินพุต) $(เอาต์พุต)

ใช้งานได้กับไฟล์ต้นฉบับเท่านั้น คุณไม่สามารถใช้สิ่งนี้เพื่อเชื่อมโยงไฟล์ได้อย่างง่ายดายหากเป็น
สร้างไว้แล้วในที่เก็บ แต่สร้างที่นี่หากยังไม่ได้สร้างตั้งแต่มี
ได้รับอนุญาตให้เป็นวิธีเดียวเท่านั้นในการสร้างไฟล์

ใช้ เพียง ญาติ ชื่อไฟล์

ที่เก็บข้อมูลทำงานอย่างโปร่งใสอย่างสมบูรณ์ if ทำไฟล์ ใช้ เพียง ญาติ ชื่อไฟล์.
ในตัวอย่างข้างต้น ไม่เป็นไรถ้า makefile ใน /src/ซีสเคป อ้างถึง ../HLibแต่
คำสั่งข้างต้นจะไม่ทำงานตามที่คาดไว้หากอ้างถึง /src/HLib. หากคุณต้องการใช้
ชื่อไฟล์ที่แน่นอน คุณสามารถใส่ลงในตัวแปรสร้างแล้วแทนที่บน
บรรทัดคำสั่งเช่นนี้:

% 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 ทดสอบสร้าง/ซีสเคป

ด้านบนจะใช้งานได้ตราบใดที่ไดเร็กทอรี "HLib" เรียกว่า "$(HLIB)" ในทุก
makefiles โปรดทราบว่าคุณต้องระบุเส้นทางที่แน่นอนสำหรับไดเร็กทอรีเพราะ
makepp cd เป็น "test-build/seescape" ก่อนอ่าน makefile สิ่งนี้นำไปสู่ความยาวนานและ
สร้างคำสั่งที่ซับซ้อน ใช้เส้นทางสัมพัทธ์เมื่อเป็นไปได้

มาเคพ ต้อง ทราบ เกี่ยวกับ ทั้งหมด การอ้างอิง

ที่เก็บจะไม่ทำงานหากมีการพึ่งพาที่ซ่อนอยู่ซึ่ง makepp ไม่ทราบ
เกี่ยวกับ. (อันที่จริง การทำบิลด์โดยใช้ที่เก็บเป็นวิธีหนึ่งในการตรวจสอบการลืม
การพึ่งพา แต่สำหรับการตรวจสอบนี้ อย่ารวมเข้ากับแคชของบิวด์ เนื่องจาก
การดึงบางสิ่งที่นั่น แทนที่จะสร้าง อาจซ่อนการพึ่งพาที่ลืมไป)
บางครั้งการพึ่งพาเหล่านี้อาจมีความละเอียดอ่อนพอสมควร ตัวอย่างเช่น ลิบทูล คำสั่งจะ
ไม่เพียงแต่สร้างไฟล์ ".lo" และ ".la" ตามรายการในบรรทัดคำสั่ง แต่ยังอาจ
สร้างไดเร็กทอรีย่อยที่เรียกว่า ".libs" ซึ่งมีไฟล์อ็อบเจ็กต์จริง เพื่อหลีกเลี่ยง
สร้างข้อผิดพลาด makepp ปฏิเสธที่จะเชื่อมโยงในไฟล์ ".la" จากที่เก็บ หวังว่าใน
libtool ในอนาคตจะได้รับการสนับสนุนที่ดีขึ้น

การขึ้นต่อกันที่ซ่อนอยู่จำนวนมากที่เกี่ยวข้องกับการคอมไพล์ถูกจับโดยเครื่องสแกนบรรทัดคำสั่ง
หากคอมไพเลอร์ของคุณใช้แฟล็กการคอมไพล์ Unix ทั่วไป (เช่น "-I", "-D" เป็นต้น) ดังนั้น
โดยปกติแล้ว makepp จะค้นหาว่าไฟล์รวมของคุณอยู่ที่ไหน คุณอาจจะ
ระวังถ้าคุณมีสคริปต์พื้นบ้านที่สร้างไฟล์ที่ makepp ไม่รู้
เกี่ยวกับ. สำหรับบิลด์ที่ถูกต้อง การระบุรายการเป็นสิ่งสำคัญอย่างยิ่ง ทั้งหมด เป้าหมายและการพึ่งพา
(หรือกำหนดโดยอัตโนมัติโดยการสแกน)

วาง แน่นอน ชื่อไฟล์ เข้าไป โปรแกรม

ที่เก็บจะไม่ทำงานหากไฟล์ใด ๆ ที่สร้างขึ้นมีชื่อไฟล์ที่แน่นอนใน
(เช่น หากคำสั่ง build ของคุณเขียนชื่อไฟล์แบบสัมบูรณ์) ตัวอย่างเช่น,
ปรากฎว่าไฟล์ ".la" ที่ผลิตโดย ลิบทูล มีคุณสมบัตินี้ (ถ้าดูเ
เนื้อหาของไฟล์ ".la" คุณจะเห็นว่ารายการการพึ่งพามี Absolute
filenames.) เพื่อแก้ปัญหานี้ makepp จะไม่เชื่อมโยงไฟล์ ".la"
จากที่เก็บ; มันจะยืนกรานที่จะสร้างใหม่

หลีกเลี่ยง การเชื่อมโยง in ไม่จำเป็น ไดเรกทอรี

ที่เก็บอาจทำงานช้าเมื่อเริ่มต้นและใช้หน่วยความจำมากหากมีจำนวนมาก
ไฟล์ที่ไม่จำเป็นในที่เก็บ ตัวอย่างเช่น หากคุณใช้ HTML . อัตโนมัติ
ตัวสร้างเอกสารซึ่งสร้างไฟล์ ".html" นับพันไฟล์จากซอร์สโค้ดของคุณ
อาจไม่ต้องการใส่ไว้ในไดเร็กทอรีย่อยของไดเร็กทอรีที่ใช้เป็นที่เก็บ
ดีกว่าที่จะวางไว้ในแผนผังไดเร็กทอรีอื่นทั้งหมด ดังนั้น repository
กลไกจะไม่โหลดในชื่อของพวกเขา

เกินไป หลาย ไฟล์

ข้อเสียของ repositories คือ symbolic links ซึ่งกลไก repository
การใช้งาน เป็นไฟล์แต่ละไฟล์ (แม้ว่าจะแทบไม่ใช้พื้นที่ดิสก์ก็ตาม) ไม่เหมือนของจริง
ลิงก์ แต่สิ่งเหล่านั้นไม่สามารถข้ามขอบเขตของระบบไฟล์ได้ ในกรณีที่รุนแรง การมีอยู่ของ
ลิงก์สัญลักษณ์จำนวนมากอาจทำให้จำนวนไฟล์ที่คาดการณ์ไว้หมดลง (เรียกว่า
inodes) แม้ว่าจะมีพื้นที่เหลือเฟือ ในกรณีนี้ผู้ดูแลระบบจะต้อง
เพื่อปรับแต่งระบบไฟล์

ที่เอาชนะ กรุ สำเนา
หากคุณทำการแก้ไขใดๆ กับไฟล์ในเครื่อง โดยปกติ makepp จะรับรู้สิ่งนี้และ
คอมไพล์ไฟล์ใหม่โดยใช้สำเนาในเครื่องแทนการคัดลอกที่เก็บ

หากคุณกำลังใช้พื้นที่เก็บข้อมูลเพื่อรักษาฐานรหัสกลาง และคุณมีนักพัฒนา
ทำงานกับสำเนาในเครื่องซึ่งมีเฉพาะไฟล์ที่แก้ไข ปัญหาหนึ่งที่
ขึ้นมาคือ: เกิดอะไรขึ้นถ้านักพัฒนาต้องการลบไฟล์ออกจากบิลด์ในเครื่องของเขา แต่
ที่เก็บข้อมูลยังคงมีอยู่หรือไม่ หากผู้พัฒนาลบสำเนาในเครื่อง makepp will
ใส่สำเนาจากที่เก็บอย่างมีความสุขและบิลด์จะดำเนินการราวกับว่าไฟล์
มีอยู่

เทคนิคหนึ่ง (ไม่ใช่สำหรับรูทผู้ใช้) สำหรับปัญหานี้คือการสร้างไฟล์ที่คุณต้องการ
ไม่ให้รวมไว้ในกระบวนการสร้างที่อ่านไม่ได้เช่นนี้

chmod a-rw ไฟล์ที่จะแยกออก

วิธีนี้จะป้องกันไม่ให้ makepp รวมเข้ากับที่เก็บ Makepp ยังรวมถึง
รหัสพิเศษเพื่อให้ไฟล์ที่อ่านไม่ได้ตรงกับสัญลักษณ์แทนหรือกฎรูปแบบ

ในทำนองเดียวกัน เพื่อป้องกันไม่ให้ makepp รวมไดเรกทอรีย่อยทั้งหมด ให้สร้าง local
ไดเร็กทอรีที่มีชื่อเหมือนกันแต่ไม่สามารถเขียนได้ หากคุณต้องการให้ makepp ละเลย
ไดเร็กทอรีทั้งหมดแล้วทำให้อ่านไม่ได้ด้วย (ไดเร็กทอรีแบบอ่านอย่างเดียวถูกค้นหาแต่
เป้าหมายในนั้นมักจะไม่สร้าง)

วิธีอื่นในการทำเช่นนี้คือการเรียก makepp ด้วยตัวเลือกการยกเว้นอย่างน้อยหนึ่งตัวเลือก:

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

อย่า ใช้ ที่เก็บ สำหรับ ไฟล์ ที่ สามารถ เปลี่ยนแปลง!
อย่าพยายามใช้ที่เก็บสำหรับไฟล์ที่เป็นส่วนหนึ่งของงานสร้างของคุณ ตัวอย่างเช่น คุณ
อาจถูกล่อลวงให้ลองใช้ที่เก็บเพื่อใส่ไฟล์ .h สาธารณะทั้งหมดของคุณไว้ในที่เดียวกัน
ไดเร็กทอรีดังนี้:

# makefile ระดับบนสุด
พื้นที่เก็บข้อมูล include=module1/include
พื้นที่เก็บข้อมูล include=module2/include
พื้นที่เก็บข้อมูล include=module3/include
พื้นที่เก็บข้อมูล include=module4/include

นี่คงไม่ใช่ความคิดที่ดีถ้า ใด ของ .h ไฟล์เป็นผลลัพธ์ของa
โปรแกรม (เช่น yacc หรือโปรแกรมอื่นที่แยกซอร์สโค้ด C) เนื่องจาก makepp
ถือว่าไฟล์ในที่เก็บไม่เคยเปลี่ยนแปลง หากความต้องการสร้าง รวม/xyz.hและ
โมดูล2/รวม/xyz.h จริงๆแล้วจำเป็นต้องผลิตโดยบางโปรแกรม makepp จะไม่รู้
เพื่อรันโปรแกรม จะดีกว่าถ้าใช้เทคนิคแบบนี้ใส่ทั้งหมดของคุณ .h ไฟล์
เป็นไดเร็กทอรีรวมทั่วไป:

#module1/Makeppfile
../include/%.h : รวม/%.h
&cp $(อินพุต) $(เอาต์พุต)
# คุณสามารถ (มีประสิทธิภาพมากขึ้นแต่มีปัญหาใน Windows) ทำสิ่งต่อไปนี้:
# &ln -r $(อินพุต) $(เอาต์พุต)

Makepp อาจยังคงพยายามสร้างไฟล์ที่เกิดขึ้นในที่เก็บหากมีบางสิ่งถาม
สำหรับพวกเขาโดยตรง แต่มันจะไม่สร้างพวกเขา on ตัวแทน ของไดเรกทอรีท้องถิ่น ผลลัพธ์
ของสิ่งนี้ได้ค่อนข้างสับสนเพราะมันสามารถนำไปสู่ลิงค์สัญลักษณ์ที่เก็บเป็น
ใช้ในขณะที่เป้าหมายของพื้นที่เก็บข้อมูลล้าสมัย แต่เป้าหมายนั้นอาจได้รับการอัปเดตในภายหลัง
ในการสร้าง คุณสามารถป้องกันไม่ให้สิ่งนี้เกิดขึ้นได้โดยทำให้แน่ใจว่า
ที่เก็บข้อมูลถูกอ้างถึง เพียง ผ่านเส้นทางที่เก็บหรือทำให้แน่ใจว่ามี
เป็นกฎในเครื่องสำหรับไฟล์ที่เก็บที่สร้างขึ้นทั้งหมดด้วย

อีกวิธีหนึ่งในการหลีกเลี่ยงการคอมไพล์ไฟล์ที่เหมือนกันในไดเร็กทอรีที่ต่างกันคือการใช้ a
สร้างแคช (ดูรายละเอียดที่ makepp_build_cache) แคชของบิวด์ไม่มี
ข้อจำกัดที่ไฟล์จะไม่เปลี่ยนแปลง

ใช้ makepp_repositories ออนไลน์โดยใช้บริการ onworks.net