सीसी: @nico @chaoren

सीएमके में, अंक 16675 , अंक 13894 और एमआर 520 में प्रासंगिक चर्चा है।

वर्कअराउंड के रूप में आप ऑब्जेक्ट आउटपुट निर्देशिका को स्पष्ट रूप से सेट कर सकते हैं, यहां तक ​​कि "।" या "..", लेकिन निरपेक्ष पथ भी काम करता है।
ninjatst.bash.txt

@zlolik IIUC आप बिल्ड मेनिफेस्ट ( build.ninja ) ग्राफ नोड्स में पूर्ण पथ रखने का सुझाव देते हैं। निश्चित रूप से यह काम करता है (और सीएमके आउट-ऑफ-सोर्स बिल्ड में करता है), लेकिन मेरा मुद्दा यह है कि निंजा पूर्ण पथों के उपयोग को हतोत्साहित करता है और फिर भी आईडीई को आउटपुट में उनकी आवश्यकता होती है।

यह भी काल्पनिक रूप से संभव है कि -c foo.c दिया गया एक कंपाइलर वैसे भी डिफाइल में एक पूर्ण पथ उत्पन्न कर सकता है। अगर ऐसा होता है तो निंजा यहां बताई गई इसी समस्या के कारण निर्भरता को नहीं पहचान पाएगा।

इसे ठीक करने के लिए निंजा को यह पहचानने में सक्षम होने की आवश्यकता होगी जब एक सापेक्ष पथ और पूर्ण पथ एक ही फ़ाइल हो और आंतरिक रूप से दो के बजाय केवल एक ग्राफ़ नोड हो। केवल डीपाइल प्रोसेसिंग के लिए ऐसा करना पर्याप्त हो सकता है, क्योंकि build.ninja जेनरेटर को बिल्ड मेनिफेस्ट के भीतर लगातार पथ नाम देने के लिए कहना उचित है।

@bradking सबसे पहले, मैं आपसे सहमत हूं कि हमें निंजा के साथ कोई समस्या है और मैं केवल समाधान का सुझाव देता हूं।
मुझे लगता है कि 3 जुड़े मुद्दे हैं:

1. इनपुट निरपेक्ष/सापेक्ष पथ के साथ तर्क, #1152 में अधिक विवरण।
2. आउटपुट निरपेक्ष/सापेक्ष पथ को बाध्य करने के लिए तर्क। कंपाइलर्स के साथ समस्या - कंपाइलर को यह कहने का एकमात्र तरीका है कि आप आउटपुट में पूर्ण पथ रखना चाहते हैं, कमांड लाइन में पूर्ण पथ का उपयोग करें। निंजा मुद्दा नहीं बल्कि हमारा।
3. निरपेक्ष/सापेक्ष पथ को पार्स करने के लिए तर्क। इस मुद्दे।

मैं 2 कामकाज का उपयोग करता हूं:

1. पहली 2 समस्याओं को हल करने के लिए build.ninja जनरेटर के पथ में उपसर्ग $p और $o का उपयोग करें। मेरे मामले में $p और $o पूर्ण नहीं हैं, लेकिन वर्तमान डीआईआर से संबंधित हैं जहां build.ninja जनरेटर चलाया गया था।
2. डेपफाइल को निंजा संगत पथ में बदलने के लिए कुछ स्क्रिप्ट का उपयोग करें। कुछ कंपाइलरों को भी डिफाइल उत्पन्न करने के लिए अलग कॉल की आवश्यकता होती है। लेकिन कोई पूर्ण पथ समस्या नहीं है।

संदर्भ के लिए, मैंने प्रस्तावित समाधान के साथ ninja-build मेलिंग सूची पर एक थ्रेड शुरू किया है।

डिबग और कवरेज जानकारी के बारे में अन्य संबंधित मुद्दे: सापेक्ष पथों के साथ कमांड का उपयोग करने से संबंधित पथों के साथ डिबग सूचना फ़ाइलें भी बनती हैं। समस्या यह है कि डिबग फाइलें आमतौर पर ऑब्जेक्ट फाइलों के बगल में रखी जाती हैं, स्रोत फाइलों के पास नहीं, इसलिए वहां के सापेक्ष पथ गैर-मौजूदा फाइलों का संदर्भ देते हैं।

इस पर किसी भी अद्यतन? मेलिंग सूची थ्रेड पर कोई प्रतिक्रिया नहीं आई है...

सभी को नमस्कार,

यह भी काल्पनिक रूप से संभव है कि -c foo.c दिया गया एक कंपाइलर वैसे भी डिफाइल में एक पूर्ण पथ उत्पन्न कर सकता है।

IAR v8 की निर्भरता फ़ाइलों में केवल पूर्ण पथ होते हैं।

सीएमके/निंजा/आईएआर के साथ आउट-ऑफ-सोर्स बिल्ड करते समय हमने इस समस्या को मारा है: सीएमके के बाइनरी डीआईआर में समाप्त होने वाली जेनरेट की गई फाइलें निंजा मेनिफेस्ट में सापेक्ष हैं, आईएआर द्वारा डीपीएस आउटपुट पूर्ण हैं।

मेरे लिए, यह स्पष्ट रूप से एक निंजा-मुद्दा है: इसमें एक ही फ़ाइल के लिए दो नोड्स नहीं होने चाहिए, चाहे कुछ भी हो।

मैंने @bradking के सुझाव को पढ़ा है, लेकिन मैं वास्तव में प्रतीकात्मक लिंक के बारे में समझ नहीं पा रहा हूं और getcwd() का उपयोग क्यों नहीं किया जा सकता है। क्या आप विस्तृत करना चाहेंगे?

मैं प्रतीकात्मक लिंक के बारे में वास्तव में समझ नहीं पा रहा हूं और क्यों getcwd() का उपयोग नहीं किया जा सकता

@sebknzl समस्या यह है कि जेनरेटर द्वारा build.ninja को लिखे गए पूर्ण पथ में प्रतीकात्मक लिंक हो सकते हैं जिन्हें जानबूझकर एक कारण या किसी अन्य कारण से हल नहीं किया जाता है। getcwd() आम तौर पर हल किए गए सिम्लिंक के साथ एक पथ देता है। यदि निंजा को बिल्ड मेनिफेस्ट में एक सापेक्ष पथ या getcwd() के सापेक्ष एक डिफाइल की व्याख्या करनी थी, तो यह जो पूर्ण पथ बनाता है वह बिल्ड मेनिफेस्ट जेनरेटर से मेल नहीं खा सकता है और हम अभी भी दो नोड्स के साथ समाप्त हो जाएंगे।

