makepp_repositories - מקוון בענן

תָכְנִית:

שֵׁם

makepp_repositories -- כיצד להשתמש במאגרים עבור בניית וריאציות, לשמירה על א
אוסף מרכזי של מקורות ודברים אחרים

תיאור

A מאגר הוא ספרייה או היררכיית ספריות מחוץ לספריית ברירת המחדל
מכיל קבצים שקובץ ה-make צריך בעץ הספריות הנוכחי. Makepp יכול
מקשרים אוטומטית קבצים מהמאגר לעץ הספריות הנוכחי אם כן
נָחוּץ. מאגרים מספקים פונקציונליות דומה למשתנה "VPATH", אך (בניגוד ל
"VPATH" בגרסאות אחרות של make) אינך צריך לעשות שום דבר מיוחד לקובץ ה-make
לגרום להם לעבוד.

מאגרים מצוינים עם אפשרות שורת הפקודה "-R" או "--repository" או עם
הצהרת "מאגר" בקובץ makefile. שימו לב שאם יש לכם הרגל להתקשר ל-makepp
בספריות משנה שונות של עץ הבנייה שלך, קל לייבא מחדש בטעות א
מאגר במקום אחר. כהגנה מפני זה, אם אתה משתמש RootMakeppfile, makepp
יסרב להתחיל אם הוא ימצא אחד מעל או מתחת למקום שבו הוא יבוא.

זה דומה במקצת למערכות הקבצים של איחוד מערכת ההפעלה (unionfs...) The
הספרייה הנוכחית היא כמו השכבה הניתנת לכתיבה ברמה הגבוהה ביותר. כל המאגרים הם כמו
שכבות תחתונות לקריאה בלבד.

מאגרים שימושיים בכמה מצבים שונים:

· כאשר אתה רוצה למקם את האובייקט ואת קבצי ההפעלה שלך בספרייה נפרדת, אבל
ה-makefile נכתב כדי למקם אותם באותה ספרייה כמו המקורות.

· כאשר אתה רוצה לבנות את אותה תוכנית בשתי דרכים שונות (למשל, עם שתיים שונות
קבוצות של אפשרויות קומפילציה, או עבור שתי ארכיטקטורות שונות).

· כאשר אין לך גישת כתיבה לכל או חלק מעץ המקור.

· כאשר מספר מפתחים עובדים על אותו פרויקט, ויש מקור משותף
מאגר המכיל את כל המקורות לפרויקט. כל מפתח יכול לשנות רק
את הקבצים שהוא צריך לשנות בספרייה המקומית שלו מבלי להשפיע על האחר
מפתחים, ו-makepp יביאו אוטומטית את הקבצים שלא השתנו מהמקור
מאגר.

יישום המאגרים של Makepp אינו מצריך כתיבה מחדש של פקודות ה-build
בכלל, שלא כמו (למשל) מאגרים בחסרונות. Makepp מכניס קישור סמלי לתוך
ספרייה שבה הפקודה מצפה לה. כל עוד הפקודה לא מתייחסת
ספריות מוחלטות, אותה פקודת מעטפת בדיוק תעבוד עם קבצים ממאגר.
זה אומר שזה עובד לא רק עבור פקודות קומפילציה, אלא כל סוג של פקודה שאתה
יכול לחשוב להכניס את ה-makefile שלך.

ל-Makepp יש סוג אחר של מנגנון שנקרא a לִבנוֹת מטמון מה שפותר חלק מאותו הדבר
סוגים של בעיות כמאגרים בדרך אחרת. תלוי בבעיה שלך, מבנה
מטמון עשוי להיות שימושי יותר ממאגר. ראה makepp_build_cache למידע על
בניית מטמונים והשוואה של בניית מטמונים ומאגרים.

דוגמאות
מאגרים מוסברים בצורה הטובה ביותר על ידי מספר דוגמאות של מה שאתה יכול לעשות.

אחר קומפילציה אפשרויות

נניח שיש לך תוכנית פשוטה עם makefile שנראה בערך כך:

CFLAGS = -O2
OBJECTS = ao bo co
my_program: $(OBJECTS)
cc $(כניסות) -o $(פלט)

%.o: %.c
cc $(CFLAGS) -c $(קלט) -o $(פלט)

Makefile זה ממקם את הקבצים "ao", "bo", "co" ו-"my_program" באותה ספרייה
בתור קבצי המקור.

