Dynamic switching method, device and equipment for IDE to adapt to multiple compiling tool chains
By using a configuration file-driven approach, the system automatically matches control types and generates user interfaces and commands, solving the problems of single IDE toolchain adaptation and decoupling difficulties, and achieving efficient configuration and dynamic switching of multiple compilation toolchains.
Patent Information
- Application Number
- CN202610169589.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-02-05
- Publication Date
- 2026-05-15
AI Technical Summary
Existing IDE toolchains are limited in their compatibility and cannot meet the needs of large projects that mix multiple languages or toolchains. Furthermore, CMake's decoupling method requires a high learning curve and compatibility challenges.
The basic information of the compilation toolchain, the initial values of compilation options, and the types of interface controls are defined by the configuration file. The configuration file node information is parsed to generate the user interface. The execution commands are automatically generated by associating control IDs and matching wildcards, so as to realize the dynamic switching of the compilation toolchain.
Adding or switching toolchains can be done without modifying the IDE core code, reducing the difficulty of adaptation. Visual interaction reduces the learning cost for users, improves configuration efficiency, avoids errors from manually writing commands, and enables dynamic switching with zero code modification.
Smart Images

Figure CN122044585A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of embedded integrated development platform technology, and in particular to a method, apparatus and device for dynamic switching of IDE to adapt to multiple compilation toolchains. Background Technology
[0002] An Embedded Integrated Development Environment (IDE) is a software toolkit tailored for embedded system development. It integrates code editing, compilation, debugging, simulation, and deployment functions, significantly improving development efficiency. Core functions include code editing, compilation, debugging and simulation, and project management. Compilation refers to providing compilers (GCC, IAR), linkers, and library files for the target processor (such as ARM Cortex-M, RISC-V), converting the code into binary files that can be downloaded to the target processor.
[0003] IDEs primarily support the build chain through two main approaches: 1. Domain-specific deep integration, addressing the complexities of embedded systems. For example, vendor-developed IDEs (Keil MDK, IAR Embedded, MULTI-IDE) deeply integrate their own configuration tools, code generators, and debuggers to lower the development threshold. 2. Decoupling of the build system from the build tools. The core of this model is the introduction of build systems like CMake as an intermediate layer. The IDE no longer directly controls the build chain but instead calls them through standardized interfaces. This approach offers significant flexibility; large projects often require a mix of languages or toolchains, and this architecture better manages complexity.
[0004] For domain-specific deep integration, vendor-provided IDEs typically only support one compiler toolchain, which cannot meet the needs of large projects that require mixing multiple languages or toolchains. If a project requires a different toolchain, all functionality needs to be redeveloped.
[0005] Decoupling the build system from the compilation tools, through CMake's standardized interface, offers significant flexibility; however, becoming familiar with CMake's interface configuration requires a learning curve. Furthermore, it doesn't integrate well with IDEs. While CMake and VS Code offer relatively good compatibility, VS Code cannot meet the needs of all complex embedded development projects. Summary of the Invention
[0006] Therefore, it is necessary to provide a method, apparatus, and device for dynamically switching between multiple compilation toolchains in an IDE, which can improve the configuration efficiency of multiple compilation toolchains in an IDE and reduce the configuration cost, in order to address the above-mentioned technical problems.
[0007] A method for dynamically switching between multiple compilation toolchains in IDE adaptation, the method comprising:
[0008] The basic information of each compilation toolchain, the initial values of compilation options, and the corresponding UI control types are defined through configuration files.
[0009] Parse the node information in the configuration file, match the UI control types, load the initial values, and generate the user interface for the UI controls.
[0010] In the user interface, the interface data of user operation is associated with and saved through control ID. According to the command generation rules preset in the configuration file, the interface data is matched with wildcards in the command generation rules to generate the executable command corresponding to the current compilation toolchain.
[0011] The executable module of the IDE is allowed to pass commands to the executable program of the corresponding compilation toolchain. This allows the initial values of the configuration file of the corresponding compilation toolchain to be reloaded, the user interface to be regenerated, and the interface data to be updated when switching compilation toolchains, thus completing the dynamic switching.
[0012] A dynamic switching device for IDE adaptation to multiple compilation toolchains, the device comprising: The standardization module is used to parse the node information of the configuration file, match the UI control type, load the initial values, and generate the user interface of the UI control.
[0013] The UI interface generation module is used to parse the node information of the configuration file, match the UI control types, load the initial values, and generate the user interface for the UI controls.
[0014] The adaptation rule execution module is used to associate and save the user operation interface data through the control ID in the user operation interface, and match the interface data with the wildcards in the command generation rules according to the preset command generation rules in the configuration file to generate the allowed executable command corresponding to the current compilation toolchain.
[0015] The dynamic switching module is used to pass the executable commands to the IDE's execution module, call the corresponding compiler toolchain's executable program, so that when switching compiler toolchains, the initial values of the corresponding compiler toolchain's configuration file are reloaded, the user interface is regenerated and the interface data is updated, thus completing the dynamic switching.
[0016] A computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program performing the following steps: The basic information of each compilation toolchain, the initial values of compilation options, and the corresponding UI control types are defined through configuration files.
[0017] Parse the node information in the configuration file, match the UI control types, load the initial values, and generate the user interface for the UI controls.
[0018] In the user interface, the interface data of user operation is associated with and saved through control ID. According to the command generation rules preset in the configuration file, the interface data is matched with wildcards in the command generation rules to generate the executable command corresponding to the current compilation toolchain.
[0019] The executable module of the IDE is allowed to pass commands to the executable program of the corresponding compilation toolchain. This allows the initial values of the configuration file of the corresponding compilation toolchain to be reloaded, the user interface to be regenerated, and the interface data to be updated when switching compilation toolchains, thus completing the dynamic switching.
[0020] The aforementioned method, apparatus, and device for dynamically switching between multiple compilation toolchains in an IDE utilize configuration files as an intermediate carrier. By defining the basic information of each toolchain, initial values of compilation options, and control types, it decouples the compilation toolchain information from the IDE execution module. This eliminates the need to modify the IDE core code; toolchains can be added or switched solely through configuration files, significantly reducing adaptation difficulty. Furthermore, by parsing the configuration file to automatically match control types and generate a user interface, professional compilation options are transformed into visual operation controls. Users do not need to master command syntax; configuration can be completed solely through interface interaction. Using control ID association data and wildcard matching rules, execution commands for the target toolchain are automatically generated, avoiding errors and compatibility issues from manually writing commands. When switching toolchains, only the initial values of the corresponding configuration file need to be reloaded to repeat the interface generation and command processing process, achieving dynamic switching with zero code modification. The entire technical process replaces hard coding with configuration-driven approaches and manual command writing with visual interaction, solving the pain points of traditional IDEs' single toolchain adaptation and difficult decoupling, while reducing the learning cost and operational threshold for user configuration. Ultimately, it significantly improves the configuration efficiency of multiple compilation toolchains and reduces configuration costs. Attached Figure Description
[0021] Figure 1 This is a flowchart illustrating a method for dynamically switching between multiple compilation toolchains in IDE adaptation, as shown in one embodiment. Figure 2 This is a flowchart illustrating the dynamic switching steps of the compilation toolchain in an integrated development environment in one embodiment. Figure 3 This is a schematic diagram of the data flow processing mechanism between modules in one embodiment; Figure 4 This is a structural block diagram of a dynamic switching device for IDE adaptation to multiple compilation toolchains in one embodiment; Figure 5 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation
[0022] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.
[0023] In one embodiment, such as Figure 1 As shown, a method for dynamically switching between multiple compilation toolchains in IDE adaptation is provided, including the following steps: Step 102: Define the basic information of each compilation toolchain, the initial values of compilation options, and the corresponding interface control types through the configuration file.
[0024] Step 104: Parse the node information of the configuration file, match the interface control type, load the initial values, and generate the user interface of the interface control.
[0025] Step 106: In the user interface, the user operation interface data is associated with and saved through the control ID. According to the command generation rules preset in the configuration file, the interface data is matched with the wildcards in the command generation rules to generate the executable command corresponding to the current compilation toolchain.
[0026] Step 108 allows the execution module of the IDE to pass the execution command to call the execution program of the corresponding compilation toolchain, so that when switching compilation toolchains, the initial value of the configuration file of the corresponding compilation toolchain is reloaded, the user interface is regenerated and the interface data is updated, thus completing the dynamic switching.
[0027] Specific The aforementioned method for dynamically switching between multiple compilation toolchains in an IDE uses a configuration file as an intermediary. By defining the basic information of each toolchain, initial values of compilation options, and control types, it decouples the compilation toolchain information from the IDE execution module. This eliminates the need to modify the IDE core code; toolchains can be added or switched solely through the configuration file, significantly reducing adaptation difficulty. Furthermore, by parsing the configuration file, it automatically matches control types and generates a user interface, transforming professional compilation options into visual operation controls. Users don't need to master command syntax; they can complete configuration simply through interface interaction. Using control ID association data and wildcard matching rules, it automatically generates execution commands for the target toolchain, avoiding errors and compatibility issues from manually writing commands. When switching toolchains, simply reloading the initial values of the corresponding configuration file repeats the interface generation and command processing process, achieving dynamic switching with zero code modification. This entire technical process replaces hard coding with configuration-driven approaches and manual command writing with visual interaction, solving the pain points of traditional IDEs' single toolchain adaptation and difficult decoupling, while reducing the learning cost and operational threshold for users. Ultimately, it significantly improves the configuration efficiency of multiple compilation toolchains and reduces configuration costs.
[0028] In one embodiment, the configuration file is an XML file that contains initial values for compilation options, UI control types, and wildcard mapping relationships for command generation rules.
[0029] In one embodiment, the interface control types include input boxes, drop-down boxes, check boxes, tables, and path input boxes.
[0030] In one embodiment, the command generation rule associates UI control IDs with wildcards, and the wildcard parameter corresponds to the user input value of the UI control.
[0031] In one embodiment, when switching the compilation toolchain, the user input values of the current interface controls are cleared, the initial values defined in the configuration file for the new compilation toolchain are loaded, and the user interface is refreshed to display the new initial values.
[0032] In one embodiment, when adapting to a new compilation toolchain, only the corresponding XML format configuration file for the compilation toolchain needs to be added, without modifying the IDE execution module.
[0033] In one embodiment, such as Figure 2 As shown, a dynamic switching step for the compilation toolchain in an integrated development environment is provided, the details of which are as follows: To facilitate user operation, the final interface presented to the user is a simple UI. This interface is generated by developers configuring an XML file and allows users to select commonly used compilation options and display them to the user in simple ways such as dropdown lists and checkboxes. Interface types include input boxes, dropdown lists, checkboxes, tables, and path input boxes.
[0034] To facilitate integration with other build toolchains by vendors without requiring extensive modifications, a simple XML configuration method is provided to generate the interface. The `buildSetting.xml` file configures basic information about various build toolchains (initial values for various common build options, the interface format for displaying these options to the user, and the logic by which user-defined values are returned to the execution module).
[0035] The UI template only needs to implement the specified input boxes, dropdown lists, and other controls. By analyzing the nodes in buildSetting.xml, the UI type is determined, and initial values are loaded. Each time the build toolchain is switched, the corresponding initial configuration is loaded to ensure compilation can proceed immediately after the switch. Each control has a unique ID, and data is stored using the ID and the control's value. Rules are formed based on commands in buildSetting. The rule format is as follows: iasmarm${OUTPUT_FLAG}${OUTPUT_PREFIX}${OUTPUT}${INPUTS} This is a rule for generating an assembly compilation command in the IAR compiler toolchain. The parameters inside the $ symbol correspond to the IDs of page controls. Ultimately, based on the values in the interface, an assembly compilation command from the IAR compiler toolchain will be generated. Of course, functions such as C / C++ compilation, linking to ELF files, and converting to Hex or Bin files all simply call the compiler toolchain's own executor; the remaining task is to generate the corresponding parameters and assemble them into a script command.
[0036] The execution module can be a custom-developed command-line executor or an IDE from various vendors. In fact, the final compilation logic of an IDE involves calling the compiler's toolchain execution program. Once we can generate executable commands, the IDE can dynamically switch between compiler toolchains for compilation simply by executing those commands.
[0037] In one embodiment, such as Figure 3 As shown, a data flow processing mechanism between modules is provided, the details of which are as follows: The XML parsing module can obtain configurations for various build chains, each of which generates three types of data: 1. Interface style and input box IDs 2. Initial value corresponding to the input box ID 3. Rules that can generate commands These three types of data correspond to the name (unique identifier) of the compilation chain.
[0038] Data processing module: Saves data 2 and data 3 to the hard drive as files; passes data 1 and data 2 to the operation page module.
[0039] The user interface module retrieves the names of all compilation chains from the data processing module and displays them in a dropdown menu. When switching compilation chains via the dropdown menu... Data 1 and 2 are retrieved from the data processing module based on the unique identifier of the compilation chain to generate the page, and data 2 is displayed in the input box according to its ID.
[0040] After the user modifies the content in the input box on the page and clicks save, Data 2 will be saved to a hard drive file through the data processing module.
[0041] Command generation module: Retrieves data 2 and 3 from the data processing module based on the current compilation chain. Data 3 is a rule, which is used to generate a command by supplementing wildcards based on data 2.
[0042] For example, wildcards are as follows: iasmarm${OUTPUT_FLAG}${OUTPUT_PREFIX}${OUTPUT}${INPUTS} OUTPUT_FLAG: --cpu Cortex-M7 --fpu VFPv5_d16 OUTPUT_PREFIX:-D_IAR_C_ALIOTHXX_ OUTPUT_PREFIX: xx.o INPUTS:xx.s The command is then generated as follows: iasmarm --cpu Cortex-M7 --fpu VFPv5_d16 -D_IAR_C_ALIOTHXX_xx.o xx.s Execution module: Simply retrieve the generated commands from the command generation module and execute them.
[0043] It should be understood that, although Figure 1 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 1At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.
[0044] In one embodiment, such as Figure 4 As shown, a dynamic switching device for IDE adaptation to multiple compilation toolchains is provided, including: a standardization module 402, a UI interface generation module 404, an adaptation rule execution module 406, and a dynamic switching module 408, wherein: Standardization module 402 is used to define the basic information of each compilation toolchain, the initial values of compilation options, and the corresponding interface control types through configuration files.
[0045] The UI interface generation module 404 is used to parse the node information of the configuration file, match the interface control type, load the initial value, and generate the user interface of the interface control.
[0046] The adaptation rule execution module 406 is used to associate and save the user operation interface data through the control ID in the user operation interface, and match the interface data with the wildcards in the command generation rules according to the preset command generation rules in the configuration file to generate the allowed executable command corresponding to the current compilation toolchain.
[0047] The dynamic switching module 408 is used to pass the executable command to the IDE's execution module, call the corresponding compiler toolchain's executable program, so that when switching compiler toolchains, the initial values of the corresponding compiler toolchain's configuration file are reloaded, the user interface is regenerated and the interface data is updated, thus completing the dynamic switching.
[0048] Specific limitations regarding the dynamic switching mechanism for IDE adaptation of multiple compilation toolchains can be found in the above section on the limitations of the dynamic switching method for IDE adaptation of multiple compilation toolchains, and will not be repeated here. Each module in the aforementioned dynamic switching mechanism for IDE adaptation of multiple compilation toolchains can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in hardware or independent of the processor in the computer device, or stored in software in the memory of the computer device, so that the processor can call and execute the operations corresponding to each module.
[0049] In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 4As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements a dynamic switching method for IDE-compatible multi-compilation toolchains. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad mounted on the computer device casing, or an external keyboard, touchpad, or mouse.
[0050] Those skilled in the art will understand that Figure 3-4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.
[0051] In one embodiment, a computer device is provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to perform the following steps: The basic information of each compilation toolchain, the initial values of compilation options, and the corresponding UI control types are defined through configuration files.
[0052] Parse the node information in the configuration file, match the interface control types, load the initial values, and generate the UI interface for user operation controls.
[0053] In the UI, user interaction data is associated with and saved through control IDs. Based on the command generation rules in the configuration file, the UI data is matched with wildcards to generate the execution commands corresponding to the compilation toolchain.
[0054] The execution command is passed to the IDE's execution module, which calls the executor of the corresponding compilation toolchain. This ensures that when switching compilation toolchains, the initial values of the configuration file for the corresponding compilation toolchain are reloaded, and the UI interface and user operation data are repeatedly generated, thus completing the dynamic switching.
[0055] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.
[0056] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.
[0057] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.
Claims
1. A method for dynamically switching between multiple compilation toolchains in an IDE, characterized in that, The method includes: The basic information of each compilation toolchain, the initial values of compilation options, and the corresponding UI control types are defined through configuration files. The node information of the configuration file is parsed, the interface control type is matched, the initial value is loaded, and the user interface of the interface control is generated. In the user interface, the interface data of the user operation is associated with and saved through the control ID. According to the command generation rules preset in the configuration file, the interface data is matched with the wildcards in the command generation rules to generate the executable command corresponding to the current compilation toolchain. The command to allow execution is passed to the execution module of the IDE, which calls the executor of the corresponding compilation toolchain. This allows the initial values of the configuration file of the corresponding compilation toolchain to be reloaded when switching compilation toolchains, the user interface to be regenerated and the interface data to be updated, thus completing the dynamic switching.
2. The method according to claim 1, characterized in that, The configuration file is in XML format and contains the initial values of compilation options, interface control types, and wildcard mapping relationships for command generation rules.
3. The method according to claim 1, characterized in that, The types of interface controls include input boxes, drop-down boxes, check boxes, tables, and path input boxes.
4. The method according to any one of claims 1 to 3, characterized in that, The command generation rule associates UI control IDs with wildcards, and the wildcard parameters correspond to the user input values of the UI controls.
5. The method according to claim 4, characterized in that, When switching the compilation toolchain, the initial values of the corresponding compilation toolchain's configuration file are reloaded, including: When switching the compilation toolchain, the user input values of the current interface controls are cleared, the initial values defined in the configuration file for the new compilation toolchain are loaded, and the user interface is refreshed to display the new initial values.
6. The method according to claim 5, characterized in that, When adapting to a new compilation toolchain, you only need to add a new XML configuration file for the corresponding compilation toolchain; there is no need to modify the IDE execution module.
7. A dynamic switching device for IDE adaptation to multiple compilation toolchains, characterized in that, The device includes: The standardization module is used to define the basic information of each compilation toolchain, the initial values of compilation options, and the corresponding UI control types through configuration files; The UI interface generation module is used to parse the node information of the configuration file, match the interface control type, load the initial value, and generate the user interface of the interface control. The adaptation rule execution module is used to associate and save the interface data of user operation through control ID in the user operation interface, and match the interface data with wildcards in the command generation rules according to the preset command generation rules in the configuration file to generate the allowed execution command corresponding to the current compilation toolchain. The dynamic switching module is used to pass the allowed execution command to the IDE's execution module, call the corresponding compiler toolchain's execution program, so that when switching the compiler toolchain, the initial value of the corresponding compiler toolchain's configuration file is reloaded, the user interface is regenerated and the interface data is updated, thus completing the dynamic switching.
8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.