ninja_workdir मैं आपके द्वारा लिंक किए गए धागे में प्रस्तावित करता हूं मूल रूप से निंजा को बता रहा है कि जेनरेटर सापेक्ष पथ के लिए आधार के रूप में क्या उपयोग करता है। व्यवहार में realpath(ninja_workdir) == realpath(getcwd()) हमेशा सत्य होना चाहिए, लेकिन इसका मतलब ninja_workdir == getcwd() नहीं है। एक अन्य विकल्प निंजा के लिए नोड्स बनाने से पहले realpath सब कुछ होगा, लेकिन इसका मतलब यह होगा कि $in जेनरेटर के इरादे से विस्तारित नहीं होगा।

@jhasse कृपया इस मुद्दे और इसे संबोधित करने के मेरे प्रस्ताव को देखें।

CMAKE_NINJA_GENERATOR_OPTION_ द्वारा नियंत्रित पूर्ण पथों के साथ _build.ninja_ क्यों नहीं उत्पन्न करें?

यानी इस तरह, जो काम करता है:

Claus-MBP:build clausklein$ cat build.ninja 

# project dir
p = /Users/clausklein/Downloads
# object dir
o = /Users/clausklein/Downloads/.ninjatst.build

rule cp
  command = cp $in $out

rule cc
  depfile = $out.d
  deps = gcc
  command = cc -I$o -c $in -o $out -MD -MT $out -MF $out.d

# All absolute paths works
build all: phony $o/foo.o

# All absolute paths works
build $o/foo.h: cp $p/foo.h.in
  IN = $p/foo.h.in

# All absolute paths works
build $o/foo.o: cc $p/foo.c || $o/foo.h
  IN = "$p/foo.c"

default all

Claus-MBP:build clausklein$ 

ninjatst.bash.txt . के साथ उत्पन्न

@ क्लॉसक्लेन हमने सीएमके को पूर्ण पथ का उपयोग करने के लिए सिखाने का प्रयास किया। मेरे द्वारा लिंक की गई चर्चाओं को https://github.com/ninja-build/ninja/issues/1251#issuecomment -282322776 में देखें। मैं इसके बजाय एक विकल्प नहीं जोड़ूंगा जो कहता है "चीजों को अलग तरीके से करें जो कुछ मामलों को ठीक करता है और दूसरों को तोड़ देता है"।

इसे ठीक से ठीक करने के लिए हमें वास्तव में https://github.com/ninja-build/ninja/issues/1251#issuecomment -487618865 में लिंक किए गए प्रस्ताव में निंजा सुविधा की आवश्यकता है।

अच्छी बात है

तो क्या यह मेसनबिल्ड सिस्टम के लिए भी उपलब्ध होगा ;-)

पूर्वाह्न 12.03.2020 उम 12:56 श्राइब ब्रैड किंग नोटिफिकेशन @github.com:

@ClausKlein https://github.com/ClausKlein हमने सीएमके को निरपेक्ष पथों का उपयोग करने के लिए सिखाने की कोशिश की। उन चर्चाओं को देखें जिन्हें मैंने #1251 (टिप्पणी) https://github.com/ninja-build/ninja/issues/1251#issuecomment-282322776 में लिंक किया है। मैं इसके बजाय एक विकल्प नहीं जोड़ूंगा जो कहता है "चीजों को अलग तरीके से करें जो कुछ मामलों को ठीक करता है और दूसरों को तोड़ देता है"।

इसे ठीक से ठीक करने के लिए हमें वास्तव में #1251 (टिप्पणी) https://github.com/ninja-build/ninja/issues/1251#issuecomment-487618865 में लिंक किए गए प्रस्ताव में निंजा सुविधा की आवश्यकता है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub https://github.com/ninja-build/ninja/issues/1251#issuecomment-598146822 पर देखें, या https://github.com/notifications/unsubscribe-auth/AAN7QWWEDHMDA45DQVPLOUDRHDEVDANCNFSM4DBNL6GA को अनसब्सक्राइब करें।

मान लीजिए कि निन्जा ninja_workdir का उपयोग डीपफाइल जानकारी के मिलान के लिए करेगा और हमारे पास ऐसी स्थिति है जहां एक सिमलिंक के कारण ninja_workdir != getcwd() है। क्या होगा यदि संकलक अब getcwd() का उपयोग करके पूर्ण पथ प्रिंट करता है?

कंपाइलर को किसी भी चीज़ के लिए getcwd() का उपयोग नहीं करना चाहिए जब तक कि उन चीजों को सापेक्ष पथ के रूप में पारित नहीं किया जाता है, इस मामले में बिल्ड सिस्टम जनरेटर को जिम्मेदारी लेने की आवश्यकता होती है।

या हम ninja_workdir और getcwd() दोनों को wrt को सामान्य करने का प्रयास करने पर विचार कर सकते हैं।

ठीक है, सापेक्ष पथ दिए जाने पर संकलक को डिफाइल में एक पूर्ण पथ वापस नहीं करना चाहिए ;)

@ क्लॉसक्लेन हमने सीएमके को पूर्ण पथ का उपयोग करने के लिए सिखाने का प्रयास किया। #1251 (टिप्पणी) में मेरे द्वारा लिंक की गई चर्चाएँ देखें। मैं इसके बजाय एक विकल्प नहीं जोड़ूंगा जो कहता है "चीजों को अलग तरीके से करें जो कुछ मामलों को ठीक करता है और दूसरों को तोड़ देता है"।

जब आपने @ClausKlein द्वारा सुझाए गए पूर्ण पथों का उपयोग किया तो वास्तव में क्या टूट गया?

यदि कंपाइलर को निरपेक्ष पथ दिया जाता है तो उसके द्वारा उत्पन्न किए गए डेपफाइल में पूर्ण पथ होते हैं, और वे बिल्ड मेनिफेस्ट में हेडर के सापेक्ष पथ से मेल नहीं खाते हैं, उदाहरण के लिए जेनरेट किए गए हेडर के लिए। इस मुद्दे के शीर्ष पर मेरी पहली पोस्ट में ninja-bug.bash.txt लिंक देखें। यह क्या होता है इसका एक चरण-दर-चरण उदाहरण दिखाता है और पूरी तरह से निंजा और सीएमके के संदर्भ में व्यक्त किया जाता है।

मैंने इसे पढ़ लिया है, लेकिन क्यों न https://github.com/ninja-build/ninja/issues/1251#issuecomment -284533599 का उपयोग करें? सिर्फ इसलिए कि निंजा पूर्ण पथ को "निराश" करता है? यदि हां, तो यह दस्तावेज़ीकरण परिवर्तन के बारे में है?

build.ninja फ़ाइलें हर जगह निरपेक्ष पथों को दोहराए बिना बहुत छोटी होती हैं, और यह उन्हें तेज़ बनाती हैं। वे अच्छे भी दिखते हैं, डिबग करना आसान होता है, और गोले में लक्ष्य नामों के निर्माण के टैब-पूर्ण होने के लिए अधिक उपयुक्त होते हैं। आईएमओ निंजा के लिए यह एक अच्छी सिफारिश है। निंजा को इस मामले को सुलझाने के लिए बस थोड़ी और जानकारी की जरूरत है, और यही मैं प्रस्तावित करता हूं।

