সিএমকে একটি লক্ষ্যের জন্য উত্স ফাইলগুলি নির্দিষ্ট করার বিভিন্ন উপায় সরবরাহ করে। একটি হ'ল গ্লোববিং ( ডকুমেন্টেশন ) ব্যবহার করা , উদাহরণস্বরূপ:
FILE(GLOB MY_SRCS dir/*)
আরেকটি পদ্ধতি হ'ল প্রতিটি ফাইল পৃথকভাবে নির্দিষ্ট করা।
কোন পথে পছন্দ হয়? গ্লোব্বিং সহজ বলে মনে হচ্ছে তবে শুনেছি এর কিছুটা ডাউনসাইড রয়েছে।
উত্তর:
সম্পূর্ণ প্রকাশ: আমি মূলত এর সরলতার জন্য গ্লোববিং পদ্ধতির পছন্দ করেছি, কিন্তু কয়েক বছর ধরে আমি বুঝতে পেরেছি যে স্পষ্টত ফাইলগুলি তালিকাভুক্ত করা বৃহত, বহু-বিকাশকারী প্রকল্পের জন্য কম ত্রুটি-প্রবণ।
আসল উত্তর:
গ্লোব্বিংয়ের সুবিধাগুলি হ'ল:
নতুন ফাইল যুক্ত করা সহজ কারণ সেগুলি কেবলমাত্র এক জায়গায় তালিকাবদ্ধ রয়েছে: ডিস্কে। গ্লোববিং নকল সৃষ্টি করে না।
আপনার CMakeLists.txt ফাইলটি ছোট হবে। আপনার কাছে প্রচুর ফাইল থাকলে এটি একটি বড় প্লাস। গ্লোব না করা আপনার ফাইলগুলির বিশাল তালিকার মধ্যে সিএমকে যুক্তি হারাতে পারে।
হার্ডকোডযুক্ত ফাইল তালিকা ব্যবহারের সুবিধাগুলি হ'ল:
সিএমকে ডিস্কে একটি নতুন ফাইলের নির্ভরতা সঠিকভাবে ট্র্যাক করবে - আমরা যদি গ্লোব ব্যবহার করি তবে আপনি যখন সিএমকে দৌড়ালেন তখন প্রথমবারের মতো বিশ্বব্যাপী ফাইলগুলি বাছাই করা যাবে না
আপনি নিশ্চিত করেছেন যে কেবলমাত্র আপনার ফাইলগুলি যুক্ত করা হয়েছে। গ্লোব্বিং আপনার চাই না এমন বিপথগামী ফাইল বাছাই করতে পারে।
প্রথম ইস্যুটি সম্পর্কে কাজ করার জন্য, আপনি স্পর্শ কমান্ডটি ব্যবহার করে বা কোনও পরিবর্তন ছাড়াই ফাইলটি লেখার মাধ্যমে সিএমকেলিস্ট.টেক্সটকে কেবল "স্পর্শ" করতে পারেন the এটি সিএমকে পুনরায় রান করতে এবং নতুন ফাইলটি তুলতে বাধ্য করবে।
দ্বিতীয় সমস্যাটি সমাধানের জন্য আপনি আপনার কোডটি সাবধানে ডিরেক্টরিতে সংগঠিত করতে পারেন যা আপনি সম্ভবত যাইহোকই করেন। সবচেয়ে খারাপ ক্ষেত্রে, আপনি list(REMOVE_ITEM)গ্লোববেড ফাইলগুলি পরিষ্কার করতে কমান্ডটি ব্যবহার করতে পারেন :
file(GLOB to_remove file_to_remove.cpp)
list(REMOVE_ITEM list ${to_remove})
যদি আপনি একই বিল্ড ডিরেক্টরিতে আপনার কোডের পুরানো সংস্করণগুলি চেষ্টা করতে গিট-বাইসেক্টের মতো কিছু ব্যবহার করে থাকেন তবে একমাত্র আসল পরিস্থিতি এটি আপনাকে কাটাতে পারে। সেক্ষেত্রে তালিকায় সঠিক ফাইলগুলি পাওয়ার জন্য আপনাকে প্রয়োজনের তুলনায় আরও পরিষ্কার এবং সংকলন করতে হতে পারে। এটি এমন একটি কর্নার কেস এবং আপনি ইতিমধ্যে আপনার পায়ের আঙ্গুলের উপরে যেখানে এটি ইতিমধ্যে কোনও সমস্যা নয়।
Simply "touch" the CMakeLists.txtঠিক আছে যদি আপনি বিকাশকারী হন তবে অন্যদের জন্য আপনার সফ্টওয়্যারটি তৈরি করা সত্যই এটি একটি ব্যথার কারণ হতে পারে যে আপনার বিল্ডটি আপডেট হওয়ার পরে ব্যর্থ হয় এবং তদন্ত করার জন্য বোঝা তাদের উপর পড়ে is কেন।
সিএমকে সোর্সফাইলে নির্দিষ্ট করার সর্বোত্তম উপায় হ'ল তাদের স্পষ্টভাবে তালিকাভুক্ত করা ।
সিএমকের নির্মাতারা নিজে গ্লোববিং ব্যবহার না করার পরামর্শ দেন।
দেখুন: https://cmake.org/cmake/help/v3.15/command/file.html?hightlight=glob#file
(আমরা আপনার উত্স ট্রি থেকে উত্স ফাইলগুলির একটি তালিকা সংগ্রহের জন্য জিএলওবি ব্যবহার করার পরামর্শ দিচ্ছি না a যদি কোনও উত্স যুক্ত করা বা অপসারণের সময় কোনও সিএমকেলিস্ট.টেক্সট ফাইল পরিবর্তন না করে তবে জেনারেট বিল্ড সিস্টেমটি সিএমকে কখন পুনরায় জেনারেট করতে বলবে তা জানতে পারে না))
অবশ্যই, আপনি ডাউনসাইডগুলি কী তা জানতে চাইতে পারেন - পড়ুন!
গ্লোব্বিংয়ের বড় অসুবিধা হ'ল ফাইলগুলি তৈরি / মুছলে বিল্ট-সিস্টেমটি স্বয়ংক্রিয়ভাবে আপডেট হয় না।
আপনি যদি সেই ব্যক্তি ফাইল যুক্ত করেন তবে এটি গ্রহণযোগ্য ট্রেড অফ হিসাবে মনে হতে পারে, তবে এটি আপনার কোড তৈরি করা অন্যান্য ব্যক্তির পক্ষে সমস্যা সৃষ্টি করে, তারা প্রকল্পটি সংস্করণ-নিয়ন্ত্রণ থেকে আপডেট করে, বিল্ড চালান, তারপরে আপনার সাথে যোগাযোগ করুন, অভিযোগ করে যে
"বিল্ডটি ভাঙ্গা "।
বিষয়টিকে আরও খারাপ করার জন্য, ব্যর্থতা সাধারণত কিছু সংযোগের ত্রুটি দেয় যা সমস্যার কারণে কোনও ইঙ্গিত দেয় না এবং সময় এটির সমস্যা সমাধানের জন্য হারিয়ে যায়।
একটি প্রকল্পে আমি কাজ করেছি আমরা গ্লোববিং বন্ধ করে দিয়েছিলাম তবে নতুন ফাইল যুক্ত হওয়ার সময় এতগুলি অভিযোগ পেয়েছি যে, গ্লোব্বিংয়ের পরিবর্তে স্পষ্টভাবে ফাইল তালিকাভুক্ত করার যথেষ্ট কারণ ছিল।
এটি সাধারণ গিট কাজের প্রবাহকেও ভেঙে দেয়
( git bisectএবং বৈশিষ্ট্যগুলির শাখাগুলির মধ্যে স্যুইচিং)।
সুতরাং আমি এটি সুপারিশ করতে পারিনি, সমস্যার ফলে এটি সুবিধার চেয়ে অনেক বেশি, যখন কেউ আপনার সফ্টওয়্যারটি এর কারণে তৈরি করতে না পারে, তারা সমস্যাটি সন্ধান করতে বা কেবল হাল ছেড়ে দেওয়ার জন্য অনেক সময় আলগা করতে পারে।
এবং অন্য একটি নোট, কেবল স্পর্শ করার CMakeLists.txtজন্য মনে রাখা যথেষ্ট নয়, স্বয়ংক্রিয় বিল্ডগুলি যা গ্লোব্বিং ব্যবহার করে, আমাকে প্রতিটি বিল্ডেরcmake আগে দৌড়াতে হয়েছিল যেহেতু শেষ বিল্ডিংয়ের পরে ফাইলগুলি যুক্ত / সরানো হতে পারে।
এমন সময় রয়েছে যেখানে গ্লোববিং করা বেশি পছন্দনীয়:
CMakeLists.txtসিএমকে ব্যবহার করে না এমন বিদ্যমান প্রকল্পগুলির জন্য একটি ফাইল সেট আপ করার জন্য। cmakeবিল্ড-ফাইলগুলি তৈরির জন্য দৌড়াতে হবে (যা সিএমকের অভিপ্রায়ের বিরুদ্ধে চলে - বিল্ডিং থেকে কনফিগারেশনকে বিভক্ত করার ক্ষমতা) ।* হ্যাঁ, আমি কোনও আপডেটের আগে এবং পরে ডিস্কের ফাইলগুলির গাছের তুলনা করার জন্য একটি কোড লিখতে পারতাম, তবে এটি এত সুন্দর কাজ নয় এবং বিল্ড-সিস্টেমের আরও ভাল কিছু ছেড়ে যায়।
সিএমকে ৩.১২-এ, file(GLOB ...)এবংfile(GLOB_RECURSE ...) কমান্ডগুলি এমন একটি CONFIGURE_DEPENDSবিকল্প অর্জন করেছে যা গ্লোবটির মান পরিবর্তন হলে cmake পুনরায় চালু করে। যেহেতু উত্স ফাইলগুলির জন্য গ্লোব্বিংয়ের প্রাথমিক অসুবিধা ছিল তাই এখন এটি করা ঠিক হবে:
# Whenever this glob's value changes, cmake will rerun and update the build with the
# new/removed files.
file(GLOB_RECURSE sources CONFIGURE_DEPENDS "*.cpp")
add_executable(my_target ${sources})
তবে কিছু লোক এখনও উত্সগুলির জন্য গ্লোববিং এড়ানো পরামর্শ দেয়। প্রকৃতপক্ষে, ডকুমেন্টেশনে বলা হয়েছে:
আমরা আপনার উত্স ট্রি থেকে উত্স ফাইলগুলির একটি তালিকা সংগ্রহ করতে GLOB ব্যবহার করার পরামর্শ দিই না। ... দ্য
CONFIGURE_DEPENDSপতাকাটি সমস্ত জেনারেটরে নির্ভরযোগ্যভাবে কাজ করতে পারে না, বা যদি ভবিষ্যতে কোনও নতুন জেনারেটর যুক্ত করা থাকে যা এটি সমর্থন করতে পারে না, এটি ব্যবহার করে করা প্রকল্পগুলি আটকে থাকবে। এমনকি যদিCONFIGURE_DEPENDSনির্ভরযোগ্যভাবে কাজ করে তবে প্রতিটি পুনর্নির্মাণের জন্য চেক সম্পাদন করতে এখনও ব্যয় হবে।
ব্যক্তিগতভাবে, আমি সম্ভাব্য ত্রুটিগুলি ছাড়িয়ে যাওয়ার জন্য উত্স ফাইল তালিকাটি ম্যানুয়ালি পরিচালনা না করার সুবিধার বিষয়টি বিবেচনা করি। যদি আপনাকে ম্যানুয়ালি তালিকাভুক্ত ফাইলগুলিতে ফিরে যেতে হয়, কেবল গ্লোববেড উত্স তালিকা মুদ্রণ করে এটিকে আবার পেস্ট করে সহজেই অর্জন করা যায়।
নির্ভরতা ধরে রাখতে আপনি অতিরিক্ত ফাইলের ব্যয়ে নিরাপদে গ্লোবাল (এবং সম্ভবত হওয়া উচিত) করতে পারেন।
কোথাও এর মতো ফাংশন যুক্ত করুন:
# Compare the new contents with the existing file, if it exists and is the
# same we don't want to trigger a make by changing its timestamp.
function(update_file path content)
set(old_content "")
if(EXISTS "${path}")
file(READ "${path}" old_content)
endif()
if(NOT old_content STREQUAL content)
file(WRITE "${path}" "${content}")
endif()
endfunction(update_file)
# Creates a file called CMakeDeps.cmake next to your CMakeLists.txt with
# the list of dependencies in it - this file should be treated as part of
# CMakeLists.txt (source controlled, etc.).
function(update_deps_file deps)
set(deps_file "CMakeDeps.cmake")
# Normalize the list so it's the same on every machine
list(REMOVE_DUPLICATES deps)
foreach(dep IN LISTS deps)
file(RELATIVE_PATH rel_dep ${CMAKE_CURRENT_SOURCE_DIR} ${dep})
list(APPEND rel_deps ${rel_dep})
endforeach(dep)
list(SORT rel_deps)
# Update the deps file
set(content "# generated by make process\nset(sources ${rel_deps})\n")
update_file(${deps_file} "${content}")
# Include the file so it's tracked as a generation dependency we don't
# need the content.
include(${deps_file})
endfunction(update_deps_file)
এবং তারপরে গ্লোববিং করুন:
file(GLOB_RECURSE sources LIST_DIRECTORIES false *.h *.cpp)
update_deps_file("${sources}")
add_executable(test ${sources})
আপনি এখনও পূর্বের মতো সুস্পষ্ট নির্ভরতা (এবং সমস্ত স্বয়ংক্রিয় বিল্ডগুলি ট্রিগার করছেন) এর চারপাশে কার্টিং করছেন, এটি কেবল একের পরিবর্তে দুটি ফাইলে রয়েছে।
পদ্ধতিতে একমাত্র পরিবর্তন আপনি একটি নতুন ফাইল তৈরি করার পরে। যদি আপনি কর্মপ্রবাহকে গ্লোব না করেন তবে ভিজুয়াল স্টুডিওর ভিতরে থেকে সিএমকেলিস্ট.টিএসটিএসটি পরিবর্তন করতে হবে এবং পুনর্নির্মাণ করতে হবে, যদি আপনি গ্লোব করেন তবে আপনি স্পষ্টভাবে চটকে চালাচ্ছেন - বা কেবল সিএমকেলিস্ট.টেক্সট স্পর্শ করুন।
makeঅদ্ভুত লিঙ্কারের ত্রুটি দেওয়ার বিষয়ে উদ্বেগ সমাধান করে ।
প্রতিটি ফাইল পৃথকভাবে নির্দিষ্ট করুন!
আমি এটি আপডেট করার জন্য একটি প্রচলিত সিএমকেলিস্ট.টেক্সট এবং পাইথন স্ক্রিপ্ট ব্যবহার করি। আমি ফাইল যুক্ত করার পরে পাইথন স্ক্রিপ্টটি ম্যানুয়ালি চালিত করি।
আমার উত্তরটি এখানে দেখুন: https://stackoverflow.com/a/48318388/3929196