מאמרים בנושא ‏‏CMake‏‏.

אם מישהו יגיד לי כמה CMake נפלא וכמה autotools גרוע אני...

ב־יום ראשון, 6 ביוני 2010, מאת ארתיום; פורסם תחת: תכנה חופשית, פיתוח, תכנה ומחשבים, ‏CMake‏; ‏2 תגובות

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

היום סוף סוף הבנתי מה הבעיה ועוד פעם, כמה אני שונא CMake.

"למזלי", התקנתי שלשום CMake 2.8.1 מקוד מקור, כדי לדבג בעיה קומפיליצה ששברה את הבניה שלי (שעבדה יפה עם 2.6, אגב גם באג או ליתר דיוק שינוי מדיניות).

אז נתחיל בקצרה:

זה פלט של הפקודה בעבודה עם CMake 2.6

$ grep application.h CMakeFiles/cppcms.dir/depend.make
CMakeFiles/cppcms.dir/src/application.cpp.o: /usr/include/cppcms/application.h
CMakeFiles/cppcms.dir/src/applications_pool.cpp.o: /usr/include/cppcms/application.h
CMakeFiles/cppcms.dir/src/http_context.cpp.o: /usr/include/cppcms/application.h
CMakeFiles/cppcms.dir/src/internal_file_server.cpp.o: /usr/include/cppcms/application.h
CMakeFiles/cppcms.dir/src/rpc_json.cpp.o: /usr/include/cppcms/application.h
CMakeFiles/cppcms.dir/src/service.cpp.o: /usr/include/cppcms/application.h
CMakeFiles/cppcms.dir/src/url_dispatcher.cpp.o: /usr/include/cppcms/application.h

וזה פלט של אותה פקודה לגמרה בעבודה עם CMake 2.8

$ grep application.h CMakeFiles/cppcms.dir/depend.make
CMakeFiles/cppcms.dir/src/application.cpp.o: ../cppcms/application.h
CMakeFiles/cppcms.dir/src/applications_pool.cpp.o: ../cppcms/application.h
CMakeFiles/cppcms.dir/src/http_context.cpp.o: ../cppcms/application.h
CMakeFiles/cppcms.dir/src/internal_file_server.cpp.o: ../cppcms/application.h
CMakeFiles/cppcms.dir/src/rpc_json.cpp.o: ../cppcms/application.h
CMakeFiles/cppcms.dir/src/service.cpp.o: ../cppcms/application.h
CMakeFiles/cppcms.dir/src/url_dispatcher.cpp.o: ../cppcms/application.h

ההבדל ברור? אם לא, אני אסביר.

למרות שדגלוני הקומפיילר אומרים באופן מפורש להסתכל בתיקיה ".." "בודק התלויות" של CMake (במרכאות כפולות ומכופלות) מתעקש להסתכל על ספריות המערכת למרות שזה לא נכון בעליל.

האמת? אני לא מבין כיצד KDE אימצו כלי כזה? אני מבין שיש ל־CMake לא מעט יתרונות, רק שהבעיה שאני יותר נלחם בו מאשר נעזר בו. האם תמיכה ב־MSVC שווה את זה?

אגב, autotools משתמש בקומפיילר עצמו כדי לבנות תלויות כך שהתלויות יוצאות מדויקות לגמרי.

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

נ.ב.: ik_5, אפילו אל תגיב... אני יודע מראש מה אתה תרצה לומר

נפלאות התמיכה בחלונות או מדוע CMake לא בדיוק מערכת הבניה איכותית.

ב־יום שלישי, 26 בינואר 2010, מאת ארתיום; פורסם תחת: לינוקס, פיתוח, תכנה ומחשבים, ‏CMake‏; ‏0 תגובות

פרסמתי מאמר Why CMake sucks... (once more)‎ בבלוג שלי באנגלית.

מומלץ לקריאה לכל אלו שאוהבים CMake ושונאים auto*‎.

קצת רקע לאנשים שלא רגילים לעולם חלונות: בחלונות לא עושים linking ישירות מול dll אלא תמיד מול import-library מיוחדת שיודעת לעשות טעינה ל־dll. כך שאם בלינוקס בד"כ כל ספריה באה בגרסאות: דינאמית וסטטית, בחלונות (כולל mingw ו־cygwin) כל ספריה באה בגרסאות: דינאמית, ספריית import לספריה דינאמית וגרסה סטטית.

עכשיו תקראו את המאמר ותיהנו ;-).

לטובת מפתחי CMake ייאמר: אחרי שדיווחתי על הבאג הם עדכנו את הויקי שלהם כדי להמנע מהבעיה הזו.

למה להמציא גלגל מחדש זה לא תמיד עובד טוב

ב־יום חמישי, 12 בנובמבר 2009, מאת ארתיום; פורסם תחת: תכנה חופשית, פיתוח, תכנה ומחשבים, C++‎‏, ‏CMake‏; ‏8 תגובות

