على سبيل المثال ، إذا كنت تستخدم دائمًا التحويل البرمجي لمشروعك باستخدام cargo build --target=thumbv6m-none-eabi
. تتيح لك هذه الميزة إضافة زوج قيمة مفتاح إلى ملف تكوين الشحن الخاص بك:
# .cargo/config
[target]
default = "thumbv6m-none-eabi"
سيتيح لك ذلك ببساطة استدعاء cargo build
لتجميع مشروعك مقابل thumbv6m-none-eabi
. قد يمتد هذا أيضًا إلى cargo doc
.
ذكرت في الأصل هنا .
يبدو هذا معقولًا جدًا بالنسبة لي ، على الرغم من أنني قد أذهب إلى حد القول بأنه يجب أن يكون في Cargo.toml لأنه من المحتمل أن يكون شيئًا لكل مشروع _إذا كان شيئًا نبدأ به.
أحد الجوانب السلبية لجعله إعدادًا للمشروع هو أنه سيتم دائمًا تجاهل الإعداد للتبعيات. مثال: إذا كان مشروعي P يعتمد على الصندوق D وقد قام D بتعيين T كهدف افتراضي ، فسيتم تجاهل هذا الإعداد دائمًا لأن D سيتم تجميعه دائمًا للهدف الذي أختاره لـ P.
تتمثل إحدى ميزات استخدام .cargo / config في أنه إذا قمت بتطوير عدة صناديق محليًا ، فيمكنني الحصول على إعداد مثل هذا:
$ tree .
my-RTOS-project
├── .cargo
│ └── config
├── allocator
│ └── (...)
├── hal
│ └── (...)
├── RusTOS
│ └── (...)
└── scheduler
└── (...)
ويمكنني القفز من دليل قفص إلى آخر وتشغيل cargo test
. في مرحلة ما ، يمكنني تحرير سطر واحد في .cargo / config والبدء في اختبار الصناديق الخاصة بي لهدف مختلف.
اها نعم فعلا! يقع هذا إلى حد ما ضمن اختصاص https://github.com/rust-lang/cargo/issues/2122 حيث لا ينبغي أن يكون هذا جانبًا سلبيًا ، ولكن لا يزال هناك بعض أعمال التصميم التي يجب القيام بها هناك أيضًا.
التعليق الأكثر فائدة
يبدو هذا معقولًا جدًا بالنسبة لي ، على الرغم من أنني قد أذهب إلى حد القول بأنه يجب أن يكون في Cargo.toml لأنه من المحتمل أن يكون شيئًا لكل مشروع _إذا كان شيئًا نبدأ به.