بنية الدليل لمكتبة C ++

Question

أنا أعمل على مكتبة C ++. في النهاية ، أود أن أتاحها للجمهور للمنصات المتعددة (Linux و Windows على الأقل) ، إلى جانب بعض الأمثلة و بيثون روابط. يتقدم العمل بشكل جيد ، ولكن في الوقت الحالي ، يكون المشروع فوضويًا تمامًا ، ومصمم فقط في Visual C ++ وليس متعدد المنصات على الإطلاق.

لذلك ، أشعر أن التنظيف في حالة جيدة. أول شيء أود تحسينه هو هيكل دليل المشروع. أرغب في إنشاء هيكل مناسب لـ السيارات الأدوات اللازمة للسماح بسهولة تجميع على منصات متعددة ، لكنني لم أستخدمها من قبل. نظرًا لأنني ما زلت أقوم (معظم) الترميز في Visual Studio ، سأحتاج إلى مكان للحفاظ على مشروع Visual Studio وملفات الحلول أيضًا.

حاولت Google لمصطلحات مثل "بنية دليل مكتبة C ++" ، لكن لا شيء مفيد يبدو أنه يظهر. لقد وجدت بعض الإرشادات الأساسية للغاية ، ولكن لا توجد حلول واضحة.

أثناء النظر إلى بعض مكتبات المصادر المفتوحة ، توصلت إلى ما يلي:

\mylib
    \mylib <source files, read somewhere to avoid 'src' directory>
        \include? or just mix .cpp and .h
    \bin <compiled examples, where to put the sources?>
    \python <Python bindings stuff>
    \lib <compiled library>
    \projects <VC++ project files, .sln goes in project root?>
    \include? 
    README
    AUTHORS
    ...

لديّ خبرة سابقة قليلة مع مشاريع تطوير/المصادر المفتوحة متعددة المنصات ، وأنا مندهش تمامًا من أنني لا أستطيع العثور على أي إرشادات جيدة حول كيفية تنظيم مثل هذا المشروع.

كيف يجب أن يقوم أحدهم عمومًا ببنية مشروع المكتبة؟ ما هو CA لقراءة؟ هل هناك بعض الأمثلة الجيدة؟

Answer 1

شيء واحد شائع جدًا بين مكتبات UNIX هو أنها منظمة مثل:

./         Makefile and configure scripts.
./src      General sources
./include  Header files that expose the public interface and are to be installed
./lib      Library build directory
./bin      Tools build directory
./tools    Tools sources
./test     Test suites that should be run during a `make test`

يعكس إلى حد ما نظام ملفات UNIX التقليدي تحت /usr أين:

/usr/src      Sometimes contains sources for installed programs
/usr/include  Default include directory
/usr/lib      Standard library install path
/usr/share/projectname   Contains files specific to the project.

بالطبع ، قد ينتهي هذه في نهاية المطاف /usr/local (وهو بادئة التثبيت الافتراضية لـ GNU AutoconF) ، وقد لا تلتزم بهذا الهيكل على الإطلاق.

لا توجد قاعدة صعبة وصعبة. أنا شخصياً لا أقوم بتنظيم الأشياء بهذه الطريقة. (أتجنب استخدام أ ./src/ دليل على الإطلاق باستثناء أكبر المشاريع ، على سبيل المثال. أنا أيضًا لا أستخدم Autotools ، مفضلاً بدلاً من ذلك cmake.)

اقتراحي لك هو أنه يجب عليك اختيار تخطيط دليل منطقي بالنسبة لك (وفريقك). افعل كل ما هو أكثر منطقية لبيئة التطوير التي اخترتها وأدوات البناء والتحكم في المصدر.

Answer 2