לפעמים אתה רוצה למקם את הקבצים הבינאריים בספרייה נפרדת. למשל, אתה
עשוי לבנות את התוכנית שלך על כמה ארכיטקטורות שונות, ואתה לא רוצה את הבינארי
קבצים בארכיטקטורה אחת יוחלפו בקבצים הבינאריים בארכיטקטורה השנייה. או שאולי
רוצה לבצע שינוי זמני ולהרכיב מחדש מבלי למחוק את הקומפילציה הקודמת
תוצאות. ללא מאגרים, תצטרך לשנות את ה-makefile שלך ​​כדי למקם את
חפצים במקומות אחרים.

עם מאגר, לעומת זאת, אינך צריך לגעת בקובץ ה-makefile שלך ​​כלל. קחו בחשבון את
רצף הפקודות הבא:

% cd my_program_source
% makepp # בונה באמצעות ה-makefile לעיל, ו
# קבצי אובייקט נכנסים לספרייה
# מקור_התוכנית_שלי.
% CD ..
% mkdir binary-debug # צור ספרייה נקייה לבניית ה
% cd binary-debug # אותה תוכנית עם אפשרויות שונות.
% makepp -R ../my_program_source CFLAGS=-g
# כעת אובייקטים נכנסים ל-binary-debug.

הפקודה הראשונה של 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" לא תיגע באף אחד מהקבצים שבהם
"מקור_התוכנית_שלי". לכן מאותה קבוצה של קבצי מקור, יש לך כעת שניים שונים
עותקים של התוכנית, אחד הידור עם אופטימיזציה ואחד הידור עבור ניפוי באגים. ו
זה קרה בלי לגעת בקובץ ה-makefile בכלל.

היתרון של שימוש במאגרים במקום פשוט להדר מחדש ולדרוס את
קבצים בינאריים מקוריים זה שעכשיו אם נתקן את הבאגים שלנו ונרצה לחזור לאופטימיזציה
גרסה, אנחנו לא צריכים להדר הכל מחדש. מאז קבצי האובייקט המקורי עדיין
מסביב, ורובם עדיין תקפים, אנו יכולים לחסוך זמן רב בהידור מחדש.
זה לא עושה הבדל גדול כאשר מדובר רק בשלושה קבצי מקור, אלא עבור א
בנייה גדולה יותר שלוקחת דקות או שעות להשלמתו, החיסכון בזמן המתכנת ו
תסכול יכול להיות משמעותי.

בונה מחדש אחד פילה עם a קטין שינוי ל מה היא קומפילציה פקודות

Makepp לא מביא רק קבצי מקור מהמאגר. אם קבצי האובייקט ב-
המאגר לא צריך בנייה מחדש, הוא ישתמש בהם. לדוגמה, שקול מעט
שינוי בקובץ ה-makefile שלמעלה:

CFLAGS := -O2
A_CFLAGS := -O6 -funroll-לולאות

אובייקטים := ao bo co

my_program: $(OBJECTS)
cc $(כניסות) -o $(פלט)

%.o: %.c
cc $(CFLAGS) -c $(קלט) -o $(פלט)

ao: ac
cc $(A_CFLAGS) -c $(קלט) -o $(פלט)

הרעיון הוא ש-"ao" מכיל את הקוד הקריטי לזמן, ולכן הוא מורכב עם גבוה יותר
אופטימיזציה מאשר שאר האובייקטים. עכשיו נניח שאנחנו רוצים לבדוק עד כמה שונה
התזמון הוא עם אפשרויות קומפילציה שונות. מאגר יכול לעזור גם בזה:

% cd my_program_source
% makepp # בונה באמצעות ה-makefile לעיל, ו
# קבצי אובייקט נכנסים לספרייה
# מקור_התוכנית_שלי.
% CD ..
% mkdir no-rolling # צור ספרייה נקייה לבניית ה
% cd ללא פתיחה של # אותה תוכנית עם אפשרויות שונות.
% makepp -R ../my_program_source A_CFLAGS=-O2
% CD ..
% time no-unrolling/my_program # סמן את שתי הגרסאות של התוכנית.
% time my_program_source/my_program

Makepp ממשיך כמו קודם, מקשר עותק של ה-makefile ואז בוחן את האובייקט
קבצים. כעת רק מודול "ao" צריך הידור מחדש, מכיוון שהאפשרויות עבור "bo" ו-"co"
לא השתנו. Makepp שם לב שהוא יכול להשתמש ב-"bo" ו-"co" מהמאגר, אז
זה רק מקשר את אלה פנימה. עם זאת, זה יקמפל מחדש את "ao" בספריית "ללא פתיחה".
לאחר סיום ההידור, שתי הגרסאות השונות של התוכנית יכולות להיות
מודד.