@bradking सापेक्ष पथ हमेशा छोटा नहीं हो सकता है:

build jsoncpp@sha/src_lib_json_json_reader.cpp.o: cpp_COMPILER ../../../../../Users/clausklein/Workspace/cpp/jsoncpp/src/lib_json/json_reader.cpp
 DEPFILE = jsoncpp@sha/src_lib_json_json_reader.cpp.o.d
 ARGS = -Ijsoncpp<strong i="7">@sha</strong> -I. -I../../../../../Users/clausklein/Workspace/cpp/jsoncpp -I../../../../../Users/clausklein/Workspace/cpp/jsoncpp/include -I../../../../../Users/clausklein/Workspace/cpp/jsoncpp/dir1 -I../../../../../Users/clausklein/Workspace/cpp/jsoncpp/dir2 -fdiagnostics-color=always -pipe -Wall -Winvalid-pch -Wnon-virtual-dtor -std=c++17 -O3

मेरा उदाहरण https://github.com/ninja-build/ninja/issues/1251#issuecomment -597877775 अच्छा लग रहा है!

सीएमके के जनरेटर के पास ../ अनुक्रमों का उपयोग न करने के बारे में एक नियम है जो बिल्ड ट्री को छोड़ देता है। पूरी तरह से आउट-ऑफ-सोर्स बिल्ड में हम सोर्स ट्री के लिए निरपेक्ष पथ और बिल्ड ट्री के सापेक्ष पथ का उपयोग करते हैं। उत्तरार्द्ध कभी भी ../ में शुरू नहीं होते हैं क्योंकि वे बिल्ड ट्री के नीचे होते हैं।

मुझे पता है, यह _mesonbuild_ के साथ उत्पन्न हुआ था। ;-)

लेकिन, क्यों न पीढ़ी को स्रोत वृक्ष में नकार दिया जाए?

हम हमेशा के लिए सापेक्ष बनाम पूर्ण पथ के गुणों पर बहस कर सकते हैं। निंजा को इसके बारे में राय नहीं दी जानी चाहिए। यहां समस्या उन मामलों को समेटने की है जहां दोनों का उपयोग एक ही निर्माण में किया जाता है। बिल्डसिस्टम जनरेटर हमेशा यह नियंत्रित नहीं कर सकता कि उपकरण पथ के साथ क्या करेंगे। निंजा को एक ही फ़ाइल में मिश्रित पूर्ण/सापेक्ष पथ का समर्थन करना चाहिए और मेरे प्रस्ताव में उल्लिखित एक सरल दृष्टिकोण के साथ ऐसा कर सकता है। प्रेरक उपयोग के मामले में परिवर्तन को डिफाइल पार्सिंग के लिए अलग किया गया है।

निंजा को एक ही फ़ाइल में मिश्रित पूर्ण/सापेक्ष पथ का समर्थन करना चाहिए

मैं सहमत हूँ!

सभी स्पष्टीकरणों के लिए धन्यवाद, मैं समझना शुरू कर रहा हूं।

क्या होगा अगर निन्जा (डीपफाइल में एक पूर्ण पथ का सामना करने पर) सीडब्ल्यूडी और उसे मिले पथ दोनों को वास्तविक रूप देगा? फिर यह रीयलपैथेड सीडब्ल्यूडी को रीयलपैथेड डिफाइल-पथ से हटा देगा ताकि जेनरेट किए गए हेडर के साथ मिलान करने के लिए सापेक्ष पथ प्राप्त हो सके। क्या इससे काम हो जायेगा?

getcwd() हमेशा पहले से ही एक वास्तविक पथ है ताकि कदम आवश्यक न हो। यदि निन्जा realpath() के लिए डिफाइल-प्रदत्त पूर्ण पथ था और एक cwd उपसर्ग की जांच करें जो काम कर सके। हालांकि, realpath() एक संभावित-महंगा सिस्कल है, जबकि मेरा प्रस्तावित ninja_workdir स्ट्रिंग प्रोसेसिंग के माध्यम से पूरी तरह से स्मृति में पथों को समेट सकता है।

दूसरी दिशा में मिश्रण की भी अनुमति दी जानी चाहिए: बिल्ड मेनिफेस्ट में एक पूर्ण पथ लेकिन डिफाइल में एक सापेक्ष पथ। मुझे नहीं लगता कि realpath() को पार्स करते समय निंजा को $# build.ninja realpath() हर पूर्ण पथ होना चाहिए। यह शायद धीमा होगा।

हम वर्कडिर को निर्धारित करने के लिए परिणाम का उपयोग कर सकते हैं। जैसे:

getcwd (): /var/xyz/build
डेपफाइल प्रविष्टि: /home/foo/build/bar.h
realpath(depfile entry): /var/xyz/build/bar.h
सापेक्ष वास्तविक पथ: bar.h
इसे depfile प्रविष्टि से हटा दें: /home/foo/build -> ninja_workdir

इस तरह हमें केवल एक बार realpath को कॉल करने की आवश्यकता है।

मुझे नहीं लगता कि सामान्य रूप से ninja_workdir स्वचालित रूप से प्राप्त करना संभव है। हम कैसे जानते हैं कि मूल सिम्लिंक युक्त तार्किक पथ के कितने तार्किक घटक वर्कडिर से मेल खाते हैं? हम एक समय में एक घटक लेकर ऐसा करने में सक्षम हो सकते हैं जब तक कि इसका वास्तविक पथ cwd से मेल नहीं खाता, लेकिन यह हैकी और त्रुटि प्रवण लगता है। इस तरह दिखने वाले पहले सिम्लिंक पर भरोसा करना जोखिम भरा लगता है। इसके अलावा, जब तक कोई इस तरह से हल नहीं करता है, तब तक हमें हर पूर्ण पथ पर realpath() चलाना होगा।

बिल्डसिस्टम जेनरेटर जानता है कि build.ninja में बिल्ड स्टेटमेंट और कमांड लाइन में निरपेक्ष पथ उत्पन्न करते समय वर्कडिर के लिए कौन सा तार्किक पथ उपयोग किया जाता है। इसलिए यह वर्कदिर पथ के लिए सूचना का सबसे विश्वसनीय स्रोत है। हमें बस इस जानकारी को निन्जा तक पहुंचाने के लिए एक तरीके की आवश्यकता है, इसलिए मेरा प्रस्तावित ninja_workdir बाध्यकारी है।

मुझे यकीन नहीं है कि मैं समझता हूं, क्षमा करें। क्या आप एक उदाहरण दे सकते हैं जहां मेरा पता लगाने का तर्क काम नहीं करेगा?

यह टूट सकता है अगर बिल्डसिस्टम जनरेटर बिल्ड ट्री के अंदर एक सिम्लिंक डालता है (बिल्ड ट्री में या पूरी तरह से बाहर की ओर इशारा करते हुए):