لا أعتقد أن هناك بالفعل أي إرشادات جيدة لهذا الغرض. معظمها مجرد تفضيل شخصي. ستحدد بعض IDE هيكلًا أساسيًا لك. Visual Studio ، على سبيل المثال ، سيقوم بإنشاء مجلد بن منفصل ينقسم في تصحيح وإصدار المجلدات الفرعية. في VS ، هذا منطقي عند تجميع الكود الخاص بك باستخدام أهداف مختلفة. (وضع التصحيح ، وضع الإصدار.)

كما يقول Greyfade ، استخدم تصميمًا منطقيًا لك. إذا كان شخص آخر لا يحب ذلك ، فسيتعين عليهم إعادة هيكلةه بأنفسهم. لحسن الحظ ، سيكون معظم المستخدمين سعداء بالهيكل الذي اخترته. (ما لم يكن فوضويًا حقيقيًا.)

Answer 3

أجد مكتبة WXWidgets (المصدر المفتوح) مثالًا جيدًا. إنهم يدعمون العديد من المنصات المختلفة (Win32 و Mac OS X و Linux و FreeBSD و Solaris و Wince ...) والمترجمين (MSVC ، GCC ، Codewarrior ، Watcom ، إلخ). يمكنك رؤية تخطيط الشجرة هنا:

https://svn.wxwidgets.org/svn/wx/wxwidgets/trunk/

Answer 4

هناك هذه الاتفاقية الرائعة التي صادفتها مؤخرًا والتي قد تكون مفيدة: تخطيط Pitchfork (أيضا على جيثب).

لتلخيص القسم الفرعي 1.3 ينص علي:

يصف PFL العديد من الدلائل التي يجب أن تظهر في جذر شجرة المشروع. ليست كل الدلائل مطلوبة ، ولكن لديها غرض مخصص ، ولا يوجد دليل آخر في نظام الملفات قد يتحمل دور إحدى هذه الدلائل. أي أن هذه الدلائل يجب أن تكون المستخدمة إذا كان الغرض مطلوبًا.

لا ينبغي أن تظهر الدلائل الأخرى في الجذر.

build/: دليل خاص لا ينبغي اعتباره جزءًا من مصدر المشروع. تستخدم لتخزين نتائج البناء سريعة الزوال. يجب عدم فحصها في التحكم في المصدر. في حالة استخدام التحكم في المصدر ، يجب تجاهله باستخدام قوائم تجاهل التحكم في المصدر.

src/: موقع المصدر الرئيسي القابل للتجميع. يجب أن تكون حاضرة للمشاريع ذات المكونات المترجمة التي لا تستخدم النسيجية الفرعية. في حضور include/, ، يحتوي أيضا على رؤوس خاصة.

include/: دليل للرؤوس العامة. قد تكون موجودة. قد يتم حذفها للمشاريع التي لا تميز بين الرؤوس الخاصة/العامة. قد يتم حذفها للمشاريع التي تستخدم علامات فرعية.

tests/: دليل للاختبارات.

examples/: دليل للعينات والأمثلة.

external/: دليل الحزم/المشاريع التي يتعين استخدامها من قبل المشروع ، ولكن لم يتم تحريرها كجزء من المشروع.

extras/: دليل يحتوي على علامات فرعية إضافية/اختيارية للمشروع.

data/: دليل يحتوي على جوانب رمز غير المصدر للمشروع. قد يشمل ذلك الرسومات وملفات الترميز.

tools/: الدليل الذي يحتوي

docs/: دليل لوثائق المشروع.

libs/: دليل للفيروسات الفرعية للمشروع الرئيسي.

بالإضافة إلى ذلك ، أعتقد extras/ الدليل هو المكان الذي ترتبط فيه بيثون يجب الذهاب.

Answer 5

أستطيع أن أوصيك حقًا باستخدام CMake ... إنه من أجل تطوير النظام الأساسي المتقاطع ، وهو أكثر مرونة بكثير من أن Automake ، استخدم Cmake وستتمكن من كتابة رمز النظام الأساسي عبر بنية direcory الخاصة بك على جميع الأنظمة.