בונה מחדש עם a קטין שינוי ל מה היא מָקוֹר

כעת נניח שאנו רוצים לבצע שינוי ב-"ac" ולבדוק את התוכנית לפני ואחרי
השינוי. מאגרים יכולים לעזור שוב. שקול את רצף הפקודות הזה:

% mkdir modified-a
% cp my_program_source/ac modified-a
% cd modified-a
% 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 בספרייה היררכיה

מאגר הוא למעשה לא רק ספרייה בודדת, זה היררכיית ספריות שלמה.
נניח שאתה משתמש /שלנו/ספרייה כמאגר. עַכשָׁיו /שלנו/ספרייה עשוי בהחלט להכיל רבים
ספריות משנה, למשל, /שלנו/ספרייה/גאי ו /שלנו/ספרייה/רשת. שקול את הפקודה הזו:

% makepp -R /our/library

פקודות כלשהן ב-makefile המתייחסות לקבצים בספרייה ./רֶשֶׁת יהיה למעשה
לקבל קבצים מ /שלנו/ספרייה/רשת, ובדומה ל ./gui. Makepp באופן אוטומטי
יוצר כל ספריות שקיימות במאגר אך לא בספריה הנוכחית.

מקשר ל כל מקום in מה היא פילה מערכת

כל הדוגמאות לעיל מציגות קבצים ממאגר המקושרים אל הנוכחי
ספרייה או ספריות המשנה שלה, אבל למעשה אתה יכול לגרום ל-makepp לקשר אותן לכל מקום
במערכת הקבצים שיש לך גישת כתיבה אליה. זה נעשה על ידי ציון
"-R new-location=ישן-location".

לדוגמה, לפעמים זה קצת מייגע להקליד את הדברים הבאים:

mkdir-build חלופי
בניית תקליטור חלופית
makepp -R ..

אתה יכול לעשות הכל בפקודה אחת, כך:

makepp -R alternate-build=. -F חלופי בנייה

"-F" או "-makeppfile" משתנה בספרייה הזו לפני טעינת ה-makefile. אתה חייב
ציין "-R" לפני "-F". שימו לב שדוגמה זו מכניסה את עץ הבנייה החדש בתוך ה-
מאגר. זה לא יעבוד אם אתה משתמש ב-a RootMakeppfile כי Makepp אמצעי הגנה
נגד עצים מקוננים. זה גם לא רעיון טוב אם אתה משתמש **, כי אם אי פעם תבנה
במאגר הוא ימצא גם קבצים ערוכים ומופקים בתת-עץ זה.

הקצאת מיקום אחר במערכת הקבצים עשויה להיות שימושית גם עבור מסובכים יותר
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 test-build/seescape

פקודה זו נטענת בקבצים מארבעה מאגרים שונים, ולאחר מכן תקליטורים ל-
./test-build/seescape ספרייה ומבצע את הקובץ makefile שם. קבצים הכלולים ב-
עץ ספריות שמתחיל ב /src/seescape מקושרים לתוך ./test-build/seescape. ב
במילים אחרות, makepp יקשר את הקובץ באופן זמני /src/seescape/gui/image_canvas.cxx ל
./test-build/seescape/gui/image_canvas.cxx כאשר זה נחוץ. הפקודה הזו תעבוד אפילו
אם ספריית "test-build" עדיין לא קיימת; makepp תיצור אותו עבורך. (אבל אתה
חייב לציין את האפשרויות "-R" לפני האפשרות "-F" בשורת הפקודה.)

מְרוּבֶּה שווה מאגרים

נניח שהפרויקט שלך מתוחזק על ידי מספר קבוצות אוטונומיות למדי. אתה יכול לקבל אחד
מאגר שלם עם כל המקורות כפי שהם בייצור או לפחות
נבדק בהצלחה. לכל קבוצה יכולה להיות מאגר ריק ברובו עם (חלק מ) ה
אותו מבנה, המכיל את הקבצים שחברי הקבוצה סיימו לפתח.

בספריות הנוכחיות של המפתחים יהיו הקבצים שהם עדיין עובדים עליהם. הקבוצה
המאגר יהיה הראשון שניתן ומאגר הייצור האחרון, כך ש
הוא מספק את הקבצים שלא נמצאו במאגר הקבוצה:

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

