update mkconcore logic to select scripts to add to src

[GREENRAT-K405]

This fixes #429

changes made:

• Added a pre-processing loop that iterates over nodes_dict to extract and store the required file extensions in a required_langs set
• Wrapped the dependency copying logic for Python, C++, Verilog, and MATLAB/Octave (including the mkcompile script) inside conditional if statements. The script now only attempts to locate and copy protocol files if that specific language is present in the graphml structure

[GREENRAT-K405]

@pradeeban , I have recreated the PR, those unnecessary line changes were shown due to some issue related to CRLF.

[GREENRAT-K405]

@pradeeban
One additional question regarding project idea:

If we follow a julia first approach, we should technically replace mkconcore.py (our orchestrator) with mkconcore.jl?

But since it is just an orchestrator code, changing it to jl might not be of much benefit.

Why I felt this question was important to ask :

• Do we "replace" python first approach of concore with a julia first approach or do we just add support for julia concore programs?
• because, if we plan on replacing mkconcore.py with mkconcore.jl, it will be one of the major end outcomes of the project

[pradeeban]

ok, good points! I think it is unnecessary to have a strong time investments unless there is a performance impact. Do you see a performance benefit in doing so? In that case, state that in your proposal. If not, also state that in your proposal and justify the decision either way. One thing we know for sure is Python is not the ideal language for latency-sensitve use cases of concore.

[GREENRAT-K405]

since mkconcore.py is just going to be called at the initial state, it won't actually matter much even if there is some improvements done by mkconcore.jl (julia version will still be very minutely faster in this case).

regardless, I believe I should develop mkoncore.jl (even if it is time consuming), though the benefits are less immediately, if the project vision for right now is julia implementation and the long term vision of control-core-project is low latency and first-class performance julia should be used here too. We could always revert back to python orchestrator in case of too complications :)

Thanks for your guidance!

[pradeeban]

Awesome plan. It could also make a little research paper, which you should add as an optional (i.e., "if time permits") outcome as part of your GSoC proposal.

[GREENRAT-K405]

Thanks for your guidance Pradeeban Sir!