नियम
j2objc_library
j2objc_library(name, deps, compatible_with, deprecation, distribs, entry_classes, features, jre_deps, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)
यह नियम JavaJ स्रोत फ़ाइलों का अनुवाद Objective-C पर करने के लिए, J2ObjC का इस्तेमाल करता है. इसका इस्तेमाल objc_library और objc_binary नियम की निर्भरता के तौर पर किया जा सकता है. J2ObjC के बारे में ज़्यादा जानकारी JJObjC साइट पर मिल सकती है
पसंद के मुताबिक बनाए गए J2ObjC ट्रांसमिशन फ़्लैग के बारे में कमांड लाइन में, बिल्ड फ़्लैग
--j2objc_translation_flags
का इस्तेमाल करके बताया जा सकता है.
कृपया ध्यान दें कि j2objc_library टारगेट में शामिल अनुवाद की गई फ़ाइलों को कंपाइल करने के लिए डिफ़ॉल्ट कॉन्फ़िगरेशन का इस्तेमाल करके कंपाइल किया जाएगा. यह objc_library नियम के सोर्स की तरह ही होगा, जिसमें एट्रिब्यूट में कंपाइल करने के विकल्प नहीं होंगे.
इसके अलावा, जनरेट किए गए कोड को टारगेट लेवल पर ही डुप्लीकेट किया जाता है, न कि सोर्स लेवल पर. अगर आपके पास दो अलग-अलग Java टारगेट हैं, जिनमें एक ही Java सोर्स फ़ाइल शामिल है, तो आपको लिंक के समय डुप्लीकेट सिंबल गड़बड़ी दिख सकती है. इस समस्या को ठीक करने का सही तरीका यह है कि शेयर की गई Java स्रोत फ़ाइलों को एक अलग सामान्य टारगेट में ले जाया जाए जिस पर भरोसा किया जा सकता है.
तर्क
विशेषताएं | |
---|---|
name |
इस टारगेट के लिए कोई खास नाम. |
deps
|
j2objc_library , java_library ,
java_import और java_proto_library के टारगेट की सूची, जिसमें Objective-C में कॉपी किए जाने के लिए Java फ़ाइलें शामिल हैं.
सभी J2ObjC अनुवाद, ट्रांज़िटिव बंद में शामिल स्रोत Java फ़ाइल के प्रकार के आधार पर अलग-अलग तरीके से काम करता है. उपयोगकर्ता अपने कोड में J2ObjC से जनरेट की गई हेडर फ़ाइलें इंपोर्ट कर सकते हैं. इन फ़ाइलों के इंपोर्ट पाथ, मूल Java आर्टफ़ैक्ट के रूट-रिलेटिव पाथ होते हैं. उदाहरण के लिए,
अगर Proto_library के नियम, इस नियम के ट्रांज़िट के दौरान बंद हैं, तो बाइनरी लेवल पर J2ObjC प्रोटो भी जनरेट, कंपाइल, और लिंक किए जाएंगे. जनरेट किए गए कोड को इंपोर्ट पाथ |
entry_classes
|
--j2objc_dead_code_removal
का फ़्लैग चालू है, तो इस एट्रिब्यूट की ज़रूरत होती है. Java क्लास की पहचान उनके कैननिकल नामों में होनी चाहिए, जैसा कि Java की भाषा की खास बातों में बताया गया है.
जब --j2objc_dead_code_removal फ़्लैग तय किया जाता है, तो एंट्री क्लास की सूची को एक जगह से दूसरी जगह इकट्ठा किया जाएगा. साथ ही, इस्तेमाल नहीं किए गए कोड का विश्लेषण करने के लिए, इसे एंट्री पॉइंट के तौर पर इस्तेमाल किया जाएगा.
इस्तेमाल नहीं की गई कक्षाओं को आखिरी ObjC ऐप्लिकेशन बंडल से हटा दिया जाएगा.
|
jre_deps
|
j2objc_library नियम से अनुवाद किए गए सभी Java कोड के लिए, ज़रूरी JRE एम्युलेशन लाइब्रेरी की सूची. डिफ़ॉल्ट रूप से, सिर्फ़ मुख्य JRE फ़ंक्शन लिंक होता है.
|
objc_Import
objc_import(name, hdrs, alwayslink, archives, compatible_with, deprecation, distribs, features, includes, licenses, restricted_to, sdk_dylibs, sdk_frameworks, sdk_includes, tags, target_compatible_with, testonly, textual_hdrs, visibility, weak_sdk_frameworks)
यह नियम पहले से कंपाइल की गई स्टैटिक लाइब्रेरी को .a
फ़ाइल के तौर पर इनकैप्सुलेट करता है. इस नीति के ज़रिए, objc_library
पर काम करने वाले एक जैसे एट्रिब्यूट का इस्तेमाल करके, हेडर और संसाधनों को एक्सपोर्ट किया जा सकता है.
तर्क
विशेषताएं | |
---|---|
name |
इस टारगेट के लिए कोई खास नाम. |
hdrs
|
ये हेडर, लाइब्रेरी के सार्वजनिक इंटरफ़ेस के बारे में जानकारी देते हैं. साथ ही, इन्हें इस नियम या निर्भर नियमों में स्रोतों के ज़रिए शामिल करने के लिए उपलब्ध कराया जाता है. इस लाइब्रेरी के क्लाइंट के ज़रिए शामिल किए जाने वाले हेडर, इसके बजाय src एट्रिब्यूट में शामिल किए जाने चाहिए. अगर मॉड्यूल चालू हैं, तो इन्हें सोर्स से अलग से कंपाइल किया जाएगा. |
alwayslink
|
srcs और non_arc_srcs में दी गई फ़ाइलों की सभी ऑब्जेक्ट फ़ाइलों से लिंक कर देगी, भले ही कुछ में बाइनरी से जुड़ी कोई निशान न हो.
यह तब मददगार होता है, जब बाइनरी में आपके कोड को साफ़ तौर पर कॉल नहीं किया जाता है. उदाहरण के लिए, अगर आपके कोड को किसी सेवा से मिले कुछ कॉलबैक पाने के लिए रजिस्टर किया गया है.
|
archives
|
.a उन फ़ाइलों की सूची जिन्हें Objective-C टारगेट के लिए दिया गया है और जो
इस टारगेट पर निर्भर करते हैं.
|
includes
|
#include/#import खोज पाथ की सूची
और टारगेट के आधार पर सभी पाथ.
ऐसा उन तीसरे पक्ष और ओपन सोर्स लाइब्रेरी की मदद करने के लिए है जो अपने #import/#include स्टेटमेंट में पूरा फ़ाइल फ़ोल्डर पाथ तय नहीं करते हैं.
पाथ को पैकेज डायरेक्ट्री के हिसाब से समझा जाता है और
जेनरिक फ़ाइलों और बिन रूट (उदाहरण के लिए, COPTS के उलट, ये फ़्लैग इस नियम और इस पर निर्भर सभी नियमों के लिए जुड़ जाते हैं. (ध्यान दें: यह उन नियमों पर निर्भर नहीं है जिन पर निर्भर है!) ऐसा करते समय सावधानी बरतें, क्योंकि इस पर बहुत दूर से असर हो सकता है. समझ में न आने पर, COPTS में फ़्लैग करें और कोटेशन शामिल करें. |
sdk_dylibs
|
|
sdk_frameworks
|
किसी टॉप लेवल की Apple बाइनरी को जोड़ते समय, उस बाइनरी और ट्रांज़िटिव डिपेंडेंसी ग्राफ़ में शामिल सभी SDK फ़्रेमवर्क लिंक हो जाते हैं. |
sdk_includes
|
#include/#import खोज पाथ की सूची और टारगेट के आधार पर सभी पाथ, जहां हर पाथ $(SDKROOT)/usr/include से जुड़ा हुआ है.
|
textual_hdrs
|
|
weak_sdk_frameworks
|
|
objc_library
objc_library(name, deps, srcs, data, hdrs, alwayslink, compatible_with, copts, defines, deprecation, distribs, enable_modules, exec_compatible_with, exec_properties, features, includes, licenses, linkopts, module_map, module_name, non_arc_srcs, pch, restricted_to, runtime_deps, sdk_dylibs, sdk_frameworks, sdk_includes, tags, target_compatible_with, testonly, textual_hdrs, toolchains, visibility, weak_sdk_frameworks)
यह नियम, ऑब्जेक्टिव-सी सोर्स फ़ाइलों से स्टैटिक लाइब्रेरी बनाता है.
तर्क
विशेषताएं | |
---|---|
name |
इस टारगेट के लिए कोई खास नाम. |
deps
|
|
srcs
|
|
hdrs
|
ये हेडर, लाइब्रेरी के सार्वजनिक इंटरफ़ेस के बारे में जानकारी देते हैं. साथ ही, इन्हें इस नियम या निर्भर नियमों में स्रोतों के ज़रिए शामिल करने के लिए उपलब्ध कराया जाता है. इस लाइब्रेरी के क्लाइंट के ज़रिए शामिल किए जाने वाले हेडर, इसके बजाय src एट्रिब्यूट में शामिल किए जाने चाहिए. अगर मॉड्यूल चालू हैं, तो इन्हें सोर्स से अलग से कंपाइल किया जाएगा. |
alwayslink
|
srcs और non_arc_srcs में दी गई फ़ाइलों की सभी ऑब्जेक्ट फ़ाइलों से लिंक कर देगी, भले ही कुछ में बाइनरी से जुड़ी कोई निशान न हो.
यह तब मददगार होता है, जब बाइनरी में आपके कोड को साफ़ तौर पर कॉल नहीं किया जाता है. उदाहरण के लिए, अगर आपके कोड को किसी सेवा से मिले कुछ कॉलबैक पाने के लिए रजिस्टर किया गया है.
|
copts
|
ध्यान दें कि जनरेट किए गए Xcode प्रोजेक्ट के लिए, डायरेक्ट्री पाथ को "-I" कूप में इस्तेमाल किए गए फ़्लैग पार्स किए जाते हैं और उन्हें "$(WORKSPACE_ROOT)/" के साथ जोड़ा जाता है; अगर वे रिलेटिव पाथ हैं, और उनसे जुड़े Xcode टारगेट के हेडर सर्च पाथ के साथ जोड़े जाते हैं. |
defines
|
-D फ़्लैग. वे KEY=VALUE के तौर पर या KEY में होने चाहिए. साथ ही, उन्हें
सिर्फ़ टारगेट के लिए कंपाइलर के तौर पर पास करना चाहिए (copts के तौर पर) और इस टारगेट के लिए, सभी objc_ डिपेंडेंसी को भी पास किया जाना चाहिए.
"Make वैरिएबल" की जगह लागू होना और
बॉर्न शेल टोकन का इस्तेमाल करना.
|
enable_modules
|
|
includes
|
#include/#import खोज पाथ की सूची
और टारगेट के आधार पर सभी पाथ.
ऐसा उन तीसरे पक्ष और ओपन सोर्स लाइब्रेरी की मदद करने के लिए है जो अपने #import/#include स्टेटमेंट में पूरा फ़ाइल फ़ोल्डर पाथ तय नहीं करते हैं.
पाथ को पैकेज डायरेक्ट्री के हिसाब से समझा जाता है और
जेनरिक फ़ाइलों और बिन रूट (उदाहरण के लिए, COPTS के उलट, ये फ़्लैग इस नियम और इस पर निर्भर सभी नियमों के लिए जुड़ जाते हैं. (ध्यान दें: यह उन नियमों पर निर्भर नहीं है जिन पर निर्भर है!) ऐसा करते समय सावधानी बरतें, क्योंकि इस पर बहुत दूर से असर हो सकता है. समझ में न आने पर, COPTS में फ़्लैग करें और कोटेशन शामिल करें. |
linkopts
|
|
module_map
|
|
module_name
|
|
non_arc_srcs
|
|
pch
|
|
runtime_deps
|
|
sdk_dylibs
|
|
sdk_frameworks
|
किसी टॉप लेवल की Apple बाइनरी को जोड़ते समय, उस बाइनरी और ट्रांज़िटिव डिपेंडेंसी ग्राफ़ में शामिल सभी SDK फ़्रेमवर्क लिंक हो जाते हैं. |
sdk_includes
|
#include/#import खोज पाथ की सूची और टारगेट के आधार पर सभी पाथ, जहां हर पाथ $(SDKROOT)/usr/include से जुड़ा हुआ है.
|
textual_hdrs
|
|
weak_sdk_frameworks
|
|
उपलब्ध_xcodes
available_xcodes(name, default, deprecation, distribs, features, licenses, tags, testonly, versions, visibility)
इस नियम के दो टारगेट, xcode_config
नियम वाले इंस्टेंस पर निर्भर हो सकते हैं. ये इंस्टेंस, रिमोट तरीके से और स्थानीय तौर पर उपलब्ध xcode वर्शन के बारे में बताते हैं.
इससे, सभी ग्रुप के लिए उपलब्ध xcode से, आधिकारिक xcode वर्शन को चुना जा सकता है.
तर्क
विशेषताएं | |
---|---|
name |
इस टारगेट के लिए कोई खास नाम. |
default
|
|
versions
|
|
xcode_config
xcode_config(name, default, deprecation, distribs, features, licenses, local_versions, remote_versions, tags, testonly, versions, visibility)
इस नियम के एक टारगेट का रेफ़रंस --xcode_version_config
बिल्ड फ़्लैग में दिया जा सकता है. इससे,
--xcode_version
फ़्लैग का इस्तेमाल स्वीकार किए गए आधिकारिक xcode वर्शन में किया जा सकता है.
इससे कई रजिस्टर किए गए उपनामों से, आधिकारिक xcode वर्शन को चुना जा सकता है.
तर्क
विशेषताएं | |
---|---|
name |
इस टारगेट के लिए कोई खास नाम. |
default
|
xcode_version बिल्ड फ़्लैग तय नहीं किया गया है, तो दिए गए xcode_version टारगेट के ज़रिए बताए गए वर्शन का इस्तेमाल किया जाना चाहिए. अगर कोई
versions सेट है, तो यह ज़रूरी है. अगर remote_versions या
local_versions सेट है, तो इसे सेट नहीं किया जा सकता.
|
local_versions
|
xcode_version |
remote_versions
|
xcode_version |
versions
|
xcode_version को स्वीकार किया गया |
xcode_version
xcode_version(name, default_ios_sdk_version, default_macos_sdk_version, default_tvos_sdk_version, default_watchos_sdk_version, deprecation, distribs, features, licenses, tags, testonly, version, visibility)
उस xcode वर्शन के लिए, मान्य आधिकारिक xcode वर्शन को स्वीकार किया जाता है.
xcode_config
नियम देखें.
तर्क
विशेषताएं | |
---|---|
name |
इस टारगेट के लिए कोई खास नाम. |
default_ios_sdk_version
|
ios_sdk_version बिल्ड फ़्लैग, यहां बताई गई वैल्यू को बदल देगा.
|
default_macos_sdk_version
|
macos_sdk_version बिल्ड फ़्लैग, यहां बताई गई वैल्यू को बदल देगा.
|
default_tvos_sdk_version
|
tvos_sdk_version बिल्ड फ़्लैग, यहां बताई गई वैल्यू को बदल देगा.
|
default_watchos_sdk_version
|
watchos_sdk_version बिल्ड फ़्लैग, यहां बताई गई वैल्यू को बदल देगा.
|
version
|
|