מכיוון שזה כנראה סטטי למדי עבור אותה ספרייה, ייתכן שתרצה לשים קובץ
.makepprc בשורשו עם התוכן הבא:

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

לחלופין, בהנחה שיש לו נתיב קבוע, אתה יכול לכתוב בקובץ ה-makefile שלך:

מאגר /path/to/production/repository

ומכיוון שאפשרויות נראות לפני קריאת קבצי makefile, אתה יכול להתקשר רק

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

מאגרים as קבוע חלק of שֶׁלְךָ לִבנוֹת מערכת

אם אתה יודע שאתה תמיד משתמש במאגר כלשהו אתה יכול להשתמש ב"מאגר" או "vpath"
הצהרות בתיק שלך.

אזהרות עם מאגרים
מתי מה היא קישורים לקבל in מה היא דרך

להתמצאות בהיררכיית הקבצים שלך ולאפשר למאתר הבאגים למצוא את
מקורות כדאי להשתמש בקישורים בזמן הבנייה. אבל כאשר אתה רוצה לערוך א
קובץ או לסנכרן אותו מחדש עם בקרת הגירסה שלך, הקישורים יכולים להפריע. זה
כי המערכת עוברת את הקישור וכותבת לקובץ במאגר. אֶלָא אִם
זה המאגר האישי שלך המשמש רק להפרדת דברים, אולי זה לא מה שאתה
רוצה.

כהגנה מפני החלפה בשוגג של קבצים ציבוריים, מומלץ להפוך את
מקורות במאגר בלתי ניתנים לכתיבה. אולי אפילו לא יספיק להסיר את הכתיבה
קצת, בגלל מערכת בקרת גרסאות שמתעקשת לנעול את הקבצים לעריכה
עשוי גם לעשות זאת, אך הפוך את הקובץ לכתיבה באופן זמני תוך כדי סנכרון מחדש שלו. אם זה כן
במקרה שלך, המאגר צריך להיות שייך למעשה למשתמש אחר.

יש כמה טקטיקות להתגבר על זה:

· שמור את המקורות שאתה עורך במאגר, בנפרד מעץ הבנייה שלך. בְּכָל פַּעַם
אתה מכניס לתוכו קובץ, אשר הובא בעבר ממאגר אחר
מאגר עריכה, makepp ישים לב ויאחזר אותו משם, בתנאי שזה
המאגר הראשון שאתה מציין.

· זכור למחוק כל קובץ, לפני שאתה יוצר עותק לכתיבה. אם אתה עוקב אחר ה
הצעת הגנה לעיל, שכחת לעשות זאת תיתן הודעת שגיאה כאשר
כְּתִיבָה. כדי לעזור לך, הפונקציה הבאה "delink" תחליף קישור אחד בעותק
של הקובץ המקושר. הגרסה הראשונה מיועדת לכל מיני קונכיות בורניש, השנייה
אחד עבור csh (או לפחות tcsh):

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

· אם אתה מרגיש שאתה לא צריך אותם, אתה יכול למחוק את כולם, מתי שתרצה, למשל
לאחר כל ריצת מייקאפ, אולי רקע (בצורה קצרה או ארוכה):

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

לא לִבנוֹת in a מאגר בְּמַהֲלָך להשתמש

מאגר נועד להיות קריאה בלבד בזמן שהוא משמש כמאגר. Makepp יהיה
לֹא תעבוד כמו שצריך אם אתה משנה קבצים במאגר שלך במהלך הבנייה.
בנייה לילית עשויה להיות בסדר עבורך, אם אף אחד אחר לא משתמש במאגר באותו זמן. לפני
זה מתחיל את ה-build, makepp מקבל רשימה של כל הקבצים שקיימים במאגר, ו
לעולם לא מעדכן את הרשימה שלו, למעט קבצים שהוא מצפה להופיע.

אם אתה צריך מאגר שמשתנה תוך כדי בניית, אולי כדאי לך לשקול את זה של makepp
בניית מנגנון מטמון (ראה makepp_build_cache). לחלופין, אתה יכול להשתמש ב"מסכן
מאגר": אתה יכול להכניס כללים מפורשים לקובץ המייקאפ שלך כדי ליצור את הקישורים הרכים, כמו
זֶה:

%.c : $(directory_I_wish_was_a_repository)/%c
&ln -fs $(קלט) $(פלט)

זה עובד רק עבור קבצי מקור; אתה לא יכול להשתמש בזה בקלות כדי לקשר קובץ אם כן
כבר בנוי במאגר, אבל בנה אותו כאן אם הוא לא כבר בנוי, שכן שם
מותר להיות רק דרך אחת לבנות קובץ.

