הבלוג של ארתיום
בלוג על לינוקס, תוכנה חופשית, מוזיקה, סלסה, ומה לא!
Autotools - קשה איתם, אבל אי אפשר בלעדיהם.
אחד הכלים השנואים ביותר ע"י המפתחים בעולם Unix זה autotools. מצד שני, זה גם הכלי הנוח ביותר עבור משתמשים שהתקנת תוכנה כלשהי מסתכמת בהרצת שלוש בפקודות
./configure
make
make install
במה מדובר? מדובר בכלי שמאפשר: בנייה, הפצה, בדיקה, התקנה, הסרה, קונפיגורציה של תכנה, ספריות, תיעוד בפלטרפורמות מרובות בצורה אוטומטית. נשמע מפוצץ? וזה אכן הדבר. נכון להיום זה אחד הכלים החזקים שקיימים בתחום *nix.
אבל, אם זה כלי כל־כך חזק, למה כל־כך רבים שונאים אותו?
התשובה היא: חבילת autotools היא מאוד מורכבת וסוחבת אתה הרבה שאריות היסטוריות. יש לה הרבה כוח, אבל כדי לנצל אותו צריך לקרוא וללמוד הרבה. הרחבה של היכולות שלה יכולה להיות מאוד קשה וניתן ליפול בפח בקלות.
כשמדובר במשהו יחסית סטנדרטי כמו יצירת ספריה או יצירת תכנה עם כמה תלויות זה מאוד פשוט. כשזה מגיע למשהו לא סטנדרטי, זה הופך להיות די קשה לעבוד עם autotools להבין כיצד לשלב רכיבים שונים ועוד. למעשה, גורם העיקרי לכך שכתבתי את הפוסט היה מכתב ברשימת דיור של soci על הפסקת תמיכה ב־autotools בגלל שזה כלי מאוד מורכב. במקום זה נכתב סקריפט tcl שנועד לבניית הספריה, שראוי לציין, פשוט לא עבד לי.
הבעיה הגדולה השנייה של autotools (מעבר למורכבות שלו) היא חוסר תמיכה בפלטפורמת Windows. מה שגורם לכך, שתכנות שמתכוונות לתמוך ב־VS חייבות לספק רכיב התקנה ובניה חילופי.
נכון להיום קיימים מספר תחליפים פופולריים ל־autotools. כאשר cmake הוא הידוע בהם, ש־KDE החל מגרסה 4 עברה להשתמש בו כתחליף ל־autotools. שפותר את הבעיה האחרונה, אבל... יש אבל גדול.
נכון להיום, לא קיימת מערכת בניה, הפצה, התקנה וניהול יותר מלאה ובשלה מאשר autotools. למשל, cmake לא תומך בכמה דברים שהם מאוד בסיסיים ב־autotools.
- אין תמיכה מובנית בהסרת תוכנה.
- אין הבניה פשוטה וישירה של גרסאות סטטיות ודינמיות של הספריות.
- תיעוד לוקה בחסר.
- ברירת המחדל לא מספיק טובות (בניית גרסת debug ללא אופטימיזציה כברירת מחדל).
אפשר להמשיך את הרשימה. למעשה, עד היום לא נוצר כלי מספיק בשל כדי להחליף את autotools הישן ו(לא כל־כך) טוב. אני עובד עם autotools הרבה זמן וממליץ לכל אחד שמעוניין בפיתוח תחת לינוקס להכיר אותו. הוא עושה את החיים של משתמשים, אורזי החבילות וגם של המפתחים הרבה יותר קלים. הכלי הזה אינו מושלם, אבל לצערי זה הדבר הטוב ביותר שיש בידינו; ואני חושב שיעבור הרבה זמן עד שייווצר כלי מספיק בשל, כדי ש־autotools יוכלו לפרוש לגמלאות מכובדת.
תגובות
Die! Autohell! Die!
אני החלטתי להעביר את הפרוייקטים שלי ל-cmake. זה מתקדם לאיטו אבל CMake פשוט עובד במקום ה-Autoconf שגורם למספר רב של אזהרות, וכן מדי פעם נשבר לחלוטין כי הם לא מסוגלים לשמור על תאימות לאחורה כמו שצריך. לא פעם בתור משתמש - מי שניסה להתקין את התוכנה - הייתי צריך לשחק ידנית עם משתני הסביבה או לשנות את קובץ ה-./configure המסובך לאללה, כך שגם עבור המשתמש Autohell הוא לא טלית שכולה תכלת.
ברור של-cmake שהוא הנדוס-מחדש של Autoconf תהיינה מספר בעיות. אבל זה צפוי בכל כלי כמעט, כולל דברים שאני ואתה כתבתנו. אבל, הוא עדיין טוב בהרבה מ-autohell, ואני מאמין שאפשר להתגבר על הבעיות שלי. לא אכפת יהיה לי לתרום ל-CMake כדי לשפר אותו, כי זה יחסוך לטווח הארוך כאב ראש רב עם Autoconf וחבר בני-הבליעל שלו.
אם תסלח לי, ארתיום אבל נראה לי שאתה טיפוס מאוד "שמרן" שלא מבין מדוע דברים חדשים ו/או עיליים הם יותר טובים. אתה לא רוצה להשתמש ב-Perl/Python וכו' מכיוון שהן עלולות להיות מהירות פחות מ-C++. אפילו .NET זה לא מספיק טוב בשבילך. אתה טוען שאין צורך בספריות אבסטרקציה כמו glib או APR משום ש-POSIX מספיק טוב. (אף שפעמים רבות הן נותנות פונקציות עיליות שמקלות על העבודה השוטפת). ואפילו חשבת במקור להשתמש ב-BDB במקום במשהו מבוסס SQL שכאמור יהיה נוח בהרבה.
אם כל הכבוד, כרגע הבעייה היא לא שתוכנות זוללות זכרון או לא מהירות מספיק מכיוון שמחשב ה-Pentium 4 הישן שאני משתמש בו כרגע יכול להריץ מספר רב של סימולציות של PDP-11, שעליו פותח במקור היוניקס המקורי, כל אחת במהירות רבה בהרבה ממה שאחת כזאת רצה (והסימולטורים כתובים גם הם בשפת C שהיא פחות אופטימלית). אני זוכר שהרצנו תסריטי CGI של פרל (לא mod_perl) בנוחות על מחשב Pentium-133 MHz ועל SGI Challenge ישן מאוד. כרגע צוואר הבקבוק הוא הזמן של המתכנתים שאין מספיק ממנו ומהם.
כאמור, הכל במידה. ספריה אחת שכתבתי, כתובה ב-ANSI C ועושה שימוש רק ב-libc. אולם במקרה שלה, המהירות הייתה קריטית, והעדפתי להמציא מחדש גלגלים מינימילסטיים ומאוד אופטימליים מאשר להשתמש בספריות קיימות שהן יותר גנריות ואיטיות ממה שאני כתבתי.
( כרגע הכל כתוב פחות או יותר ב-C89 ואילו הייתה לי האפשרות לעבור ל-C99 או להשתמש ב-gcc extensions הייתי עושה זאת בשמחה. אני אראה מה קורה עם gcc עבור win64 לפני שאני מחליט. )
בכל מקרה, מערכת ניהול תוכן דינמית היא משהו שדורש גמישות, קלות התקנה, ונוחות, והמהירות פחות חשובה בה. ניסיתי להתקין את CppCMS ו-Autoconf צעק עליי באחת התלויות הרבות, אז התייאשתי.
קודם כל וואו...
ובכן נתחיל:
ברור לי שעתיד הוא לא autoconf, אבל כרגע אין לו תחליפים ראויים לשמם. מצטער... אם אני צריך לכתוב 20-30 שורת רק כדי לעשות uninstall -- הפעולה בסיסית ביותר, אז מצטער cmake עדיין לא בשל. אני מאוד מקווה שהוא יהיה ואז אפשר יהיה לשלוח אותו לגמלאות מוכבדת.
אני בהחלט מקווה שיום אחד אני אוכל להגיד... יש תחליף ל־autohell אבל כיום אין. אפשר להעמיד פנים, אפשר לצעוק, אפשר להתלונן אפשר לכתוב סקריפטים משלך. אבל כשזה מגיע למציאות, אין לו תחליף.
כמה נקודות. אני חושב שהשם CppCMS מטעה -- זה לא Content Managment System כמו למשל Drupal, זה framework לפיתוח ל־web כמו Django. לגבי התלויות הרבות. כמה אתה חושב תלויות יש ל־Frameworks דומים אחרים? אתה שוכח שהרבה תלויות באות עם השפות הדימניות. והן לא באות בחינם. בסה"כ כל הכלים זמינים ממאגרי Debian וכתבתי במפורש בהוראות מה צריך להתקין.
מצד שני, אמרת autoconf צעק עליך? וטוב שכך, עדיף שמה שהיה צועק זה gcc שמתלונן על header חסר?
שלומי
אני חושב שצריך לקחת דברים בפרופורציות נכונות. לכל דבר יש יתרון וחסרון... מה שכן, צריך להכיר אותם ולהיות מודע לבעיות.
אני חושב שאתה צריך למצוא מהדר נורמלי ל־Windows של C. זה ש־MS זרקו תמיכה ב־C99 בכלל ואין קומפיילר סביר עבורו של Windows אז זו בעיה שלהם. בסה"כ אני לא מפתח ל־win32 וגם לא ממש מתכוון.
Die win32api die
יצא לך לבדוק תחליפי make מבוססי שפות דינאמיות?
יש את rake (רובי) ו scons (פייתון) שיחסית ותיקים בשוק. בנוסף, משום מה יש עכשיו פריחה כללית של תחליפי make מבוססי פיתון: zc.buildout, Vellum, Paver
אני לא יודע האם זה נכון לדרוש ממשתמשים להתקין Python/Rubi + את החבילה המתאימה בשביל לקמפל תוכנה של ++C, וגם אין לי ניסיון עם אף אחד מהפרוייקטים, אבל סביר להניח שתוכל למצוא בהם מערכות נוחות יותר מאשר AutoTools כיוון שאלו מערכות שנבנו על לקחי autotools וכמו כן תוכל להשתמש בכח של השפה שמאחורי הפרוייקט בשביל להקל על העבודה.
הי ארתיום!
תגובה לעניין. לדעתי uninstall זה יותר מה שמנהל החבילות צריך לעשות, ולא מה שתוכנה צריכה לעשות. אני תמיד מתקין בעזרת --prefix שבו הסרה היא פעולה פשוטה של rm -fr.
אני כרגע מתכוון לעבור ל-CMake ואם אתקל בבבעיות מיוחדות עימו, אז פשוט אתקן אותן שם, במקום להתעסק יותר מדי עם Autoconf. נתקלתי בלא מעט בעיות בספריות או בממשקים בהם הייתי תלוי ופתרתי אותן משום שהן היו קוד פתוח ופרוייקטים דמויי-בזאר וקיבלו ברצון את התרומות שלי. כך את התרומות שלי ל- XML-RSS כמקרה קיצוני. זה הכוח של קוד פתוח.
ייתכן שעדיין יש הצדקה להשתמש ב-autoconf במקום באלטרנטיבות המודרניות יותר שלו, אבל אני עדיין חושב ש-CMake הוא עם הכל יותר טוב, ומאמין שהוא מהווה נקודת התחלה יותר טובה.
בקשר ל-CppCMS - לא הצלחתי למצוא את כל התלויות במאגרים של מנדריבה קוקר, שהינם מאוד מקיפים אף הם. לא כל העולם משתמש בדביאן. אני מודה שגם ל-Latemp יש לא מעט תלויות, אך אני וידאתי שאני יכול לבנות אותה גם על cygwin (!).
אמן! גם אני לא סובל את חלונות ואת ממשק המתכנת הגועלי שלו. אבל מה לעשות שאנשים רבים עדיין משתמשים בו. אני מאמין שחלונות תמות בסוף (לא מיקרוסופט - מאוד ייתכן שהיא תשרוד), אבל כמו כמעט כל דבר מת בעולם התוכנה, עדיין ימשיכו להשתמש בה. רק לסבר את האוזן, עדיין משתמשים ב-PDP-11, PDP-10, VAX, DOS, NetWare, IRIX, OS/2, שלא לדבר על תוכנות ישנות שאבד עליהן הכלח שעדיין רצות מעל מערכות הפעלה מודרניות.
כך שימשיכו עדיין להריץ חלונות בכל מיני מקומות שונים כבר זמן רב.
במקרה שלא שמת לב, הספריה שאני כתבתי (והתחילה כתוכנית של שורת הפקודה) מיועדת למציאת פתרונות אוטומטיים של משחקי קלפים. מרבית השחקנים המשחקים במשחקים אלה עדיין לא עברו לחלונות, כולל חלק מהמומחים הגדולים בתחום. אם לא אוודא שהקוד שלי ירוץ שם הרי שאאבד את מרבית שוק-המשתמשים הפוטנציאלי שלי.
מרבית מפתחי הקוד הפתוח עדיין רוצים שמשתמשי חלונות ישתמשו בתוכנות שכתבו, מסיבות רבות שאוכל להרחיב עליהן במידת הצורך, אך אני חושב שלא צריך. מערכת ההפעלה VMS, שאתה לפעמים מדבר בשבחה, ידועה כגורמת הצרות הגדולה ביותר בעולם הפרל (אפילו יותר מחלונות) אבל עדיין יש כאלה שמנסים לדאוג שתוכנות הפרל שלהם תעבודנה שם, פשוט משום שיש לפרל שם ביקוש ואנשים תלויים בזה.
אני אישית הצלחתי לאחרונה לכתוב תסריטי בדיקה בפרל שרצו מצוין על כל מערכות הלינוקס ונכשלו בכל המערכות מבוססות ה-BSD. הסיבה לכך הייתה שבניתי מסלול שהיה ארוך באופן מלאכותי והיה יותר גדול מ-1024 בתים (שהוא הגבול של BSD) ופחות ארוך מ-4096 בתים, שהוא המגבלה של לינוקס.
כך שזה לא קשה לכתוב קוד שלא יהיה פורטבילי גם בין היוניקסים האולטרה-מודרניים והעדכניים ביותר.
טוב, דבר ראשון, בשם יש בעייה של קידוד כפול, לפחות בקונקורר 3.5.9.
תשובה לעידו: הסתכלתי על SCons ולא התלהבתי - הוא דורש ממך להמציא גלגלים רבים שקיימים כבר ב-Autoconf (וב-CMake) מחדש עם יותר מדי לוגיקה שצריך לכתוב ידנית. יש לו הרחבות רבות, אבל אין משהו רשמי. הוא גם מאוד איטי, ולא מפריד בין התצורה לבנייה עצמה כמו ./configure ו-make.
לא הסתכלתי על rake עדיין. לא חסרים עכשיו כלי-בנייה ותצורה וקשה לדעת מה לבחור. כרגע לי עושה רושם ש-CMake הוא הכי טוב. הייתי מעדיף אילו היה כתוב בפרל או בפייתון במקום ב-c++, אבל כרגע הוא עובד מצוין, וגם הרשיון שלו (modBSD אם אני זוכר נכון) הוא מצוין.
כן, ל־CppCMS יש תלויות. אבל את הרוב ניתן להתקין ללא בעיות מיוחדות (אפילו ב־cygwin)
החבילות העיקריות הן: boost, cgicc ו־libdbi. כל השאר (fastcgi ו־libmm) הן אופציונליות כל השאר אמור להיות די נפוץ. הדבר הכי "אקזוטי" זה libdbi, אבל אם אתה לא משתמש ב־dbixx אלא ספריה משלך עבור MySQL או בסיס הנתונים שלך אין שום בעיה. בסה"כ dbixx זה מעטפת נוחה שמאפשרת עבודה מול מס' sqlים.
מוזר, צריך לבדוק כי בסה"כ אני בודק הכל בכל הדפדפנים ולא נתקלתי. מוזר. אולי שינית קידוד באופן ידני או משהו כזה?
אני משבח? אני סובל ממנה ביום־יום. מה שכן, יש להם קומפיילר שתומך ב־C99 וגם תאימות שלהם ל־posix הרבה יותר גבוהה (לפחות ב־8.3) בהשוואה ל־windows. הבעיה העיקרית שלהם זה שמות של קבצים ומערכת קבצים.
שורה תחתונה
אני לא אומר ש־autotools זה הכלי הנוח והיעיל ביותר אבל עדיין הוא כלי שמאפשר לעשות את העבודה. אני רוצה שיום אחד הוא יוחלף במשהו יותר מודרני אבל חזק כמהו.
בינתיים, אני משתמש בו ;)
אולי תנסה להציע למשתמש מה צריך להתקין?
הנה נסיון ראשוני שלי:
http://updates.xorcom.com/astribank/bristuff/bristuff-current/prereq.sh
מה להתקין? כמה הפצות לינוקס עיקריות קיימות: debian, ubuntu, rhel, fedora, suse, mandriva, arch, gentoo
מה עם טעמי BSD? יש OpenBSD, FreeBSD, PC BSD, NetBSD
מה עם גרסאות Solaris, HP-UX? מה עם cygwin...
בדיוק בשביל זה יש הוראות שאומרות אני צריך ספריה XYZ ואני סומך על המשתמש שמקמפל תכנה לדעת להתקין את התלויות בכוחות עצמו.
אני אבדוק את התלויות בעזרת autotools ואני אוודא שבהוראות כתובים הסברים מדויקים. "כלים" כאלה לא בדיוק יעזרו כי תמיד יש חבילות מחוץ להפצה.
למשל, RHEL בא ללא cgicc וגם ללא libdbi? אפשר להתקין אותן בקלות אבל עדיין אין דרך לעשות את זה דרך מנהל החבילות. לכן, אני לא חושב שזה פתרון.
לדוגמה: מהי הספריה "termcap"?
אני לא מצפה ממך לבדוק בכל המקרים. זה מיועד לחסוך לך תשובות לשאלות. כמובן שאתה צריך לסמוך על משתמשי גנטו שיעדכנו את הוראות ההתקנה להפצה שלהם וכך לגבי כל הפצה / מערכת הפעלה אחרת.
אם החבילות הללו לא זמינות דרך מנהל החבילות, לא מתקינים.
אני עדיין מנסה לחשוב איך לשלב עם autoconf (כדי לדעת מה המשתמש רצה לבנות).
צודק, שחזרתי את הבעיה בקונקי -- ב־FF/Opera/IE זה עובד רק בקונקי לא.
פתחתי באג, תודה
בואו נגיד ככה: כשמשתמש מתקין דרך קוד מקור סביר להניח שהוא יודע כיצד להשיג ספריות ולקמפל אותן.
אם לא, כדאי שישקול אם בכלל צריך לבצע התקנה של התכנה מקוד מקור.
פשוט אפשר לרשום בהודעה של "כשלון" את השמות של החבילות האופייניות. למשל, עבור debian תתקין libabc-dev עבור RHEL תקין dev-abc ועוד.
בדברים כאלה אין פתרונות קסם
תודה! בינתיים אני משתמש בתעתיק האנגלי של השם שלי.
הי ארתיום!
בנוגע למה שכתבת שאין דרך נוחה ליצור גרסאות סטאטיות ודינמיות של אותה ספריה, אז בזכות Risko Gergely, מתחזק החבילה של Freecell Solver בדביאן, מצאתי דרך לא מסובכת לבצע את זה. לפרטים נוספים חפש ADD_LIBRARY בקובץ ה-CMakeLists.txt של הקוד של הפותר
זה אומנם דורש לבנות את האובייקטים של שתי הגרסאות של הספריות פעמיים, אבל זה יותר טוב מכלום, ולפיתוח שוטף ניתן להסתפק רק בגרסה אחת.
אני לא אומר שזה מסובך... זה פשוט לא שקוף. עם autotools, מבחינתך אתה בונה ספריה, הפלטפורמה כבר דואגת להכל, כיצד לבנות, שמות ועוד.
תשים לב, שגם עם autotools הספריה תיבנה פעמיים, כי גרסה דינאמית דורשת דגלונים כמו -fPIC או -DDLL_BUILD, לתוי בפלטפרומה... רק שב־autotools זה הרבה יותר שקוף.
הוסף תגובה:
חובה לאפשר JavaScript כדי להגיב.