[发明专利]跨语言编译方法、装置、电子设备和存储设备

说明书

本发明的实施方式提供了一种跨语言编译方法、装置、电子设备和存储设备。该方法，包括：响应于组件库为Framework静态库组件，根据预设执行脚本生成所述Framework静态库组件对应的第一模块化文件，以得到模块化后的Framework静态库组件，所述模块化后的Framework静态库组件能够用于组件打包；响应于组件库为第三方静态库组件，根据预设插件生成第三方静态库组件对应的第二模块化文件，以得到模块化后的第三方静态库组件，所述模块化后的第三方静态库组件能够用于组件集成；其中，所述模块化后的Framework静态库组件或所述模块化后的第三方静态库组件能够由Swift语言调用。本发明的使得组件可以支持Swift混编调用，避免出现编译错误，节省大量的人力资源，实现高效的跨语言编译。

技术领域

本发明的实施方式涉及计算机技术领域，更具体地，本发明的实施方式涉及跨语言编译方法、装置、电子设备和存储设备。

背景技术

本部分旨在为本发明的实施方式提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。

目前iOS生态主要有两种编程语言Objective-C(扩充C的面向对象编程语言)和Swift，在新业务使用Swift编码时，依然有调用Objective-C组件库的需求，称为组件之间跨语言的混编。

Objective-C组件库要实现能够被Swift调用，需要完成模块化。目前大量Objective-C组件库想要支持Swift混编，常规的解决方案是通过设置编译选项“DEFINES_MODULE＝YES”，对源码组件进行重新编译，在理想情况下，这种方案成功编译的产物是支持模块化的。但在实际实施中，由于组件源码会以独立的上下文进行编译，在编译过程中如果组件源码有依赖于上下文的场景，源码组件的编译方式会发生改变，可能出现各种编译问题，比如：宏定义代码找不到的编译错误；头文件引用不规范报错；PCH(PrecompiledHeader，预编译头文件)引入的上下文丢失；第三方静态库无法构建modulemap文件。

通过上述方案会带来各种编译问题，需要手动解决一系列的编译错误，耗费大量人力和时间，导致跨语言编译改造成本高，效率低。

发明内容

对组件源码进行重新编译的过程中，由于组件源码使用独立的上下文空间进行模块化编译，当组件源码有依赖于上下文的场景时，就无法成功编译出支持模块化的产物，会出现大量的编译错误。

因此在现有技术中，大量的编译错误需要逐一手动去解决，这是非常令人烦恼的过程。

为此，非常需要一种改进的组件模块化方案，以使组件支持Swift混编调用。

在本上下文中，本公开的实施方式期望提供一种跨语言编译方法、装置、电子设备和存储设备。

在本公开实施方式的第一方面中，提供了一种跨语言编译方法，包括：响应于组件库为Framework静态库组件，根据预设执行脚本生成所述Framework静态库组件对应的第一模块化文件，以得到模块化后的Framework静态库组件，所述模块化后的Framework静态库组件能够用于组件打包；响应于组件库为第三方静态库组件，根据预设插件生成第三方静态库组件对应的第二模块化文件，以得到模块化后的第三方静态库组件，所述模块化后的第三方静态库组件能够用于组件集成；所述模块化后的Framework静态库组件或所述模块化后的第三方静态库组件能够由Swift语言调用。