השתמש רק קרוב משפחה שמות קבצים

מאגרים עובדים בשקיפות מלאה if מה היא makefiles להשתמש רק קרוב משפחה שמות קבצים.
בדוגמה שלמעלה, זה בסדר אם ה-makefile נכנס /src/seescape מתייחס ../HLib, אבל
הפקודה לעיל לא תעבוד כצפוי אם היא מתייחסת /src/HLib. אם אתה צריך להשתמש
שמות קבצים מוחלטים, אתה יכול להכניס אותם למשתני make ואז לעקוף אותם ב-
שורת פקודה, כך:

% 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 ל-"test-build/seescape" לפני קריאת ה-makefile. זה מוביל ארוך ו
פקודות ביצוע מסובכות; השתמש בנתיבים יחסיים במידת האפשר.

Makepp צריך לדעת על את כל תלות

מאגרים לא יעבדו אם יש תלות נסתרות ש-makepp לא מכיר
על אודות. (למעשה, ביצוע בנייה באמצעות מאגרים, היא אחת הדרכים לבדוק אם נשכחו
תלות. אבל, רק בשביל הבדיקה הזו, אל תשלב אותו עם מטמון בנייה, שכן
להביא משהו לשם, במקום לבנות אותו, עלול להסתיר תלות נשכחת.)
לפעמים התלות הללו יכולה להיות עדינה למדי. לדוגמה, ה libtool צוואה בפקודה
לא רק ליצור קבצי ".lo" ו- ".la" כפי שמופיעים בשורת הפקודה, אלא זה גם עשוי
צור ספריית משנה בשם ".libs" המכילה את קבצי האובייקט בפועל. למנוע
לבנות טעויות, makepp מסרב לקשר בקובץ ".la" ממאגר. בתקווה פנימה
ה-libtool העתידי יהיה נתמך טוב יותר.