getcwd (): /var/xyz/build
डेपफाइल प्रविष्टि: /home/foo/build/subdir-link/bar.h
realpath(depfile entry): /var/xyz/build/subdir-real/bar.h
सापेक्ष वास्तविक पथ: subdir-real/bar.h
इसे डिफाइल एंट्री से हटा दें: ???

सीएमके ऐसा नहीं करता है लेकिन आम तौर पर एक बिल्ड सिस्टम जनरेटर कर सकता है।

भले ही हम यह कहने को तैयार हों कि यह समर्थित नहीं है, फिर भी पता लगाने का सामना करना पड़ सकता है:

getcwd (): /var/xyz/build
1000 डीपाइल प्रविष्टियां: /home/foo/ext-lib/bar{1,2,...}.h
1000 वास्तविकपथ(डीपाइल प्रविष्टियां): /var/xyz/ext-lib/bar{1,2,...}.h
1000 सापेक्ष वास्तविक पथ: cwd के अंतर्गत कोई नहीं

अब कल्पना कीजिए कि यह 1000 स्रोतों की अशुद्धियों में प्रकट होता है और कभी भी हिट नहीं होता है। वह 1 मिलियन realpath() कॉल है जिसका इस अनुमानी के लिए कोई मिलान नहीं है। और यह हर बार एक स्रोत के पुनर्निर्माण और उसके डीपफाइल को फिर से पार्स किए जाने पर दोहराता है।

बिल्ड ट्री के अंदर सिम्लिंक -> हाँ, हम वास्तव में इसका समर्थन नहीं कर सकते हैं, इसके परिणामस्वरूप सभी प्रकार के अन्य मुद्दे वैसे भी होंगे (बिना किसी वास्तविक स्थान के)।

दूसरा उदाहरण बल्कि कृत्रिम लगता है। आम तौर पर डिफाइल स्थानीय निर्भरता से शुरू होते हैं, सिस्टम हेडर के साथ नहीं।

यदि यह वास्तव में एक प्रदर्शन समस्या बन जाती है, तो हम वर्कडिर को .ninja_deps में कैश कर सकते हैं?

आउट-ऑफ-सोर्स बिल्ड में बहुत कम डिफाइल प्रविष्टियां बिल्ड ट्री पर भी इंगित करेंगी। यह बहुत आम होगा:

getcwd (): /var/xyz/build
1000 डीपाइल प्रविष्टियाँ: /home/foo/project-source/bar{1,2,...}.h
1000 वास्तविकपथ(डीपाइल प्रविष्टियां): /var/xyz/project-source/bar{1,2,...}.h
1000 सापेक्ष वास्तविक पथ: cwd के अंतर्गत कोई नहीं

निंजा को उन सभी पर realpath() पर कॉल करना होगा, या वास्तविक सिस्को से बचने के लिए परिणामों की किसी प्रकार की तालिका बनाए रखना होगा। यह समय से पहले नहीं जान सकता है कि यह एक सिम्लिंक पथ का सामना करेगा जो सीडब्ल्यूडी को हल करता है, और यह भी नहीं जानता कि यह एक मिल जाएगा या नहीं।

यह देखते हुए कि वर्तमान में डेपफाइल में पूर्ण और वास्तविक पथ मिश्रण काम नहीं करता है, मुझे नहीं लगता कि यह "बहुत आम" कैसे होगा ??

सिम्लिंक या मिश्रित पथों का उपयोग न करने पर भी मेरे उदाहरण में फॉर्म के डिफाइल पहले से ही बहुत आम हैं। मेरे पास मेरे अधिकांश निर्माण पेड़ों में है। निंजा समय से पहले नहीं जान सकता है कि अनुमानी की आवश्यकता है या नहीं, इसलिए इसे realpath() syscalls पर केवल मामले में ब्लॉक करना होगा।

शायद मैंने आपके उदाहरण को गलत समझा। क्या आपका मतलब 3000 प्रविष्टियों के साथ एक depfile है या 300 प्रविष्टियों के साथ depfiles के लिए वे 3 अलग-अलग उदाहरण थे?

मेरा मतलब था कि 1000 depfile प्रविष्टियाँ किसी भी संख्या में depfiles में फैली हुई हैं। यह एक हो सकता है। यह कई हो सकते हैं। एक परियोजना में 10000 प्रविष्टियाँ हो सकती हैं। उनके पथ फाइल सिस्टम पर कहीं भी इंगित कर सकते हैं और वास्तव में बिल्ड ट्री में इंगित कर सकते हैं या नहीं भी कर सकते हैं।

क्या आप एक उदाहरण CMakeLists.txt दे सकते हैं जिसके परिणामस्वरूप पथों का ऐसा मिश्रण होता है (1000 होना जरूरी नहीं है, प्रत्येक में से केवल एक)?

CMakeLists.txt फ़ाइल में दिखाना मुश्किल है क्योंकि सीएमके वर्तमान में ज्यादातर मामलों में मिश्रण पथ से बचने का ख्याल रखता है। हालांकि, सीएमके के इश्यू ट्रैकर में उन समस्याओं के बारे में समस्याएं हैं जिन्हें पहले निंजा इसे ठीक किए बिना ठीक नहीं किया जा सकता है। उदाहरण के लिए देखें सीएमके अंक 13894 । उपयोगकर्ता बिल्ड ट्री में या इन-सोर्स बिल्ड करते समय स्रोतों (और शायद निर्देशिकाओं को शामिल करें) के लिए भी कंपाइलर को पूर्ण पथ देने में सक्षम होना चाहते हैं। यह सीएमके के मेकफ़ाइल जेनरेटर के साथ ठीक काम करता है। अगर हम निंजा के साथ ऐसा करते हैं तो डेफाइल्स पूर्ण पथ के साथ वापस आते हैं और वे सापेक्ष पथ से मेल नहीं खाते build.ninja । हो सकता है कि हम हर चीज के लिए पूर्ण पथ पर स्विच कर सकें, लेकिन जैसा कि यहां ऊपर चर्चा की गई है, हमें ऐसा नहीं करना चाहिए।

शायद आप इसे परीक्षण के लिए आजमा सकते हैं https://github.com/ClausKlein/build-performance/commit/8013836486e3a459474eb374f6c3da5e20983443

यहां दिखाई गई समस्या https://github.com/ninja-build/ninja/issues/1251#issue -210080507 पर आधारित है
यह उतना ही लक्ष्य उत्पन्न करता है जितना आप चाहते हैं। यानी 2 सबड्यूअर्स प्रत्येक में 2 सोर्स फाइल्स हैं:

PWD=/Users/clausklein/Workspace/build-performance/build

rule cp
  command = cp $in $out

rule cc
  depfile = $out.d
  deps = gcc
  command = gcc -c -I$PWD $IN -o $out $FLAGS -MMD -MT $out -MF $out.d

rule link
  command = gcc -o $out $in $LINK_PATH $LINK_LIBRARIES