לאחרונה אני מנסה להגר ל־CMake מ־autotools בפרויקט CppCMS בעיקר כדי להבטיח תמיכה טובה יותר בסביבת Windows ובפרט ב־MSVC מתישהו בעתיד.

עשיתי כבר הרבה עובדה והענף הניסיוני עבר ל־CMake. אפילו לא מעט אנשים ברשימת התפוצה התלהבו מהעובדה שהמערכת תעבוד על CMake... רבים חוץ ממני. אחרי שהתחלתי לעבוד אתה בצורה יותר עניינית הבנתי: היא באמת יותר מוצלחת בפיתוח ל־Windows מאשר autotools בעיקר בגלל שהיא קצת יותר גמישה בנושא ה־exports וכמובן התמיכה ב־MSVC.

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

המהירות שאנשי CMake מתלהבים ממנה זאת גם עקב אכילס שלה. יש לזה מספר נקודות:

  1. ב־autotools הייתה הפרדה ברורה בין automake שמגדיר את מבנה הפרויקט לבין autoconf שמגדיר את קונפיגורציית הפלטפורמה. מצד אחד זה היה קצת מפריע אבל מצד שני זה היה מאוד נוח: הוספת קובץ חדש לא פרויקט לא דרשה הרצת configure מחדש מצד אחד, מצד שני כל שינוי בצורת הקונפיגורציה ביצע הרצת configure שלמה.

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

    מצד שני, אם אני מוחק CMakeCache ומעדכן את CMakeLists.txt הוא לא זוכר את הפרטרים המקורים שהרצתי אתו את cmake כמו "איפה נמצאות הספריות או איזו אופציה שאני העברתי"

  2. מנגנון מעקב אחרי התלויות של CMake לא בודק את הקובץ config.h משמע... אם עשיתי שינויים בקונפיגורציה הקוד לא ייבנה מחדש. צריך להריץ make clean ו־make שוב! העיקר שיש להם cache חזק.

הרבה מגנונים הקיימים לוקים בחסר או לא מתוכננים היבט. לדוגמה:

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

  2. בדיקת sizeof היא בכלל פנינת CMake. יש לה מספר בעיות:

    • היא נעשית ע"י הרצת קוד מה שאומר היא לא תעבוד בקרוס־קומפילציה. כאשר ב־autotools עושים טריק מאוד יפה המאפשר לבצע בדיקה כזו ללא הרצת קוד אלא קומפילציה בלבד.
    • היא לא מאפשרת להוסיף header כך שלא ניתן לבדוק sizeof של טיפוסים הנמצאים ב־includes לא סטנדרטיים.
  3. אין פונקציונליות דומה ל־AC_ARG_ENABLE המאפשרת להציג רשימת הפרמטרים לקונפיגורציה והערות לגביהם -- קרי אין כלי כמו ‎./configure --help שמאוד עוזר בהרבה מקרים.

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

אני מקווה שיום אחד autotools ידעו לתמוך גם ב־MSVC בסה"כ זה לא אמור להיות מי יודע מה מסובך... ICU משתמשים ב־autotools יחד עם MSVC בצורה מוצלחת למידי (למעשה הבעיה היא אפילו לא automake ו־autoconf הם דווקא איכשהו עובדים עם הקומפיילר, (הוא מסתבר כן תומך בהרבה דגלונים הרגילים כמו "‎-o -I" ועוד) הבעיה היא בעיקר libtool.

במילים אחרות... אם אתם לא מתכוונים לתמוך ב־MSVC תתרחקו מ־CMake, אבל ממש תתרחקו ממנו.

עוד כמה מפלאי ה־CMake

ב־יום שלישי, 18 בנובמבר 2008, מאת ארתיום; פורסם תחת: תכנה חופשית, פיתוח, תכנה ומחשבים, ‏CMake‏; ‏0 תגובות

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

  1. Makefile הרגיל, הישן והלא כל־כך טוב.
  2. תסריטי autotools המוכנים מראש.
  3. תסריטי CMake.

אחת הנקודות שהייתי צריך לבדוק אותה, זאת תמיכה ב־gettext, שזה אומר:

  1. בניה אוטומטית של קבצי pot עבור התרגום בעזרת xgettext.‏
  2. עדכון קבצי po של התרגומים הקיימים (מיזוג עם שינויים בתכנה)
  3. בניה והתקנה אוטומטית של קבצי mo מקבצי po.

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

אז, האם יש לכם חשק להחליף auto(hell)tools ב־CMake. לי לא כל־כך.

Autotools - קשה איתם, אבל אי אפשר בלעדיהם.

ב־יום חמישי, 3 ביולי 2008, מאת ארתיום; פורסם תחת: תכנה חופשית, פיתוח, תכנה ומחשבים, ‏CMake‏; ‏14 תגובות

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

./configure
make
make install

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

אבל, אם זה כלי כל־כך חזק, למה כל־כך רבים שונאים אותו?

המשך...

העמוד הבא

דפים

נושאים