תלות נסתרת רבות הקשורות להידור נתפסות על ידי סורק שורת הפקודה.
אם המהדר שלך משתמש בדגלי ההידור הנפוצים של Unix (למשל, "-I", "-D" וכו'), אז
makepp בדרך כלל יגלה היכן נמצאים כל קבצי ה-include שלך. ייתכן שתצטרך להיות
זהירות אם יש לך סקריפטים מהבית שיוצרים קבצים ש-makepp לא מכיר
על אודות. לבנייה נכונה, חשוב מאוד לרשום את כל מטרות ותלות
(או לקבוע אותם באופן אוטומטי על ידי סריקה).

מכניס מוחלט שמות קבצים אל תוך תוכניות

מאגרים גם לא יעבדו אם אחד מהקבצים שנבנו מכיל שמות קבצים מוחלטים
אותם (למשל, אם כל אחת מפקודות ה-build שלך תכתוב שם קובץ מוחלט). לדוגמה,
מסתבר שקבצי ".la" שהופקו על ידי libtool יש את הנכס הזה. (אם אתה מסתכל על
את התוכן של קובץ ".la" תראה שרשימת התלות מכילה אבסולוט
שמות קבצים.) על מנת לפתור את הבעיה הספציפית הזו, makepp לא יקשר קבצי ".la".
ממאגר; הוא יתעקש לבנות אותם מחדש.

להמנע מְקַשֵׁר in מְיוּתָר ספריות

מאגרים יכולים להיות איטיים באתחול ולהשתמש בהרבה זיכרון אם יש הרבה
קבצים מיותרים במאגר. לדוגמה, אם אתה משתמש ב-HTML אוטומטי
מחולל תיעוד שיוצר אלפי קבצי ".html" מקוד המקור שלך, אתה
אולי לא רוצה לשים אותם בתיקיית משנה של ספרייה המשמשת כמאגר.
עדיף לשים אותם בעץ ספריות אחר לגמרי, אז המאגר
המנגנון לא ייטען בשמותיהם.

גם רב קבצים

החיסרון של מאגרים הוא כי קישורים סמליים, אשר מנגנון המאגר
שימושים, הם קבצים בודדים (אם כי הם אינם משתמשים כמעט בשטח דיסק). זה לא כמו אמיתי
קישורים, אבל אלה לא יכולים לחצות את גבולות מערכת הקבצים. במקרים קיצוניים נוכחות של
קישורים סמליים רבים מאוד יכולים להוביל למיצוי מספר הקבצים הצפוי (נקרא כך
inodes), למרות שנותר הרבה מקום. במקרה זה ה-sysadmin יצטרך
כדי לכוון את מערכת הקבצים.

מגבילים מאגר עותקים
אם תבצע שינויים כלשהם בקובץ באופן מקומי, makepp בדרך כלל יבין זאת ו
הידור מחדש של הקובץ באמצעות העותק המקומי במקום עותק המאגר.

אם אתה משתמש במאגר כדי לשמור על בסיס קוד מרכזי, ויש לך מפתחים
עובדים על עותקים מקומיים המכילים רק את הקבצים שהם שינו, בעיה אחת
עולה הוא: מה אם מפתח רוצה להסיר קובץ מהמבנה המקומי שלו אבל את
המאגר עדיין מכיל את זה? אם המפתח יסיר את העותק המקומי, makepp יסיר
הכנס בשמחה את העותק מהמאגר, והבנייה תתקדם כאילו הקובץ
היה קיים.

טכניקה אחת (אבוי לא לשורש המשתמש) לבעיה זו היא ליצור את הקובץ שאתה רוצה
לא לכלול בתהליך הבנייה בלתי קריא, כמו זה:

chmod a-rw קובץ שיש להחריג

זה ימנע מ-makep לשלב אותו מהמאגר. Makepp כולל גם
קוד מיוחד כך שקבצים בלתי קריאים אינם תואמים לתווים כלליים או לכללי דפוס.

באופן דומה, כדי למנוע מ-makepp לשלב ספריית משנה שלמה, צור מקומי
ספרייה בעלת אותו שם אך אינה ניתנת לכתיבה. אם אתה רוצה ש-makepp יתעלם
ספרייה כולה, ולאחר מכן הפוך גם אותה לבלתי ניתנת לקריאה. (מחפשים ספריות לקריאה בלבד אבל
מטרות בהן בדרך כלל אינן בנויות.)

הדרך האחרת לעשות זאת היא לקרוא ל-makepp עם אפשרות אי הכללה אחת או יותר:

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

לא להשתמש מאגרים ל קבצים אשר יכול שינוי!
אל תנסה להשתמש במאגר עבור קובץ שהוא חלק מה-build שלך. למשל, אתה
עלול להתפתות לנסות להשתמש במאגרים כדי לשים את כל קבצי ה-.h הציבוריים שלך באותו
ספרייה, כך:

# קובץ makefile ברמה העליונה
repository include=module1/include
repository include=module2/include
repository include=module3/include
repository include=module4/include

זה כנראה לא רעיון טוב אם כל של .h קבצים הם עצמם פלטים של a
תוכנית (למשל, yacc או תוכנה אחרת שיורקת קוד מקור C), כי makepp
מניח שקבצים במאגרים לעולם לא משתנים. אם המבנה צריך include/xyz.h, ו
module2/include/xyz.h למעשה צריך להפיק על ידי תוכנית כלשהי, makepp לא יידע
כדי להפעיל את התוכנית. עדיף להשתמש בטכניקה כזו כדי לשים את כל שלך .h קבצים
לתוך ספריית include נפוצה:

# module1/Makeppfile
../include/%.h : include/%.h
&cp $(קלט) $(פלט)
# תוכל גם (ביעילות רבה יותר אך בעייתית ב-Windows) לבצע את הפעולות הבאות:
# &ln -r $(קלט) $(פלט)

Makepp עדיין עשוי לנסות לבנות קבצים שנמצאים במקרה במאגר אם משהו יבקש
עבורם ישירות, אבל זה לא יבנה אותם on בשם של הספרייה המקומית. התוצאה
זה יכול להיות די מבלבל, כי זה יכול להוביל לקישור סמלי של מאגר
בשימוש כאשר יעד המאגר שלו אינו מעודכן, אך היעד הזה עשוי להתעדכן מאוחר יותר
בבנייה. אתה יכול למנוע את זה על ידי כך שתוודא כי
למאגר מתייחסים רק דרך נתיב המאגר, או על ידי לוודא שיש
הוא גם כלל מקומי עבור כל קבצי המאגר שנוצרו.

דרך נוספת להימנע מהידור מחדש של קבצים זהים בספריות שונות היא להשתמש ב-a
לבנות מטמון (ראה makepp_build_cache לפרטים). מטמון בנייה אין את
הגבלה לכך שהקובץ לא ישתנה.

השתמש ב-makepp_repositories באינטרנט באמצעות שירותי onworks.net