build foo: phony foo.h
build foo.h: cp foo.h.in

build bin/main0.o: cc /Users/clausklein/Workspace/build-performance/build/subdir0/main.c || foo.h
  IN = /Users/clausklein/Workspace/build-performance/build/subdir0/main.c
build /Users/clausklein/Workspace/build-performance/build/subdir0/file0.o: cc /Users/clausklein/Workspace/build-performance/build/subdir0/file0.c || foo.h
  IN = /Users/clausklein/Workspace/build-performance/build/subdir0/file0.c

build bin/main1.o: cc /Users/clausklein/Workspace/build-performance/build/subdir1/main.c || foo.h
  IN = /Users/clausklein/Workspace/build-performance/build/subdir1/main.c
build /Users/clausklein/Workspace/build-performance/build/subdir1/file0.o: cc /Users/clausklein/Workspace/build-performance/build/subdir1/file0.c || foo.h
  IN = /Users/clausklein/Workspace/build-performance/build/subdir1/file0.c

build bin/main0: link bin/main0.o /Users/clausklein/Workspace/build-performance/build/subdir0/file0.o 
build bin/main1: link bin/main1.o /Users/clausklein/Workspace/build-performance/build/subdir1/file0.o 

build all: phony foo bin/main0 bin/main1 
default all

यह सीएमके के मेकफ़ाइल जेनरेटर के साथ ठीक काम करता है।

मेक सिम्लिंक मुद्दे को कैसे संभालता है?

मेक सिम्लिंक मुद्दे को कैसे संभालता है?

मेकफ़ाइल जनरेटर वर्तमान में डेपफाइल्स का उपयोग नहीं कर रहा है और अपनी अनुमानित स्कैनिंग करता है। मेकफ़ाइल जेनरेटर में सी ++ 20 मॉड्यूल समर्थन जोड़ने के हिस्से के रूप में इसे अपडेट किया जाएगा, जिस बिंदु पर डिफाइल पथों की व्याख्या को यहां प्रस्तावित के समान ही समेटना होगा।

एक विकल्प अभी के लिए ninja_workdir को छोड़ना है और कम से कम निंजा को मिश्रित रास्तों को समेटना सिखाना है, यह मानते हुए कि getcwd() सबसे ऊपर है। इस तरह कम से कम मिश्रित पथ सामान्य नो-सिमलिंक मामले में काम करेंगे। फिर बाद में अधिक जटिल मामलों का समर्थन करने के लिए ninja_workdir को जोड़ा जा सकता है।

कृपया कोई इसे ठीक करे। मैं इस वजह से बहुत नाराज हूं।

मैं सीएमके और वीएससीओडी के साथ एआरएम-जीसीसी का उपयोग कर रहा हूं। जब मैं इन-सोर्स बिल्ड का उपयोग करता हूं, तो पथ "बिल्ड" निर्देशिका (रूट निर्देशिका के बजाय) के सापेक्ष होते हैं, जिसके कारण VSCode अब पथों को हल करने में सक्षम नहीं होता है, जिसका अर्थ है, आप केवल क्लिक नहीं कर सकते कमांड लाइन विंडो में पथ, इसके बजाय, आपको प्रत्येक फ़ाइल को स्वयं ढूँढना होगा। जब मैं सीएमके आउट-ऑफ-ट्री बिल्ड का उपयोग करता हूं, तो यह एक्लिप्स के "इंटेलिजेन्स" को तोड़ देता है और सीएमके सबप्रोजेक्ट्स के साथ समस्याएं पैदा करता है। अभी के लिए मेरा समाधान MakeFiles का उपयोग करना है, क्योंकि यह प्रति डिफ़ॉल्ट पूर्ण पथ का उपयोग करता है। लेकिन निंजा बेहतर है, यह बेहतर पठनीय फाइलें (नियम। निंजा ...) का उत्पादन करता है और कमांड लाइन पर बिल्ड आउटपुट बेहतर होता है। एक बहुप्रचारित संदर्भ में कमांड लाइन पर चेतावनियों को आउटपुट करने में समस्या है, इसका मतलब है, एकाधिक चेतावनियां इंटरलीव की जाती हैं। जो मुझे सिंगल थ्रेडेड बनाने का कारण बनता है, जो फिर से, बहुत कष्टप्रद है।

कृपया कोई इसे ठीक करे। मैं इस वजह से बहुत नाराज हूं।

मैं सीएमके और वीएससीओडी के साथ एआरएम-जीसीसी का उपयोग कर रहा हूं। जब मैं इन-सोर्स बिल्ड का उपयोग करता हूं, तो पथ "बिल्ड" निर्देशिका के सापेक्ष होते हैं ...

वर्कअराउंड मौजूद है: सोर्स ट्री के बाहर बिल्ड डीआईआर को चुना! यानी _$टीएमपीडीआईआर/..._

धन्यवाद क्लॉसक्लेन, लेकिन वर्कअराउंड आउट ऑफ सोर्स बिल्ड है, लेकिन मुझे अपने ट्री के अंदर फाइलों की जरूरत है, क्योंकि यह अन्य लिपियों द्वारा संदर्भित है। साथ ही यह एक गैर-मानक निर्माण आवश्यकता है।

अभी के लिए मेरा समाधान है, सीएमके को हमेशा पूर्ण पथ का उपयोग करने के लिए बदलना। मुझे समझ में नहीं आता कि इसके लिए कोई विकल्प क्यों नहीं है। हालांकि, अगर किसी और को इसकी आवश्यकता है, तो यहां सीएमके v3.18.1 का पैच दिया गया है:

@@ -241,7 +241,7 @@ void cmNinjaTargetGenerator::AddIncludeFlags(std::string& languageFlags,
   // Add include directory flags.
   std::string includeFlags = this->LocalGenerator->GetIncludeFlags(
     includes, this->GeneratorTarget, language,
-    language == "RC", // full include paths for RC needed by cmcldeps
+    true, // full include paths for RC needed by cmcldeps
     false, config);
   if (this->GetGlobalGenerator()->IsGCCOnWindows()) {
     std::replace(includeFlags.begin(), includeFlags.end(), '\\', '/');
@@ -1133,8 +1133,7 @@ void cmNinjaTargetGenerator::WriteObjectBuildStatement(
   const std::string& fileConfig, bool firstForConfig)
 {
   std::string const language = source->GetLanguage();
-  std::string const sourceFileName =
-    language == "RC" ? source->GetFullPath() : this->GetSourceFilePath(source);
+  std::string const sourceFileName = source->GetFullPath();
   std::string const objectDir = this->ConvertToNinjaPath(
     cmStrCat(this->GeneratorTarget->GetSupportDirectory(),
              this->GetGlobalGenerator()->ConfigDirectory(config)));

ध्यान दें , cmake के लिए एक पैच था, लेकिन देखें https://github.com/ninja-build/ninja/issues/1251

हमें निंजा के लिए एक पैच चाहिए!

मेरी आखिरी टिप्पणी में, मैंने सीएमके के सापेक्ष पथों के बजाय पूर्ण पथ का उपयोग करने के लिए एक पैच दिखाया। पता चला कि यह एक बुरा विचार है, क्योंकि यह निंजा के साथ कस्टम सीएमके हेडर निर्भरता को तोड़ता है (उदाहरण के लिए एक जेनरेट की गई हेडर फ़ाइल एक .json फ़ाइल पर निर्भर है)। मान लीजिए कि यह समस्या यहाँ इस मुद्दे से उत्पन्न हुई है, जिसे मैं समझने के लिए बहुत मूर्ख था।

अगर किसी को इसके बारे में दिलचस्पी है, तो मैं अब निंजा का उपयोग सापेक्ष पथों के साथ करता हूं। मैंने एकीकृत टर्मिनल के अंदर सापेक्ष पथों पर क्लिक करने में सक्षम होने के लिए VSCode के लिए एक एक्सटेंशन बनाया है। विस्तार

@ ग्रैंडक्रिस ग्रेट! इसे Output टैब में भी काम करने का कोई मौका?

@weliveindetail https://github.com/GrandChris/TerminalRelativePath/issues पर एक नया मुद्दा बनाने के लिए स्वतंत्र महसूस करें और अपने उपयोग-मामले का विस्तार से वर्णन करें। लेकिन वीएससीओडी में आउटपुट टैब एकीकृत टर्मिनल से अलग व्यवहार करता है और मुझे नहीं लगता कि इस संबंध में व्यवहार का विस्तार करने के लिए कोई एपीआई है।

ठीक है धन्यवाद। आखिरकार, क्लिक करने योग्य सापेक्ष पथ शायद वीएससीओडी या सीएमके एक्सटेंशन में हल किए जाने चाहिए। उनके पक्ष में पिंग करेंगे।

संदर्भ के लिए, यह सीएमके अंक 21865 में फिर से आया। यह एक ऐसे मामले का एक और build.ninja है जहां यह आसान नहीं है (संभव?)

1917 उपरोक्त प्रस्तावित ninja_workdir बाइंडिंग को अपने आप में एक उपयोगी विशेषता के रूप में जोड़ता है। एक बार इसका विलय हो जाने के बाद, मैं इस समस्या के समाधान के साथ अनुवर्ती कार्रवाई कर सकता हूं।

@jhasse मैं इस निश्चित अपस्ट्रीम को प्राप्त करने के लिए एक स्वीकार्य समाधान के साथ आना चाहता हूं। ninja_workdir समस्या का समाधान करता है। मैंने ऊपर अपना पक्ष रखा है। आप और क्या विकल्प सुझाते हैं?

जैसा कि आपने इस मुद्दे को इंगित किया है (डिफाइल पूर्ण पथों को प्रकट सापेक्ष पथों के पुनर्निर्माण के साथ मिलाकर) डिज़ाइन द्वारा है। मुझे लगता है कि हमें और अधिक विशिष्ट मुद्दे बनाने चाहिए, क्योंकि हमने चर्चा में कई मुद्दों को छुआ है (उदाहरण के लिए बिल्ड डीआईआर को सिम्लिंक करना)।

प्रारंभिक टिप्पणी में दो उपयोग के मामलों के लिए मेरे विकल्प होंगे:

यह त्रुटि संदेशों से मेल खाने और मूल फ़ाइलों को वापस संदर्भित करने के लिए आईडीई के लिए बेहतर आउटपुट उत्पन्न करता है।

या तो आईडीई को ठीक करें, या कंपाइलर को /FC या -fabs-path-diagnostics पास करें।

यह डीबग जानकारी में दर्ज पथों को भी प्रभावित कर सकता है।

यह भी संकलक द्वारा तय किया जाना चाहिए। मैं -fdebug-prefix-map को देखने का सुझाव दूंगा, लेकिन मुझे यकीन नहीं है कि समस्या वास्तव में क्या है।

यहाँ इस मुद्दे को प्रदर्शित करने वाली एक स्क्रिप्ट है: ninja-bug.bash.txt

वास्तव में नहीं, यह निंजा के वर्तमान व्यवहार को प्रदर्शित करता है। दो मुद्दे

1. "मेरा आईडीई कंपाइलर के आउटपुट से सही फाइल से मेल नहीं खा सकता है"
2. "मुझे डीबग जानकारी में पूर्ण पथ चाहिए"

आगे स्पष्टीकरण की आवश्यकता है। अन्यथा यह मेरे लिए एक XY समस्या की तरह दिखता है (X "पूर्ण और सापेक्ष पथों को मिला रहा है" और Y या तो 1. या 2 है)।

मुझे नहीं लगता कि समाधान "अन्य सभी टूलिंग में इसके आसपास काम करना" होना चाहिए।

1924 ninja_workdir दृष्टिकोण के आधार पर परीक्षणों के साथ एक पूर्ण कामकाजी सुधार प्रदर्शित करता है। इसका उपयोग करने वाला एक जनरेटर उपरोक्त सभी समस्याओं को हल कर सकता है।

मैं भी नहीं, क्योंकि मैं उन्हें वर्कअराउंड के रूप में नहीं देखता।

यह जीएनयू जीसीसी विकल्प नहीं हैं!

पूर्वाह्न 05.03.2021 उम 16:58 स्क्रिब जन निकलास हस नोटिफिकेशन @github.com:

या तो IDE ठीक करें, या /FC https://docs.microsoft.com/de-de/cpp/build/reference/fc-full-path-of-source-code-file-in-diagnostics पास करें या -fabs- पथ-निदान https://reviews.llvm.org/D23816 संकलक के लिए।

यह डीबग जानकारी में दर्ज पथों को भी प्रभावित कर सकता है।

यहाँ इस मुद्दे को प्रदर्शित करने वाली एक स्क्रिप्ट है: ninja-bug.bash.txt

वास्तव में नहीं, यह निंजा के वर्तमान व्यवहार को प्रदर्शित करता है।

आपके द्वारा उद्धृत मेरी पोस्ट स्वीकार करती है कि यह वर्तमान में प्रलेखित व्यवहार है।
इस मुद्दे का उद्देश्य डिजाइन को प्रश्न में बुलाना है
उपयोग के मामलों के एक वर्ग का प्रदर्शन जो यह सेवा नहीं करता है।

दो मुद्दे ... (1) ... (2) ... और स्पष्टीकरण की आवश्यकता है।

वे समस्याओं के केवल दो उदाहरण हैं जिन्हें हल करना आसान बना दिया गया है
टूलींग के लिए पूर्ण पथ पारित करना। निरपेक्ष पथ अनुचित नहीं हैं
सिर्फ इसलिए कि अन्य समाधान ऐसे के विशिष्ट उदाहरणों में उपलब्ध हैं
समस्याएं (कुछ विक्रेताओं से उपलब्ध टूलींग की विशिष्ट विशेषताओं का उपयोग करके)।
निरपेक्ष पथ अपडेट के बिना इन समस्याओं के एक बड़े वर्ग को हल करने में मदद करते हैं
बाकी पारिस्थितिकी तंत्र के लिए। जैसा कि मैंने पहले पोस्ट किया था :

हम हमेशा के लिए सापेक्ष बनाम पूर्ण पथ के गुणों पर बहस कर सकते हैं। निंजा चाहिए
उसके बारे में राय नहीं बनानी चाहिए। यहाँ समस्या ऐसे मामलों को सुलझा रही है जहाँ
दोनों का उपयोग एक ही निर्माण के भीतर किया जाता है। बिल्डसिस्टम जनरेटर हमेशा नहीं हो सकता
नियंत्रित करें कि उपकरण पथ के साथ क्या करेंगे।

जटिल वास्तविक-विश्व निर्माण प्रणालियों में, परतों की मनमानी संख्या हो सकती है
लिपियों, रैपरों, औजारों, आदि (सभी प्रकार के विक्रेताओं से) के बीच
बिल्ड फ़ाइल जनरेटर और वास्तविक पथ द्वारा build.ninja में लिखे गए पथ
एक defile में निंजा द्वारा सामना किया। कभी-कभी किसी दी गई फ़ाइल को किसके द्वारा संदर्भित किया जा सकता है
एक उपकरण से एक डिफाइल जिसे सीधे build.ninja से पथ नहीं दिया गया था।
डिफाइल्स के लिए निंजा के वर्तमान डिजाइन के तहत काम करने के लिए, संपूर्ण टूलिंग
स्टैक को ठीक-ठीक बताया जाना चाहिए कि कैसे build.ninja जनरेटर व्यक्त करना चुनता है
बिल्ड स्टेटमेंट पर वे पथ, और सुविधाएँ हैं जो उन्हें संरक्षित करती हैं या परिवर्तित करती हैं
उन्हें उसी तरह। यह सामान्य रूप से ट्रैक्टेबल नहीं है।

निन्जा इस समस्या को एक छोटे डिज़ाइन परिवर्तन के साथ हल कर सकता है:
build.ninja (और इसके विपरीत) में एक सापेक्ष पथ के साथ एक डिफाइल में पूर्ण पथ
विपरीत)। मैं एक ही फ़ाइल में मनमाने रास्तों को समेटने के लिए नहीं कह रहा हूँ, केवल
पहचानें कि /path/to/some/file एक depfile में some/file in . के समान है
बिल्ड फ़ाइल /path/to/build.ninja ।

इस तरह के डिज़ाइन अपडेट के लिए मिसाल है। जब निंजा पहली बार शुरू हुआ, आशा
क्या वह पथ हमेशा ninja द्वारा बिल्कुल उसी में सामना किया जाएगा
बाइट-फॉर-बाइट प्रतिनिधित्व जिसे बिल्ड फ़ाइल जनरेटर ने लिखा है
build.ninja । git blame -M -C -w -- src/util.cc चलाएँ और इतिहास देखें
CanonicalizePath के मामलों की एक श्रृंखला देखने के लिए जो सामने आए थे जहां वह
डिजाइन दर्शन को शिथिल करना पड़ा। यह ऐसे मामलों का एक और वर्ग है।

बात यह है कि मैं इससे असहमत हूं

निंजा को इसके बारे में राय नहीं दी जानी चाहिए।

पहली जगह में।

यह सामान्य रूप से ट्रैक्टेबल नहीं है।

तो विशिष्ट मुद्दा क्या है? क्षमा करें मैं थोड़ा भ्रमित हूँ।

मैं पहली जगह में "निंजा को उस बारे में राय नहीं बनानी चाहिए" से असहमत हूं .... तो विशिष्ट मुद्दा क्या है?

यह किसी एक विशिष्ट मुद्दे के बारे में नहीं है, बल्कि उन समस्याओं के पूरे वर्ग के बारे में है जिन्हें पूर्ण पथों के साथ हल करना बहुत आसान है। इससे कोई फर्क नहीं पड़ता कि डेवलपर्स अपने उपकरणों के लिए पूर्ण पथ क्यों पारित करना चाहते हैं, केवल यह कि वे अपने विशेष मामले पर लागू होने वाले किसी भी कारण से पूर्ण पथ का उपयोग करना चाहते हैं। बिल्ड सिस्टम अपने उपयोगकर्ताओं की सेवा के लिए मौजूद हैं, नीति निर्धारित करने के लिए नहीं। निंजा को बिल्ड सिस्टम के लिए असेंबली भाषा माना जाता है, और फिर भी मिश्रित-शैली वाले पथों का उपयोग करके बिल्ड सिस्टम को व्यक्त करने का कोई तरीका नहीं है।

अपस्ट्रीम परिवर्तनों के लिए निंजा की नीति यह है कि समस्याओं को फ़ाइल जेनरेटर बनाकर हल किया जाना चाहिए, न कि निंजा अपस्ट्रीम, अगर उन्हें दक्षता के नुकसान के बिना हल किया जा सकता है। इस मामले में, सामान्य-उद्देश्य ninja_workdir प्रदान करने का एकमात्र तरीका बिल्ड फ़ाइल जेनरेटर से डिफाइल पथों का स्टाइल सामंजस्य है, प्रत्येक कमांड के बाद इंजेक्ट करना है जो डिफाइल में पथों को संशोधित करने के लिए एक अतिरिक्त कमांड उत्पन्न करता है मिलान करने के लिए निंजा लोड होने से पहले बिल्ड फ़ाइल। उस अतिरिक्त कमांड की अपनी रनटाइम लागत होगी जो #1924 की तुलना में बहुत अधिक है ( ninja प्रक्रिया के अंदर एक छोटी संख्या अतिरिक्त इन-मेमोरी लुकअप)। इसलिए सामान्य-उद्देश्य समाधान निन्जा अपस्ट्रीम में प्रदान करने के लिए अधिक कुशल है, और इसलिए शामिल करने के लिए एक उम्मीदवार है।

यहां तक ​​​​कि अगर आप हर चीज के लिए निरपेक्ष रास्तों का उपयोग करते हैं, तो निरपेक्ष और सापेक्ष पथों को मिलाने के बजाय, एक कष्टप्रद एर्गोनॉमिक्स समस्या है। यदि उपयोगकर्ता ninja को नकली लक्ष्य के बजाय एक विशिष्ट आउटपुट फ़ाइल को पुन: उत्पन्न करने के लिए कहता है, उदाहरण के लिए, ninja out/my_executable या ninja out/foo/bar.o , तो उन्हें पूर्ण पथ, या निंजा पास करना याद रखना होगा एक भ्रमित "अज्ञात लक्ष्य" त्रुटि के साथ विफल हो जाएगा। विपरीत समस्या भी मौजूद है: जब बिल्ड.निंजा फ़ाइल सापेक्ष पथों का उपयोग करती है, तो उपयोगकर्ता निन्जा को एक निरपेक्ष पथ के पुनर्निर्माण के लिए कह सकता है।

मेरे द्वारा बनाए गए एक निंजा जनरेटर टूल में, मैं हर एक build स्टेटमेंट में आउटपुट के रूप में सापेक्ष पथ और इसके संबंधित पूर्ण पथ दोनों को शामिल करके इसके आसपास काम करता हूं। यह काम करता है, लेकिन यह वास्तव में निंजा में एक सीमा के आसपास काम करने के लिए एक हैक की तरह लगता है। (संपादित करें: इसके अलावा, यदि बिल्ड.निंजा केवल सापेक्ष पथ का उपयोग करता है और इस प्रकार एक अलग पूर्ण पथ पर ले जाने के बाद भी काम कर सकता है, तो पूर्ण पथ उपनाम जोड़ने से वह क्षमता टूट जाएगी।)

बेशक, यह बिल्कुल वैसा ही मुद्दा नहीं है जैसा कि डिफाइल्स, लेकिन यह सुझाव देता है कि निंजा को सामान्य रूप से निरपेक्ष बनाम सापेक्ष पथ समकक्षों के बारे में अधिक जानकारी होनी चाहिए।

@comex धन्यवाद, यह एक वैध चिंता है। क्या आप इसके लिए कोई नया अंक खोल सकते हैं?

इससे कोई फर्क नहीं पड़ता कि क्यों डेवलपर्स अपने टूल्स के लिए पूर्ण पथ पारित करना चाहते हैं [...]

मैं असहमत हूं।

इस मामले में, सामान्य-उद्देश्य ninja_workdir प्रदान करने का एकमात्र तरीका - डिफाइल पथों का स्टाइल सामंजस्य [...]

हालांकि आपको पहले स्थान पर ninja_workdir -स्टाइल सुलह की आवश्यकता क्यों है?

हालांकि आपको पहले स्थान पर ninja_workdir- शैली के मेल-मिलाप की आवश्यकता क्यों है?

यह डेवलपर्स को build.ninja में सापेक्ष पथों का उपयोग करने की अनुमति देता है, जबकि वे अभी भी टूलींग द्वारा उत्पन्न निरपेक्ष पथों को संभालते हैं जिन्हें वे नियंत्रित नहीं करते हैं। अन्यथा, उन्हें build.ninja में निरपेक्ष पथ का उपयोग करने के लिए मजबूर किया जा सकता है ताकि निंजा की उप-डिज़ाइन सीमा के संयोजन में इस तरह के टूलींग को समायोजित किया जा सके। मेरा प्रस्ताव सापेक्ष पथों के उपयोग को नहीं रोकता है। यह उनका अधिक उपयोग करने में सक्षम बनाता है।

मैंने #1924 के समान सामंजस्य को लागू करने के लिए #1925 खोला है, लेकिन ninja_workdir बाध्यकारी के बिना। यह प्रतीकात्मक लिंक के साथ तार्किक वर्कडिर पथों का समर्थन करने के निर्णय से डिफाइल पथों को समेटने के निर्णय को अलग करता है।

[...] टूलिंग द्वारा डिफाइल्स में उत्पन्न निरपेक्ष पथ जिन्हें वे नियंत्रित नहीं करते हैं।

क्या ऐसे टूलींग के लिए कोई उदाहरण है?

हम संभवतः दुनिया में हर किसी के द्वारा उपयोग किए जाने वाले सभी टूलिंग के व्यवहार की भविष्यवाणी नहीं कर सकते हैं। यहां तक ​​कि हमारे द्वारा नियंत्रित टूलींग के लिए भी हम पहले से ही ऊपर कई मामलों पर चर्चा कर चुके हैं जिन्हें पूर्ण पथों के साथ हल करना आसान है, लेकिन टूल-विशिष्ट विकल्पों की आवश्यकता होती है और सापेक्ष पथों के साथ हल करने के लिए बहुत अधिक देखभाल की आवश्यकता होती है। सीएमके समान कारणों से कई मामलों में पूर्ण पथ पसंद करता है। मेरे पास निंजा जनरेटर के बारे में कई बग रिपोर्ट हैं जो ऐसा नहीं कर रहे हैं जबकि अन्य सभी जनरेटर करते हैं। मैंने कई बार निर्भरता की समस्या को ट्रैक करने में घंटों बिताए हैं, केवल यह पता लगाने के लिए कि डिफाइल पथों का निर्माण मैनिफेस्ट पथों के साथ मेल नहीं किया जा रहा है। उपकरण जानकारी प्रदान कर रहे हैं निंजा को निर्भरताओं को पकड़ने की जरूरत है, लेकिन निंजा इसे अनदेखा कर रहा है।

आपकी स्थिति एक राय के रूप में सामने आती है कि सापेक्ष पथ सार्वभौमिक रूप से बेहतर हैं। अन्य लोगों की एक अलग राय है कि कुछ मामलों में पूर्ण पथ बेहतर होते हैं। मुझे नहीं लगता कि यह सापेक्ष पथों को प्रचारित करने के लिए एक निर्माण उपकरण का स्थान है।

मेरा प्रस्ताव निंजा के लिए बुनियादी ढांचे की एक छोटी राशि जोड़ता है। इससे क्या दुख होता है? इसका न होना बहुत बड़ी लागत को बाहरी करता है।

हां यह सच है!

और पूर्ण पथ के साथ, cmake डुप्लिकेट कंपाइलर को शामिल करने में सक्षम है पथ शामिल हैं।
यह निर्माण समय को फिर से कम करता है।

पूर्वाह्न 09.03.2021 उम 19:20 श्राइब ब्रैड किंग नोटिफिकेशन @github.com:

मुझे नहीं लगता कि यह सापेक्ष पथों को प्रचारित करने के लिए एक निर्माण उपकरण का स्थान है।

मैं एक समस्या के बारे में सीएमके मुद्दे को सेट करता हूं जिसका सामना हम क्यूटी के त्वरित कंपाइलर जेनरेट सीपीपी फाइलों के साथ कर रहे हैं और एकता निर्माण को सक्षम करते हैं। मेरी स्थानीय जांच से पता चला है कि निंजा सबसे तेज निर्माण प्रणाली है, लेकिन इस नक्षत्र में यह अविश्वसनीय है। अब मैं इस समस्या का सामना कर रहा हूं कि मैं वर्कअराउंड कैसे ढूंढ सकता हूं या बिल्ड टाइम में वृद्धि को उचित ठहरा सकता हूं।

सीएमके को सर्कुलर निर्भरता के साथ सिर्फ एक समस्या का सामना करना पड़ा, जो हाल ही में, इस निंजा मुद्दे से मुखौटा था। यदि इस समस्या को ठीक कर दिया गया होता, तो हम सीएमके के मुद्दे को बहुत पहले ही खोज लेते।