Computer-implemented method, computer system and computer program for managing ports of a software project

The method automates the process of software porting by comparing hashes and analyzing function calls and syntax trees to efficiently update downstream files on heterogeneous platforms, addressing inefficiencies in existing porting methods.

JP2026004226APending Publication Date: 2026-01-14INTERNATIONAL BUSINESS MACHINE CORPORATION
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
JP2025092073
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Priority Date
2024-06-25
Filing Date
2025-06-02
Publication Date
2026-01-14

AI Technical Summary

Technical Problem

Existing software porting processes are inefficient and cumbersome, particularly when adapting software to run on heterogeneous computing platforms, as they fail to automatically synchronize changes between upstream and downstream files, leading to manual and complex updates.

Method used

A computer-implemented method that compares hashes of content between upstream and downstream files, applies changes automatically, and sends notifications to developers, utilizing function call graph and abstract syntax tree analysis for precise platform-specific updates.

Benefits of technology

Enhances the efficiency of software porting by automatically identifying and applying necessary changes to downstream files, improving functionality on heterogeneous platforms and reducing manual intervention.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2026004226000001_ABST
    Figure 2026004226000001_ABST
Patent Text Reader

Abstract

To provide management of software project ports.SOLUTION: A comparison of a second hash of content in an upstream file corresponding to the computing platform of the parent software project with a first hash of the content in the upstream file retrieved from a hash-based comment inserted into a downstream platform-specific file corresponding to the heterogeneous computing platform is performed. Based on the comparison, a determination is made to apply the set of changes made to the upstream file to the downstream platform-specific file. A notification is sent to a developer of the downstream platform-specific files regarding the set of changes made to the upstream files.SELECTED DRAWING: Figure 3
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] The disclosure relates generally to porting, and more particularly to managing ports of a software project. Summary of the Invention [Problem to be solved by the invention]

[0002] Porting is the process of adapting software to run on a computing platform, architecture, or environment (e.g., a different processor, operating system, third-party libraries, etc.) that is different from the computing platform for which the software was originally designed. [Means for solving the problem]

[0003] According to one exemplary embodiment, a computer-implemented method for managing software project ports is provided. The computer performs a comparison of a second hash of content in an upstream file corresponding to a computing platform of a parent software project with a first hash of the content in the upstream file, the first hash being extracted from a hash-based comment inserted in a downstream platform-specific file corresponding to a heterogeneous computing platform. The computer determines to apply a set of changes made to the upstream file corresponding to the computing platform of the parent software project to the downstream platform-specific file corresponding to the heterogeneous computing platform based on the comparison of the second hash of the content in the upstream file with the first hash of the content in the upstream file, the first hash being extracted from the hash-based comment inserted in the downstream platform-specific file. The computer sends a notification to a developer of the downstream platform-specific file corresponding to the heterogeneous computing platform regarding the set of changes made to the upstream file corresponding to the computing platform of the parent software project on which the downstream platform-specific file was based. According to other exemplary embodiments, a computer system and a computer program product for managing software project ports are provided. [Brief explanation of the drawings]

[0004] [Figure 1] 1 is a pictorial representation of a computing environment in which an exemplary embodiment may be implemented.

[0005] [Figure 2] 1 is a diagram illustrating an example of a hash-based comment insertion process according to an example embodiment.

[0006] [Figure 3] 1 is a diagram illustrating an example of a hash comparison process according to an example embodiment.

[0007] [Figure 4] 1 is a diagram illustrating an example of an abstract syntax tree according to an exemplary embodiment.

[0008] [Figure 5A] 1 is a flowchart illustrating a process for managing software project ports according to an example embodiment. [Figure 5B] 1 is a flowchart illustrating a process for managing software project ports according to an example embodiment.

[0009] [Figure 6A] 10 is a flowchart illustrating a process for determining platform-specific implementation changes at the function level by performing function call graph analysis according to an example embodiment. [Figure 6B] 10 is a flowchart illustrating a process for determining platform-specific implementation changes at the function level by performing function call graph analysis according to an example embodiment. [Figure 6C] 10 is a flowchart illustrating a process for determining platform-specific implementation changes at the function level by performing function call graph analysis according to an example embodiment.

[0010] [Figure 7A] 10 is a flowchart illustrating a process for determining platform-specific implementation changes at the statement level for a given function by performing abstract syntax tree analysis according to an example embodiment. [Figure 7B]10 is a flowchart illustrating a process for determining platform-specific implementation changes at the statement level for a given function by performing abstract syntax tree analysis according to an example embodiment. [Figure 7C] 10 is a flowchart illustrating a process for determining platform-specific implementation changes at the statement level for a given function by performing abstract syntax tree analysis according to an example embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0011] A computer-implemented method provides software project port management. The computer performs a comparison of a second hash of content in an upstream file corresponding to a computing platform of a parent software project with a first hash of the content in the upstream file, the first hash being extracted from a hash-based comment inserted in a downstream platform-specific file corresponding to a heterogeneous computing platform. The computer determines to apply a set of changes made to the upstream file corresponding to the computing platform of the parent software project to the downstream platform-specific file corresponding to the heterogeneous computing platform based on the comparison of the second hash of the content in the upstream file with the first hash of the content in the upstream file, the first hash being extracted from the hash-based comment inserted in the downstream platform-specific file. The computer sends a notification to a developer of the downstream platform-specific file corresponding to the heterogeneous computing platform regarding the set of changes made to the upstream file corresponding to the computing platform of the parent software project on which the downstream platform-specific file was based. As a result, the illustrative embodiments provide the technical effect of determining to apply a set of changes made to an upstream file corresponding to a computing platform of a parent software project to a downstream platform-specific file corresponding to a heterogeneous computing platform based on a comparison of a hash of content in the upstream file with a hash of content in the upstream file extracted from a hash-based comment inserted in the downstream platform-specific file, thereby increasing the efficiency of identifying changes to upstream files that need to be applied to downstream platform-specific files corresponding to heterogeneous computing platforms for porting.

[0012] Additionally, the computer automatically implements, in the downstream platform-specific files corresponding to the heterogeneous computing platform, the set of changes made to the upstream files corresponding to the computing platform of the parent software project. As a result, exemplary embodiments provide the technical effect of automatically implementing, in the downstream platform-specific files corresponding to the heterogeneous computing platform, the set of changes made to the upstream files corresponding to the computing platform of the parent software project, thereby improving functionality of the heterogeneous computing platform because software is automatically configured to run on the heterogeneous computing platform.

[0013] Additionally, the computer determines that the downstream platform-specific file corresponding to the heterogeneous computing platform is related to the upstream file corresponding to the computing platform of the parent software project based on the number of common functions and constant variables between the downstream platform-specific file and the upstream file exceeding a specified minimum commonality threshold level. Based on determining that the downstream platform-specific file corresponding to the heterogeneous computing platform is related to the upstream file, the computer generates the first hash of the content in the upstream file corresponding to the computing platform of the parent software project. In response to generating the first hash of the content in the upstream file corresponding to the computing platform of the parent software project, the computer inserts the hash-based comment into the downstream platform-specific file corresponding to the heterogeneous computing platform. The hash-based comment includes the first hash of the content in the upstream file. As a result, the exemplary embodiment provides the technical effect of inserting a hash-based comment including a hash of the content in an upstream file into a downstream platform-specific file corresponding to a heterogeneous computing platform for efficient comparison of hashes.

[0014] Additionally, the computer monitors a centralized source code control repository for any changes. The computer determines whether the set of changes have been committed to the centralized source code control repository based on monitoring the centralized source code control repository for any changes. As a result, the exemplary embodiments provide the technical effect of determining whether changes have been committed to a centralized source code control repository.

[0015] Additionally, in response to the computer determining that the set of changes has been committed to the centralized source code control repository based on monitoring the centralized source code control repository for any changes, the computer generates the second hash of the content in the upstream file corresponding to the computing platform of the parent software project. The computer derives the first hash of the content in the upstream file corresponding to the computing platform of the parent software project from the hash-based comment inserted in the downstream platform-specific file corresponding to the heterogeneous computing platform. As a result, exemplary embodiments provide the technical effect of generating a second hash of the content in the upstream file corresponding to the computing platform of a parent software project and deriving the first hash of the content in the upstream file from the hash-based comment inserted in the downstream platform-specific file corresponding to the heterogeneous computing platform for efficient comparison of hashes to identify whether changes to the upstream file should be applied to the downstream platform-specific file for porting.

[0016] Additionally, the computer determines platform-specific implementation changes at the function level by performing function call graph analysis. As a result, the exemplary embodiments provide the technical effect of using function call graph analysis to determine platform-specific implementation changes at the function level.

[0017] The computer also determines platform-specific implementation changes at a statement level for a given function by performing abstract syntax tree analysis. As a result, the illustrative embodiments provide the technical effect of using abstract syntax tree analysis to determine platform-specific implementation changes at a statement level for a given function.

[0018] A computer system for managing software project ports comprises a communications fabric, a set of computer-readable storage media connected to the communications fabric, where the set of computer-readable storage media collectively store program instructions, and a set of processors connected to the communications fabric, where the set of processors execute the program instructions. The computer system performs a comparison of a second hash of content in an upstream file corresponding to a computing platform of a parent software project with a first hash of the content in the upstream file retrieved from a hash-based comment inserted in a downstream platform-specific file corresponding to a heterogeneous computing platform. The computer system determines to apply a set of changes made to the upstream file corresponding to the computing platform of the parent software project to the downstream platform-specific file corresponding to the heterogeneous computing platform based on the comparison of the second hash of the content in the upstream file with the first hash of the content in the upstream file retrieved from the hash-based comment inserted in the downstream platform-specific file. The computer system sends a notification to a developer of the downstream platform-specific file corresponding to the heterogeneous computing platform regarding the set of changes made to the upstream file corresponding to the computing platform of the parent software project on which the downstream platform-specific file is based.As a result, the illustrative embodiments provide the technical effect of determining to apply a set of changes made to an upstream file corresponding to a computing platform of a parent software project to a downstream platform-specific file corresponding to a heterogeneous computing platform based on a comparison of a hash of content in the upstream file with a hash of content in the upstream file extracted from a hash-based comment inserted in the downstream platform-specific file, thereby increasing the efficiency of identifying changes to upstream files that need to be applied to downstream platform-specific files corresponding to heterogeneous computing platforms for porting.

[0019] Additionally, the computer system automatically implements, in the downstream platform-specific files corresponding to the heterogeneous computing platform, the set of changes made to the upstream file corresponding to the computing platform of the parent software project. As a result, exemplary embodiments provide the technical effect of automatically implementing, in the downstream platform-specific files corresponding to the heterogeneous computing platform for porting, a set of changes made to the upstream file corresponding to the computing platform of the parent software project, thereby improving functionality of the heterogeneous computing platform because software is automatically configured to run on the heterogeneous computing platform.

[0020] Additionally, the computer system determines that the downstream platform-specific file corresponding to the heterogeneous computing platform is related to the upstream file corresponding to the computing platform of the parent software project based on the number of common functions and constant variables between the downstream platform-specific file and the upstream file exceeding a specified minimum commonality threshold level. Based on determining that the downstream platform-specific file corresponding to the heterogeneous computing platform is related to the upstream file, the computer system generates the first hash of the content in the upstream file corresponding to the computing platform of the parent software project. In response to generating the first hash of the content in the upstream file corresponding to the computing platform of the parent software project, the computer system inserts the hash-based comment into the downstream platform-specific file corresponding to the heterogeneous computing platform. The hash-based comment includes the first hash of the content in the upstream file. As a result, the exemplary embodiment provides the technical effect of inserting a hash-based comment including a hash of the content in the upstream file into the downstream platform-specific file corresponding to the heterogeneous computing platform for efficient comparison of hashes.

[0021] Additionally, the computer system monitors a centralized source code control repository for any changes. Based on monitoring the centralized source code control repository for any changes, the computer system determines whether the set of changes have been committed to the centralized source code control repository. As a result, the exemplary embodiments provide the technical effect of determining whether changes have been committed to a centralized source code control repository.

[0022] Additionally, in response to determining that the set of changes has been committed to the centralized source code control repository based on monitoring the centralized source code control repository for any changes, the computer system generates the second hash of the content in the upstream file corresponding to the computing platform of the parent software project. The computer system derives the first hash of the content in the upstream file corresponding to the computing platform of the parent software project from the hash-based comment inserted in the downstream platform-specific file corresponding to the heterogeneous computing platform. As a result, exemplary embodiments provide the technical effect of generating a second hash of the content in the upstream file corresponding to the computing platform of the parent software project and deriving the first hash of the content in the upstream file from the hash-based comment inserted in the downstream platform-specific file corresponding to the heterogeneous computing platform for efficient comparison of hashes to identify whether changes to the upstream file should be applied to the downstream platform-specific file for porting.

[0023] The computer system also determines platform-specific implementation changes at the function level by performing function call graph analysis. As a result, the illustrative embodiments provide the technical effect of using function call graph analysis to determine platform-specific implementation changes at the function level.

[0024] A computer program product for managing software project ports comprises a set of computer-readable storage media having program instructions collectively stored therein, the program instructions being executable by a computer. The computer performs a comparison of a second hash of content in an upstream file corresponding to a computing platform of a parent software project with a first hash of the content in the upstream file retrieved from a hash-based comment inserted in a downstream platform-specific file corresponding to a heterogeneous computing platform. The computer determines to apply a set of changes made to the upstream file corresponding to the computing platform of the parent software project to the downstream platform-specific file corresponding to the heterogeneous computing platform based on the comparison of the second hash of the content in the upstream file with the first hash of the content in the upstream file retrieved from the hash-based comment inserted in the downstream platform-specific file. The computer sends a notification to a developer of the downstream platform-specific file corresponding to the heterogeneous computing platform regarding the set of changes made to the upstream file corresponding to the computing platform of the parent software project on which the downstream platform-specific file was based.As a result, the illustrative embodiments provide the technical effect of determining to apply a set of changes made to an upstream file corresponding to a computing platform of a parent software project to a downstream platform-specific file corresponding to a heterogeneous computing platform based on a comparison of a hash of content in the upstream file with a hash of content in the upstream file extracted from a hash-based comment inserted in the downstream platform-specific file, thereby increasing the efficiency of identifying changes to upstream files that need to be applied to downstream platform-specific files corresponding to heterogeneous computing platforms for porting.

[0025] Additionally, the computer automatically implements, in the downstream platform-specific files corresponding to the heterogeneous computing platform, the set of changes made to the upstream files corresponding to the computing platform of the parent software project. As a result, exemplary embodiments provide the technical effect of automatically implementing, in the downstream platform-specific files corresponding to the heterogeneous computing platform, the set of changes made to the upstream files corresponding to the computing platform of the parent software project, thereby improving functionality of the heterogeneous computing platform because software is automatically configured to run on the heterogeneous computing platform.

[0026] Additionally, the computer determines that the downstream platform-specific file corresponding to the heterogeneous computing platform is related to the upstream file corresponding to the computing platform of the parent software project based on the number of common functions and constant variables between the downstream platform-specific file and the upstream file exceeding a specified minimum commonality threshold level. Based on determining that the downstream platform-specific file corresponding to the heterogeneous computing platform is related to the upstream file, the computer generates the first hash of the content in the upstream file corresponding to the computing platform of the parent software project. In response to generating the first hash of the content in the upstream file corresponding to the computing platform of the parent software project, the computer inserts the hash-based comment into the downstream platform-specific file corresponding to the heterogeneous computing platform. The hash-based comment includes the first hash of the content in the upstream file. As a result, the exemplary embodiment provides the technical effect of inserting a hash-based comment including a hash of the content in the upstream file into the downstream platform-specific file corresponding to the heterogeneous computing platform for efficient comparison of hashes.

[0027] Additionally, a computer monitors a centralized source code control repository for any changes. Based on the monitoring of the centralized source code control repository for any changes, the computer determines whether the set of changes have been committed to the centralized source code control repository. As a result, the exemplary embodiments provide the technical effect of determining whether changes have been committed to a centralized source code control repository.

[0028] Additionally, in response to determining that the set of changes has been committed to the centralized source code control repository based on monitoring the centralized source code control repository for any changes, the computer generates the second hash of the content in the upstream file corresponding to the computing platform of the parent software project. The computer derives the first hash of the content in the upstream file corresponding to the computing platform of the parent software project from the hash-based comment inserted in the downstream platform-specific file corresponding to the heterogeneous computing platform. As a result, exemplary embodiments provide the technical effect of generating a second hash of the content in the upstream file corresponding to the computing platform of the parent software project and deriving the first hash of the content in the upstream file from the hash-based comment inserted in the downstream platform-specific file corresponding to the heterogeneous computing platform for efficient comparison of hashes to identify whether changes to the upstream file should be applied to the downstream platform-specific file for porting.

[0029] The computer also determines platform-specific implementation changes at the function level by performing function call graph analysis. As a result, the illustrative embodiments provide the technical effect of using function call graph analysis to determine platform-specific implementation changes at the function level.

[0030] The computer also determines platform-specific implementation changes at the statement level for the given function by performing abstract syntax tree analysis. As a result, the illustrative embodiments provide the technical effect of using abstract syntax tree analysis to determine platform-specific implementation changes at the statement level for the given function.

[0031] Various aspects of the present disclosure are described through text, flowcharts, block diagrams of computer systems, and / or block diagrams of machine logic included in computer program product (CPP) embodiments. For any flowchart, depending on the technology involved, operations may be performed in a different order than shown in a given flowchart. For example, again depending on the technology involved, two operations shown in successive flowchart blocks may be performed in reverse order, as a single integrated step, simultaneously, or in an at least partially overlapping manner.

[0032] A computer program product embodiment ("CPP embodiment" or "CPP") is a term used in this disclosure to describe any set of one or more storage media (also referred to as "media") collectively contained in one or more storage devices that collectively contain machine-readable code corresponding to instructions and / or data for performing the computer operations specified in a given CPP claim. A "storage device" is any tangible device that can hold and store instructions for use by a computer processor. Without limitation, the computer-readable storage medium may be an electronic storage medium, a magnetic storage medium, an optical storage medium, an electromagnetic storage medium, a semiconductor storage medium, a mechanical storage medium, or any suitable combination of the foregoing. Some known types of storage devices that include these media include diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanically encoded devices (such as punch cards or pits / lands formed on a major surface of a disk), or any suitable combination of the foregoing. Computer-readable storage media, as the term is used in this disclosure, is not to be construed as storage in the form of transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide, light pulses passing through fiber optic cables, electrical signals transmitted through wires, and / or other transmission media.As will be appreciated by those skilled in the art, data is typically moved at some infrequent time during the normal operation of a storage device, such as during access, defragmentation, or garbage collection, but the above does not make a storage device transient, as data is not transient while it is stored.

[0033] Referring now to the figures, and in particular to Figure 1, a diagram of a data processing environment is provided in which illustrative embodiments may be implemented. It is understood that Figure 1 is merely an example and is not intended to assert or imply any limitation with regard to the environments in which different embodiments may be implemented. Many modifications to the depicted environment may be made.

[0034] FIG. 1 shows a diagrammatic representation of a computing environment in which exemplary embodiments may be implemented. Computing environment 100 includes an example platform, architecture, or environment for execution of at least a portion of computer code associated with performing the inventive method of the exemplary embodiments, such as software project port management code 200. For example, software project port management code 200 detects platform-specific changes in upstream files corresponding to the computing platform of a parent software project and triggers notification to developers of downstream platform-specific files corresponding to dissimilar computing platforms, thereby enabling the developers to determine whether to apply the platform-specific changes to those downstream platform-specific files that are based on the upstream files. In other words, downstream platform-specific files corresponding to dissimilar computing platforms are based on upstream files corresponding to the computing platform of the parent software project. Thus, the upstream files are the parent files on which developers base their downstream files.

[0035] In addition to software project port management code 200, computing environment 100 includes, for example, computer 101, wide area network (WAN) 102, end user device (EUD) 103, remote server 104, public cloud 105, and private cloud 106. In this embodiment, computer 101 includes a processor set 110 (including processing circuitry 120 and cache 121), communication fabric 111, volatile memory 112, persistent storage 113 (including operating system 122 and software project port management code 200, as identified above), a peripheral device set 114 (including a user interface (UI) device set 123, storage 124, and an Internet of Things (IoT) sensor set 125), and network module 115. Remote server 104 includes a remote database 130. The public cloud 105 includes a gateway 140, a cloud orchestration module 141, a set of host physical machines 142, a set of virtual machines 143, and a set of containers 144.

[0036] Computer 101 may take the form of a mainframe computer, a quantum computer, a desktop computer, a laptop computer, a tablet computer, a smartphone, a smartwatch, or other wearable computer, or any other now known or later developed computer or mobile device capable of, for example, running a program, accessing a network, or querying a database, such as remote database 130. Remote database 130 may be, for example, a remote source code control repository. As is well understood in the field of computer technology, and depending on the technology, execution of a computer-implemented method may be distributed among multiple computers and / or multiple locations. However, in this description of computing environment 100, for purposes of brevity, the detailed discussion focuses on a single computer, specifically computer 101. While computer 101 is not shown in FIG. 1 within the cloud, it may be located within the cloud. However, computer 101 is not required to reside within the cloud except to any extent that may be expressly indicated.

[0037] Processor set 110 includes one or more computer processors of any type now known or later developed. Processing circuitry 120 may be distributed across multiple packages, e.g., multiple linked integrated circuit chips. Processing circuitry 120 may implement multiple processor threads and / or multiple processor cores. Cache 121 is memory located within the processor chip package and is typically used for data or code that should be available for fast access by threads or cores executing on processor set 110. Cache memory is typically organized into multiple levels depending on relative proximity to the processing circuitry. Alternatively, some or all caches for a processor set may be located “off-chip.” In some computing environments, processor set 110 may be designed to operate with qubits and perform quantum computing.

[0038] Computer-readable program instructions are typically loaded onto computer 101 and cause processor set 110 of computer 101 to execute a series of operational steps, thereby enabling a computer-implemented method, such that the instructions so executed instantiate the methods specified in the computer-implemented method flowcharts and / or descriptions contained herein (collectively referred to as the "invention methods"). These computer-readable program instructions are stored in various types of computer-readable storage media, such as cache 121 and other storage media discussed below. The program instructions and associated data are accessed by processor set 110 to control and direct the execution of the inventive methods. In computing environment 100, at least a portion of the instructions for executing the inventive methods of the exemplary embodiments may be stored in software project port management code 200 in persistent storage 113.

[0039] Communications fabric 111 is the signal-conducting pathway that allows various components of computer 101 to communicate with one another. Typically, this fabric is made up of switches and conductive pathways, such as those that make up buses, bridges, physical input / output ports, and the like. Other types of signal communication pathways may be used, such as fiber optic and / or wireless communication pathways.

[0040] Volatile memory 112 may be any type of volatile memory now known or later developed. Examples include dynamic random access memory (RAM) or static RAM. Typically, volatile memory 112 is characterized by random access, although this is not required unless expressly stated. In computer 101, volatile memory 112 is located in a single package and is internal to computer 101; however, alternatively or additionally, volatile memory may be distributed across multiple packages and / or located external to computer 101.

[0041] Persistent storage 113 is any form of non-volatile storage for a computer, now known or later developed. Persistent storage 113 may include, for example, a local source code control repository. The non-volatility of this storage means that stored data is maintained regardless of whether power is supplied to computer 101 and / or directly to persistent storage 113. Persistent storage 113 may be read-only memory (ROM), but typically at least a portion of persistent storage allows data to be written, data to be deleted, and data to be rewritten. Some well-known forms of persistent storage include magnetic disks and solid-state storage devices. Operating system 122 may take several forms, including various known proprietary operating systems or open-source Portable Operating System Interface-type operating systems that use a kernel.

[0042] The peripheral device set 114 includes the set of peripheral devices of the computer 101. Data communication connections between the peripheral devices and other components of the computer 101 may be implemented in various ways, such as Bluetooth® connections, Near-Field Communication (NFC) connections, connections made by cable (such as a universal serial bus (USB)-type cable), insertion-type connections (e.g., a secure digital (SD) card), connections made through a local area communication network, and even connections made through a wide area network such as the Internet. In various embodiments, the UI device set 123 may include components such as a display screen, speakers, microphones, wearable devices (such as smart glasses and smart watches), keyboards, mice, printers, touchpads, game controllers, and haptic devices. The storage 124 may be external storage, such as an external hard drive, or insertable storage, such as an SD card. The storage 124 may be persistent and / or volatile. In some embodiments, the storage 124 may take the form of a quantum computing storage device for storing data in the form of qubits. In embodiments where computer 101 is required to have a large amount of storage (e.g., computer 101 stores and manages a large database locally), in which case this storage may be provided by a peripheral storage device designed to store very large amounts of data, such as a storage area network (SAN) shared by multiple, geographically distributed computers. IoT sensor set 125 is made up of sensors that may be used in Internet of Things applications. For example, one sensor may be a thermometer and another sensor may be a motion detector.

[0043] Network module 115 is a collection of computer software, hardware, and firmware that enables computer 101 to communicate with other computers over WAN 102. Network module 115 may include hardware such as a modem or Wi-Fi® signal transceiver, software for packetizing and / or depacketizing data for communication network transmission, and / or web browser software for communicating data over the Internet. In some embodiments, the network control and network forwarding functions of network module 115 are performed on the same physical hardware device. In other embodiments (e.g., embodiments utilizing Software-Defined Networking (SDN)), the control and forwarding functions of network module 115 are performed on physically separate devices, such that the control function manages multiple different network hardware devices. Computer-readable program instructions for implementing the methods of the present invention may be downloaded to computer 101 from an external computer or external storage device, typically through a network adapter card or network interface included in network module 115.

[0044] WAN 102 is any wide area network (e.g., the Internet) capable of communicating computer data over non-local distances by any technology for communicating computer data now known or later developed. In some embodiments, WAN 102 may be replaced and / or supplemented by a local area network (LAN) designed to communicate data between devices located in a local area, such as a Wi-Fi network. WANs and / or LANs typically include copper transmission cables, optical fiber transmissions, wireless transmissions, and computer hardware such as routers, firewalls, switches, gateway computers, and edge servers.

[0045] EUD 103 is any computer system used and controlled by an end user (e.g., a developer of downstream platform-specific files for disparate computing platforms) and may take any of the forms described above in connection with computer 101. EUD 103 typically receives useful and useful data from the operation of computer 101. For example, in the hypothetical case where computer 101 is designed to provide upstream file change notification to end users, this upstream file change notification would typically be communicated over WAN 102 from network module 115 of computer 101 to EUD 103. In this manner, EUD 103 can display or otherwise present the upstream file change notification to end users. In some embodiments, EUD 103 may be a client device, such as a thin client, a heavy client, a mainframe computer, a desktop computer, a laptop computer, a tablet computer, a smartphone, or the like.

[0046] Remote server 104 is any computer system that provides at least some data and / or functionality to computer 101. Remote server 104 may be controlled and used by the same entity that operates computer 101. Remote server 104 represents a machine that collects and stores useful and useful data for use by other computers, such as computer 101. For example, in the hypothetical case where computer 101 is designed and programmed to provide upstream file change notifications based on upstream file changes committed to remote database 130, these upstream file changes committed to remote database 130 may then be communicated to computer 101 by remote server 104.

[0047] A public cloud 105 is any computer system available for use by multiple entities that provides on-demand availability of computer system resources and / or other computer functionality, particularly data storage (cloud storage) and computing power, without direct active management by users. Cloud computing typically leverages resource sharing to achieve coherence and economies of scale. Direct active management of the computing resources of the public cloud 105 is performed by computer hardware and / or software in a cloud orchestration module 141. The computing resources provided by the public cloud 105 are typically implemented by virtual computing environments running on various computers that comprise a host physical machine set 142, which is the universe of physical computers within and / or available to the public cloud 105. The virtual computing environments (VCEs) typically take the form of virtual machines from a virtual machine set 143 and / or containers from a container set 144. It is understood that these VCEs may be stored as images and transferred among and between various hosts of physical machines either as images or after instantiation of the VCE. Cloud orchestration module 141 manages the transfer and storage of images, deploys new instantiations of VCEs, and manages active instantiations of VCE deployments. Gateway 140 is a collection of computer software, hardware, and firmware that enables public cloud 105 to communicate over WAN 102.

[0048] We now provide some further explanation of virtual computing environments (VCEs). A VCE can be stored as an "image." A new, active instance of a VCE can be instantiated from the image. Two well-known types of VCEs are virtual machines and containers. A container is a VCE that uses operating system-level virtualization. This refers to a feature of an operating system in which the kernel allows the existence of multiple isolated user space instances, called containers. These isolated user space instances typically behave as actual computers from the perspective of programs running within them. A computer program running on a typical operating system can utilize all of the computer's resources, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, a program running inside a container can only use the contents of the container and of the devices assigned to the container; this feature is known as containerization.

[0049] A private cloud 106 is similar to a public cloud 105, except that computing resources are available for use only by a single entity. While the private cloud 106 is shown in communication with the WAN 102, in other embodiments, the private cloud may be completely disconnected from the Internet and accessible only through a local / private network. A hybrid cloud is a composite of multiple clouds of different types (e.g., private, community, or public cloud types), often implemented by different vendors. While each of the multiple clouds remains a separate, discrete entity, the larger hybrid cloud architecture is bound together by standardized or proprietary technologies that enable orchestration, management, and / or data / application portability between the constituent clouds. In this embodiment, both the public cloud 105 and the private cloud 106 are part of a larger hybrid cloud.

[0050] Public cloud 105 and private cloud 106 are programmed and configured to provide cloud computing services and / or microservices (not separately shown in FIG. 1 ). Unless otherwise indicated, the term “microservices” should be interpreted to include larger “services” regardless of scale. Cloud services are typically infrastructure, platforms, or software hosted by a third-party provider and made available to users over the Internet. Cloud services facilitate the flow of user data from front-end clients (e.g., user-side servers, tablets, desktops, and laptops) over the Internet to the provider's systems and vice versa. In some embodiments, cloud services can be configured and orchestrated according to the “as a service” technology paradigm, where something is presented to internal or external customers in the form of cloud computing services. As-a-service offerings typically provide endpoints with which various customers interface. These endpoints are typically based on a set of application programming interfaces (APIs). One category of as-a-service offerings is Platform as a Service (PaaS), where a service provider provisions, instantiates, runs, and manages modular bundles of code that customers can use to instantiate a computing platform and one or more applications without the complexities of building and maintaining the infrastructure typically associated with these. Another category is Software as a Service (SaaS), where software is centrally hosted and allocated on a subscription basis. SaaS is also known as on-demand software, web-based software, or web-hosted software.The four technology subfields involved in cloud services are deployment, integration, on-demand, and virtual private networks.

[0051] As used herein, when used in reference to items, a "set of" means one or more of those items. For example, a set of clouds is one or more different types of cloud environments. Similarly, when used in reference to items, a "number of" means one or more of those items. Also, a "group of" or "plurality of" when used in reference to items means two or more of those items.

[0052] Furthermore, the term "at least one of," when used in conjunction with a list of items, means that different combinations of one or more of the listed items may be used, and only one of each item in the list may be required. In other words, "at least one" means that any combination of the items and number of items in the list may be used, but not all items in the list are required. An item may be a particular object, thing, or category.

[0053] For example, without limitation, "at least one of item A, item B, or item C" may include item A, item A and item B, or item B. This example may also include item A, item B and item C, or item B and item C. Of course, any combination of these items may be present. In some illustrative examples, "at least one" may be, without limitation, for example, two of item A, one of item B, ten of item C, four of item B and seven of item C, or other suitable combinations.

[0054] When a developer creates a new software project based on an existing software project, the developer may sometimes find that the program code of the new software project cannot be integrated into the existing parent software project. For example, the developer wants to port the existing parent open source software project to a new, dissimilar computing platform that is different from the computing platform for which the existing parent open source software project was originally designed. However, the existing parent software project cannot incorporate the changes required to support the new, dissimilar computing platform. In addition, the existing parent software project continues to evolve daily with changes to the program code, such as adding features and fixing bugs. One challenge that arises in a child software project is that the child software project tries to keep up with the evolution of the existing parent software project. The problem is that as changes are made to upstream files corresponding to the existing parent software project, those upstream file changes fail to be made to local downstream files in the local repository corresponding to the child software project associated with the new, dissimilar computing platform.

[0055] There are two common ways to change or modify the program code of a software project that is adapted to a new heterogeneous computing platform. The first way is to add new files containing platform-specific program code to the software project that is being ported to the new heterogeneous computing platform. The second way is to apply the platform-specific program code to a section of the software project that detects on which computing platform the program code is running.

[0056] As an example of the first method, assume that an upstream file "blah.go" located in a centralized repository has been copied into a local downstream platform-specific file blah.PLAT.go on a local repository, with the downstream platform-specific file blah.PLAT.go containing appropriate changes specifically for a particular type of computing platform. Note that the GO® (registered trademark of Google LLC, Mountain View, California, USA) programming language is intended merely as an example and not as a limitation on the exemplary embodiments. For example, the exemplary embodiments are applicable to any type of programming language for any type of computing platform. Also assume that a bug is detected and fixed in the upstream file blah.go. The upstream file blah.go continues to change as developers incorporate the changes from the upstream file blah.go into the local downstream platform-specific file blah.PLAT.go associated with the new, disparate computing platform. However, the developer of the local downstream platform-specific file blah.PLAT.go may miss these recent changes to the upstream file blah.go.

[0057] Similarly, in the second approach, even if there is a single upstream file blah.go with some sections that apply only to particular types of computing platforms (e.g., in the GO programming language, this is accomplished in the GOOS=PLAT section, in the C programming language, this is accomplished with #IFDEF, etc.), when changes are made to the single upstream file blah.go, it is important that the platform-specific sections of downstream files do not miss out on receiving the appropriate changes corresponding to bug fixes.

[0058] As a result, the developer must analyze two things: 1) the changes that the platform-specific downstream file copies from the upstream file; and 2) whether the changes need to be applied to the platform-specific sections of a single downstream file. Note that even if such upstream file changes are identified as applying to the local downstream file or the platform-specific sections of the local downstream file associated with a new, heterogeneous computing platform, the developer may still need to manipulate the changes to fit the new, heterogeneous computing platform.

[0059] In the first scenario, a developer needs to identify all platform-specific downstream files that are not present in the upstream file of the existing parent software project and any associated files for the platform-specific downstream files that are present in the upstream file of the existing parent software project. Next, the developer needs to determine whether updates applied to the associated files need to be applied to the platform-specific downstream files. However, identifying the correct associated files is not a simple task. For example, assume that the file blah.go is a platform-specific file for the z / operating system (OS) platform. In the upstream file corresponding to the existing parent software project, there may be files such as the file blah.go, the file "blah_unix.go," the file "blah_linux.go," and so on. However, some challenges arise with this approach. For example, the upstream file of the existing parent software project is a file named blah_unix.go, which has subfiles such as the subfile blah_linux.go and the subfile "blah_zos.go." The parent upstream file contains common program code, while the downstream files contain platform-specific implementation program code. On the other hand, the file blah_unix.go may be the upstream file version of a platform-specific file, such as the file blah_zos.go. Thus, the file name itself is not a good indicator that there is a file to track.

[0060] In the second scenario, the platform-specific section of the program code is typically written in an if-else statement, where we check if OS==Platform, and then apply the platform-specific program code and the original common program code of the parent software project within the if-else statement. For example: if runtime.GOOS=="zos"{ return zosDbgTmp() }else { return gccTmp() }.

[0061] Changes released in upstream files of an existing parent software project require developers to synchronize downstream files that have been locally modified by developers of the existing parent software project with the changes to the upstream files. These upstream file changes may affect various sections of the program code. Managing these upstream file changes becomes increasingly complex as the program code contains multiple if-else statements.

[0062] In the second scenario above, if an originator working on an upstream file in a parent software project changes the implementation in function gccTmp(), the developer of the downstream z / OS platform-specific file must check whether the upstream file update for function zosDbgTmp() requires synchronization with function gccTmp(). As a result, the developer must manually perform the update review, which significantly reduces efficiency.

[0063] Exemplary embodiments enable a process whereby, when integrated from a distributed source code control system such as, for example, Github® (a registered trademark of Github Inc., San Francisco, California, USA), upstream file changes trigger notifications or alerts that refer developers to alternative files or alternative code sections of files, allowing developers working on downstream platform-specific files to investigate whether the upstream file changes apply to a target computing platform. First, exemplary embodiments utilize a difference comparison tool to perform a comparison of program code text sections (e.g., a comparison of files or specific sections of files). Second, exemplary embodiments enhance the comparison of program code text sections performed by the difference comparison tool by performing function call graph analysis to determine platform-specific implementation changes at the function level. Third, exemplary embodiments perform abstract syntax tree analysis to determine platform-specific implementation changes at the statement level for a given function. Additionally, exemplary embodiments utilize an automatic patching method whereby the exemplary embodiments automatically integrate program code changes made in upstream files into downstream program-specific files, regardless of whether developer notifications are triggered.

[0064] Exemplary embodiments insert a hash-based comment into each target downstream platform-specific file or each platform-specific section of a target downstream platform-specific file. The content of the hash-based comment includes, for example, the name of the upstream file on which the target downstream platform-specific file or platform-specific section of the target downstream platform-specific file was based, and a hash (e.g., SHA2 hash, SHA3 hash, MD5 hash, etc.) of the upstream file's contents since the upstream file was last changed, updated, or modified. After exemplary embodiments integrate the upstream file changes into the target local downstream platform-specific file, the exemplary embodiments determine whether the upstream file on which the particular target downstream platform-specific file was based has changed by checking all downstream platform-specific files that contain such hash-based comments. If the exemplary embodiment determines that the upstream file has changed, the exemplary embodiment generates a notification to the developer and examines the upstream file changes to determine whether the upstream file changes need to be rewritten into the particular target downstream platform-specific file.

[0065] More specifically, the exemplary embodiments insert hash-based comments into target downstream platform-specific files, thereby enabling the exemplary embodiments to automatically track changes to upstream files to which the target downstream platform-specific files may be related. The hash-based comments include a mathematical hash of the most recently modified contents of the named parent upstream file, along with the name of the parent upstream file and the path to it. For example, the downstream platform-specific file blah_zos.go is based on the parent upstream file blah.go. As a result, the downstream platform-specific file blah_zos.go includes a hash-based comment that includes the name of the parent upstream file blah.go and the path to it, along with the mathematical hash of the contents of the parent upstream file blah.go since the parent upstream file blah.go was last modified. If the contents of the parent upstream file blah.go are changed, the exemplary embodiments can detect the change due to the change in the hash of the contents. Each time an originator working on a parent software project commits an upstream file change to a distributed source code control system (e.g., a centralized repository), the exemplary embodiment checks all hashes present in hash-based comments of downstream platform-specific files in the distributed source code control system against newly generated hashes of the contents of the parent upstream file (e.g., blah.go) named in one or more of the hash-based comments in the distributed source code control system. If the exemplary embodiment determines that the hash of the parent upstream file has changed based on the hash comparison, the exemplary embodiment sends a notification to the developer indicating that the change to the parent upstream file requires investigation for applicability to downstream platform-specific versions of the parent upstream file.

[0066] While the exemplary embodiments work when inserting hash-based comments into downstream platform-specific files from the beginning of a parent upstream file's program code branch, the exemplary embodiments are also applicable to software projects that have already been running for some time. The key is for the exemplary embodiments to determine which upstream files may be appropriate files to be tracked, typically based on a difference measurement with the downstream platform-specific file. In any given downstream platform-specific file, the exemplary embodiments can use up to a specified number of hash-based comments (e.g., 5) containing the name of the parent upstream file, ordered by the degree of difference compared to the parent upstream file. The exemplary embodiments measure the degree of difference based on the difference in the names of common functions and the difference in the content of those common functions. The exemplary embodiments measure the difference in the content of common functions based on the number of program code line additions and program code line subtractions identified by a difference comparison tool. While the exemplary embodiments can invoke a difference comparison tool to perform the difference degree measurement, the exemplary embodiments can also use a programmatic approach to perform the difference comparison. In determining which upstream files are included in the specified number of top-level upstream files (e.g., 5), exemplary embodiments give priority to some upstream files named in hash-based comments even if their names have little or no similarity. For example, exemplary embodiments may track changes to the upstream file blah_linux.go even if the file name has nothing in common with the name of the downstream file blah_zos.go, because exemplary embodiments should examine any changes to the upstream file blah_linux.go to determine whether the changes may indirectly affect the downstream file blah_zos.go.

[0067] Based on this degree-of-difference-based approach, the illustrative embodiments can determine whether the implementation of any function in a path starting from the current program code section in the function call graph has changed by searching the function call graph for platform-specific changes. If the illustrative embodiments determine, based on the function call graph analysis, that the platform-specific implementation of the function has changed, the illustrative embodiments generate and send a notification to the developer regarding the change in the platform-specific implementation of the function.

[0068] Exemplary embodiments detect changes to platform-specific files. For example, exemplary embodiments insert a hash-based comment into a downstream platform-specific file that represents the contents of the upstream file on which a developer based the downstream platform-specific file. The hash-based comment includes a hash of the contents of the original upstream file or the contents of a particular section of the original upstream file. The newly generated hash of the upstream file may change if the contents of the upstream file change. As a result, by comparing the hashes and detecting a difference in the hashes based on the comparison, the exemplary embodiments can generate a notification for the developer to check for changes in the upstream file that affect the downstream platform-specific file on which the developer is working.

[0069] The GO programming language generates a hash of the contents of the upstream file using the SHA256 hashing algorithm. The exemplary embodiment locates the hash in a hash-based comment line in a z / OS downstream platform-specific file. The exemplary embodiment searches for the hash-based comment line in all z / OS downstream platform-specific files and compares the recorded hash contained in the hash-based comment line of the z / OS downstream platform-specific file with a current hash of the parent upstream file, which is generated in real time by the exemplary embodiment. If the exemplary embodiment determines that the hashes are different based on the comparison, the exemplary embodiment sends a notification to the developer to investigate changes in the parent upstream file.

[0070] As described above, the exemplary embodiments can be applied retroactively to a parent software project by determining which upstream file is most similar to a given downstream platform-specific file or a given platform-specific section of a downstream file. The exemplary embodiments identify the associated upstream file corresponding to the parent software project for a given downstream platform-specific file. Assume that the exemplary embodiments are analyzing a compiler port of the GO programming language for a parent software project. First, the exemplary embodiments extract all functions and constant variables from the parent upstream file blah.go and the downstream platform-specific file blah_zos.go. Then, the exemplary embodiments record the number of common functions and constant variables between the parent upstream file blah.go and the downstream platform-specific file blah_zos.go. Next, the exemplary embodiments determine the similarity percentage of the content of the common functions between the parent upstream file blah.go and the downstream platform-specific file blah_zos.go. An example of an exemplary embodiment of an exemplary algorithm utilized to calculate the similarity percentage is as follows:

number

[0071] An exemplary embodiment obtains the line differences by utilizing a difference comparison tool. The difference comparison tool effectively shows how the parent upstream file changes into the downstream platform-specific file by showing added and removed lines of program code. An example of an exemplary embodiment of an algorithm utilized to calculate the line differences is as follows:

number

[0072] Using the information obtained above, the exemplary embodiment prioritizes the upstream file blah*.go, giving the highest priority to related files. For the GO programming language, the priority is, for example: number of common functions and constant variables > percentage of similarity > filenames containing "unix" > filenames containing "linux" > filenames containing "aix". The exemplary embodiment identifies the correct related files using a defined number of files ("n") as the highest priority files in the list, where n is a threshold number of related files. Note, however, that several files may have the same priority.

[0073] Note that exemplary embodiments need not permanently leave hash-based comments in downstream platform-specific files. For example, exemplary embodiments can dynamically generate hash-based comments and insert them in real time before merging upstream files. After exemplary embodiments send various notifications regarding upstream file changes, exemplary embodiments can remove the hash-based comments from the downstream platform-specific files. Alternatively, exemplary embodiments can place hash-based comments in accessory files that may or may not reside in a source code control system (e.g., a centralized repository). Note also that each hash-based comment may include sufficient path information to enable exemplary embodiments to dynamically identify the downstream platform-specific file and a predetermined number of its top-level associated upstream files. However, when a hash-based comment includes sufficient path information to identify the downstream platform-specific file and a predetermined number of its top-level associated upstream files, the hash-based comment is not actually a comment, but simply a line in a side file.

[0074] Exemplary embodiments perform function tracking as well. For example, it is sometimes desirable for exemplary embodiments to extend upstream file modification checking to include changes to specific functions called from a program code segment. For example, consider a function "someFunc" with a platform-specific specifier, where two function call paths are enumerated as shown below: func someFunc(a int,b int)int { if runtime.GOOS=="zos"{ return zosFunc(a,b) }else{ return linuxFunc(a,b) } } func linuxFunc(a int,b int)int{ / / ...other operation c:=linuxInnerFunc(a,b) / / ...other operation return c } func linuxInnerFunc(a int,b int)int{ return a+b }.

[0075] In the example shown above, one function call path is for the z / OS platform and the other function call path is for the Linux platform. If there is a change to the called function "linuxFunc" or the inner function "linuxInnerFunc", the example embodiment notifies the developer of this change, as this change may prompt a change to the function "zosFunc" called in the "if" program code path.

[0076] More precisely, in function someFunc, the program code checks the current platform on which the program code is running and calls the associated function accordingly. Specifically, if the program code is running on a Linux platform, the program code calls at least two Linux platform-specific functions (i.e., linuxFunc and linuxInnerFunc) in the above example. Changes to these two Linux platform-specific functions may occur in the parent upstream file. As a result, it is not sufficient for the exemplary embodiment to simply compare the text content or abstract syntax trees within the program code block of an if-else statement. To enhance monitoring of upstream file changes, the exemplary embodiment tracks functions and verifies any changes in the platform-specific implementation of the functions within the function call graph, prompting notification to the developer.

[0077] The exemplary embodiment scans the entire parent software project program code before pulling updates from the upstream file, and then generates a first function call graph C1. Additionally, the exemplary embodiment scans the entire parent software project program code again after pulling updates from the upstream file, and then generates a second function call graph C2. After generating the function call graphs C1 and C2, the exemplary embodiment utilizes the following algorithm: For every else system check code block cb: functionCalls=getAllFunction(cb) for every functionCalls f: for f!=null: if not isSameImplement(f,c1,c2): notify() return else: f=next(f,c2) f2=next(f,c1) if f!=f2: notify() return

[0078] For each other system check code block that invokes a function call, the exemplary embodiment looks for subgraphs starting from those functions in both the first function call graph C1 and the second function call graph C2. If the exemplary embodiment determines that the subgraphs in the first function call graph C1 and the second function call graph C2 are different, the exemplary embodiment notifies the developer of the change. Conversely, if the exemplary embodiment determines that the subgraphs in the first function call graph C1 and the second function call graph C2 are identical, the exemplary embodiment looks for platform-specific implementations of those functions within the subgraphs. If any nodes corresponding to particular functions within the subgraphs indicate different platform-specific implementations, the exemplary embodiment notifies the developer of the change.

[0079] An efficient way for the exemplary embodiments to access platform-specific implementations of functions while scanning the entire parent software project program code is for the exemplary embodiments to also build an abstract syntax tree for the functions in the parent software project. The abstract syntax tree represents the structure of the program code in the parent software project. The exemplary embodiments may, for example, functionMap:=make(map[string]ast.Node) functionMap["filePath:someFunc"]=AST of someFunc functionMap["filePath:someFunc2"]=AST of someFunc2 Store the function in a data structure such as

[0080] When an exemplary embodiment first constructs the data structure, "isSameImplement" may be as follows: isSameImplement(f,c1,c2): tree1=c1.functionMap[f] tree2=c2.functionMap[f] return compareTree(tree1,tree2)

[0081] In real-world scenarios, functions may call many other functions, resulting in a vast and complex function call graph. Monitoring the entire function call graph is inefficient due to its vast number of layers. Also, because commonly used functions may be invoked on various paths throughout the function call graph, updates to commonly used functions may cause exemplary embodiments to generate numerous notifications. As a result, exemplary embodiments limit the traversal depth of the entire function call graph. For example, instead of traversing every path in the entire function call graph, exemplary embodiments utilize a maximum traversal threshold for the path length that the exemplary embodiment traverses within the entire function call graph.

[0082] Alternatively, exemplary embodiments may terminate path traversal for common function calls. For example, if a particular function is frequently referenced, the exemplary embodiments may classify the particular function as a common function. For example, in the GO programming language, the function "println()" can be invoked by many other functions. By the exemplary embodiments ignoring these commonly referenced functions during function call checks, the exemplary embodiments significantly increase efficiency and reduce irrelevant notifications. For example, the exemplary embodiments may set a maximum function reference threshold, e.g., to 2. If the exemplary embodiments determine that a node corresponding to a particular function in the function call graph has a number of incoming edges greater than or equal to the set maximum function reference threshold (e.g., 2), the exemplary embodiments may ignore or skip the node corresponding to the particular function, which the exemplary embodiments classify as a common function.

[0083] Additionally, exemplary embodiments may generate a function call graph using a program code coverage tool. For example, exemplary embodiments may further enhance the generation of the function call graph by considering test cases of a software project and applying a program code coverage tool to generate a sequence of functions in a function call graph associated with the test cases. In this manner, exemplary embodiments may generate a map to the function call graph of a test case as follows: Test case name, function call graph Test Case 1 | Main, Foo, Goo, Boo Test Case 2|Main,Foo,Goo,Groo,Boo.

[0084] Moreover, the exemplary embodiments can generate a comprehensive function call graph representing all test cases by combining all function call graphs to represent a realistic function call graph fine-tuned for test case coverage. Moreover, the exemplary embodiments can operate based on the comprehensive function call graph generated above by utilizing the test cases in mapping the function call graph and enhancing notifications corresponding to functions and also suggesting test cases.

[0085] Additionally, the exemplary embodiments may utilize the abstract syntax tree to identify locations of similar program code. In other words, the exemplary embodiments may consider the program code of a software project at a more granular level. For example, the exemplary embodiments may consider program code differences that occur at the statement level. The exemplary embodiments utilize the abstract syntax tree representing program code statements for a given function to identify newly added, modified, or deleted program code. As a result, the exemplary embodiments may utilize this identified information to provide more granular notification at the statement level instead of the function level.

[0086] Assume the following: D=2 if defined(__MVS__) A=5 elif defined(__linux__) A=6.

[0087] Now, let's assume that new code has been added for the else linux path: D=2 if defined(__MVS__) A=5 elif defined(__linux__) A=6 A=A*D / / New Program Code.

[0088] The illustrative embodiments identify a target function by generating a list of distinct functions based on a comparison of function call graphs (e.g., a comparison of function call graphs C1 and C2), as described above. Next, the illustrative embodiments utilize the abstract syntax tree, along with a tree-based algorithm such as tree edit distance, to detect similar program code sequences between two functions (e.g., function Fa, which is a platform-specific function implementation in a branch corresponding to a heterogeneous platform, and function Fb, which is a base function of the base platform) across the abstract syntax tree. In addition, the illustrative embodiments can use the abstract syntax tree to detect new program code that may require adjustments to function Fa. Note that abstract syntax tree parsers exist for most programming languages. The GO programming language provides an abstract syntax tree module, "go / ast," which the illustrative embodiments can use to generate and analyze abstract syntax trees for programs written in the GO programming language. Clang also provides a plug-in function for analyzing abstract syntax trees for C and C++ programs.

[0089] First, the exemplary embodiment identifies the newly added program code as a subtree. For example, before the exemplary embodiment retrieves new changes from a source code control system (e.g., before the exemplary embodiment performs a Github pull for the new changes), the exemplary embodiment generates a first abstract syntax tree A1 for the basis function Fb. Additionally, after the exemplary embodiment retrieves the new changes from the source code control system (e.g., after the exemplary embodiment pulls the new changes from Github), the exemplary embodiment generates a second abstract syntax tree A2 for the basis function Fb. After generating the abstract syntax trees A1 and A2, the exemplary embodiment compares the abstract syntax tree A2 with the abstract syntax tree A1 by utilizing a tree edit distance algorithm. Based on the exemplary embodiment comparing abstract syntax tree A2 with abstract syntax tree A1, the exemplary embodiment identifies a set of newly added subtrees Nb (e.g., newly added subtrees N1 to newly added subtrees Nx), identifies a set of deleted subtrees Db (e.g., deleted subtrees D1 to deleted subtrees Dx), and identifies a set of updated or modified subtrees Ub (e.g., updated subtrees U1 to updated subtrees Ux).

[0090] Second, the exemplary embodiment compares the function Fa with the basis function Fb. For example, the exemplary embodiment pulls a set of changes in the branch corresponding to the heterogeneous platform from an upstream file corresponding to the parent software project (e.g., using Github pull). After pulling the set of changes from the upstream file, the exemplary embodiment generates a third abstract syntax tree A3 for the function Fa corresponding to the heterogeneous platform. The exemplary embodiment compares the second abstract syntax tree A2 for the basis function Fb corresponding to the base platform with the third abstract syntax tree A3 for the function Fa corresponding to the heterogeneous platform. Based on comparing the second abstract syntax tree A2 for the basis function Fb corresponding to the base platform with the third abstract syntax tree A3 for the function Fa corresponding to the heterogeneous platform, the exemplary embodiment identifies a set of newly added subtrees Nf (e.g., newly added subtrees N1 to newly added subtrees Nx), a set of deleted subtrees Df (e.g., deleted subtrees D1 to deleted subtrees Dx), and a set of updated subtrees Uf (e.g., updated subtrees U1 to updated subtrees Ux). For each of the identified set of newly added subtrees Nf, the identified set of deleted subtrees Df, and the identified set of updated subtrees Uf, the exemplary embodiment identifies the location of a common ancestor in the second abstract syntax tree A2 for the basis function Fb corresponding to the base platform for the identified set of newly added subtrees Nf, the identified set of deleted subtrees Df, and the identified set of updated subtrees Uf. After the illustrative embodiment identifies the common ancestor for the identified set of newly added subtrees Nf, the common ancestor for the identified set of deleted subtrees Df, and the common ancestor for the identified set of updated subtrees Uf in the second abstract syntax tree A2 for the basis function Fb corresponding to the base platform, the illustrative embodiment sends a notification to the developer about each common ancestor.

[0091] The illustrative embodiments can automatically implement a set of changes in downstream platform-specific files corresponding to the disparate platforms. For example, the illustrative embodiments can add subtrees in branch paths corresponding to the disparate platforms to the abstract syntax tree corresponding to the base platform. For example, the illustrative embodiments can add subtrees corresponding to the disparate platforms to all branch subnodes in the abstract syntax tree corresponding to the base platform. The illustrative embodiments then add subtrees corresponding to the disparate platforms based on successful construction and highest success rate for a given set of test cases by selecting a particular branch subnode in the abstract syntax tree corresponding to the base platform.

[0092] Therefore, the illustrative embodiments provide one or more technical solutions that solve the current technical problem of being unable to recognize all changes made to upstream files corresponding to a computing platform of a parent software project that need to be applied to downstream platform-specific files corresponding to a heterogeneous computing platform for porting. As a result, these one or more technical solutions provide technical effects and practical applications in the field of software porting.

[0093] 2, a diagram illustrating an example of a hash-based comment insertion process according to an exemplary embodiment is shown. Hash-based comment insertion process 202 is implemented in a computer, such as computer 101 in FIG.

[0094] In this example, hash-based comment insertion process 202 includes an upstream file, blah.go 204, and a downstream platform-specific file, blah_zos.go 206. However, it should be noted that hash-based comment insertion process 202 is merely an example and does not limit the illustrative embodiments. For example, hash-based comment insertion process 202 may include any number and types of upstream files and downstream platform-specific files.

[0095] At 208, in response to hash-based comment insertion process 202 determining that downstream platform-specific file blah_zos.go 206 is related to upstream file blah.go 204 based on, for example, the number of common functions and constant variables, similarity, file names, etc., hash-based comment insertion process 202 generates a hash of the contents of upstream file blah.go 204 using a hashing algorithm. In this example, the hash of the contents of upstream file blah.go 204 is hash "ABCED" 210. Additionally, hash-based comment insertion process 202 inserts a hash-based comment 212 into downstream platform-specific file blah_zos.go 206. Furthermore, hash-based comment insertion process 202 places hash ABCED 210, which is a hash of the contents of upstream file blah.go 204, into hash-based comment 212. The hash-based comment insertion process 202 may also include other information in the hash-based comment 212, such as the name of the upstream file blah.go 204, the path to the upstream file blah.go 204, etc.

[0096] 3, a diagram illustrating an example of a hash comparison process according to an exemplary embodiment is shown. Hash comparison process 300 is implemented in a computer, such as computer 101 in FIG.

[0097] In this example, hash comparison process 300 includes modified upstream file blah.go 302 and downstream platform-specific file blah_zos.go 206. Note that modified upstream file blah.go 302 is an updated or modified version of upstream file blah.go 204 in Figure 2 after a set of changes have been made.

[0098] At 304, in response to detecting a set of changes in modified upstream file blah.go 302, hash comparison process 300 generates a current hash of the contents of modified upstream file blah.go 302 in real time. In this example, the current hash of the contents of modified upstream file blah.go 302 is current hash "EFGHI" 306. In addition, hash comparison process 300 retrieves hash ABCED 210, which is a previously generated hash of the contents of upstream file blah.go 204 in Figure 2, from hash-based comment 212 in downstream platform-specific file blah_zos.go 206.

[0099] At 308, hash comparison process 300 compares current hash EFGHI 306 with hash ABCED 210. At 310, based on comparing current hash EFGHI 306 with hash ABCED 210, hash comparison process 300 generates a hash comparison result. At 312, hash comparison process 300 determines whether the hash comparison result indicates a set of changes in modified upstream file blah.go 302, which in this example is yes because current hash EFGHI 306 does not match hash ABCED 210.

[0100] At 314, in response to hash comparison process 300 determining that the hash comparison results indicate a set of changes in modified upstream file blah.go 302, hash comparison process 300 sends a notification of the set of changes to the developer of downstream platform-specific file blah_zos.go 206. Additionally, at 316, hash comparison process 300 automatically implements the set of changes in downstream platform-specific file blah_zos.go 206.

[0101] 4, a diagram illustrating an example of an abstract syntax tree according to an exemplary embodiment is shown. Abstract syntax tree 400 is implemented in a computer, such as computer 101 in FIG.

[0102] In this example, abstract syntax tree 400 includes a main path 402, a base platform path 404, and a branch heterogeneous platform path 406. Base platform path 404 includes subtree 408, and branch heterogeneous platform path 406 includes subtree 410. However, it should be noted that abstract syntax tree 400 is a simple example and may include any number of subtrees.

[0103] The computer detects two newly added subtrees (i.e., subtree 408 and subtree 410), one corresponding to base platform path 404 and the other corresponding to branch heterogeneous platform path 406, for example, by utilizing a tree edit distance algorithm. Subtree 408 includes new code 412 and new code 414. Subtree 410 includes new platform code 416 and new platform code 418.

[0104] The computer can annotate the nodes of abstract syntax tree 400 with labels that allow each node to be uniquely identified. The computer determines where the subtrees meet by traversing up subtree 408 and subtree 410. The computer determines the point where the subtrees meet, in this example, D=5, as common ancestor 420. Common ancestor 420 is where the computer adds a notification to developers of downstream platform-specific files that correspond to diverging heterogeneous platform paths 406.

[0105] 5A-5B, a flowchart illustrating a process for managing software project ports according to an example embodiment is shown. The process illustrated in Figures 5A-5B may be implemented in a computer, such as computer 101 in Figure 1. For example, the process illustrated in Figures 5A-5B may be implemented by software project port management code 200 in Figure 1.

[0106] The process begins when a computer determines that a downstream platform-specific file corresponding to a dissimilar computing platform is related to an upstream file corresponding to a computing platform of the parent software project based on a number of common functions and constant variables between the downstream platform-specific file and the upstream file exceeding a specified minimum commonality threshold level (step 502). Based on the determination that the downstream platform-specific file corresponding to the dissimilar computing platform is related to the upstream file, the computer generates a first hash of the contents in the upstream file corresponding to the computing platform of the parent software project (step 504).

[0107] The computer inserts a hash-based comment in a downstream platform-specific file corresponding to the heterogeneous computing platform in response to generating a first hash of the content in the upstream file corresponding to the computing platform of the parent software project, the hash-based comment including the first hash of the content in the upstream file (step 506). The computer monitors the centralized source code control repository for any changes at specified time intervals (step 508). The computer makes a determination as to whether a set of changes has been committed to the centralized source code control repository based on monitoring the centralized source code control repository for any changes (step 510).

[0108] If the computer determines, based on monitoring the centralized source code control repository for any changes, that the set of changes has not been committed to the centralized source code control repository, it outputs "No" in step 510, and the process then returns to step 508, where the computer continues to monitor the centralized source code control repository. If the computer determines, based on monitoring the centralized source code control repository for any changes, that the set of changes has been committed to the centralized source code control repository, it outputs "Yes" in step 510, and the computer then generates a second hash of the content in the upstream file corresponding to the computing platform of the parent software project (step 512). In addition, the computer retrieves the first hash of the content in the upstream file corresponding to the computing platform of the parent software project from a hash-based comment inserted in the downstream platform-specific file corresponding to the heterogeneous computing platform (step 514). The computer performs a comparison of the second hash of the content in the upstream file corresponding to the computing platform of the parent software project with the first hash of the content in the upstream file, which was retrieved from the hash-based comment inserted in the downstream platform-specific file corresponding to the heterogeneous computing platform (step 516).

[0109] Note that the computer knows which downstream platform-specific files corresponding to the heterogeneous computing platforms have hash-based comments inserted. As a result, the computer can quickly check the hash-based comments. Alternatively, the computer can maintain a list of downstream platform-specific files in which hash-based comments have been inserted. Each hash-based comment includes the file path to the corresponding upstream file. Because the computer monitors or periodically checks the centralized source code control repository for any changes at a gross level, the computer knows when changes have occurred in one or more upstream files. For each downstream platform-specific file that includes a hash-based comment, the computer compares the hashes by generating a hash of the corresponding upstream file named in the hash-based comment.

[0110] Also, note that the computer first integrates all upstream file changes into the downstream platform-specific version, and then checks the integrated file. As a result, the upstream file that the computer compares has been copied into the local source code control repository. In other words, when the computer identifies an upstream file's hash to compare with the hash stored in the hash-based comment, that upstream file has been copied locally. Thus, the process is efficient by being able to quickly run through all hash-based comments, quickly locate named upstream files locally, generate new hashes for the named upstream files, and then compare the hashes.

[0111] The computer determines to apply the set of changes made to the upstream file corresponding to the computing platform of the parent software project to the downstream platform-specific file corresponding to the heterogeneous computing platform based on a comparison of the second hash of the content in the upstream file with the first hash of the content in the upstream file extracted from the hash-based comment inserted in the downstream platform-specific file (step 518). The computer sends a notification to the developer of the downstream platform-specific file corresponding to the heterogeneous computing platform regarding the set of changes made to the upstream file corresponding to the computing platform of the parent software project on which the downstream platform-specific file was based (step 520). Furthermore, the computer automatically implements the set of changes made to the upstream file corresponding to the computing platform of the parent software project in the downstream platform-specific file corresponding to the heterogeneous computing platform (step 522). Thereafter, the process returns to step 508, where the computer continues to monitor the centralized source code control repository for any changes.

[0112] 6A-6C, a flowchart illustrating a process for determining platform-specific implementation changes at the function level by performing function call graph analysis according to an example embodiment is shown. The process illustrated in Figures 6A-6C may be implemented in a computer, such as computer 101 in Figure 1. For example, the process illustrated in Figures 6A-6C may be implemented by software project port management code 200 in Figure 1.

[0113] The process begins when a computer performs a first scan of program code in a downstream platform-specific file corresponding to a heterogeneous computing platform before retrieving a set of changes from an upstream file corresponding to the computing platform of the parent software project (stage 602). The computer generates a first function call graph for the downstream platform-specific file corresponding to the heterogeneous computing platform based on the first scan of program code in the downstream platform-specific file before retrieving a set of changes from an upstream file corresponding to the computing platform of the parent software project (stage 604).

[0114] In response to generating the first function call graph for the downstream platform-specific file corresponding to the heterogeneous computing platform, the computer retrieves a set of changes from the upstream file corresponding to the computing platform of the parent software project (step 606). The computer automatically implements the set of changes retrieved from the upstream file corresponding to the computing platform of the parent software project in program code of the downstream platform-specific file corresponding to the heterogeneous computing platform (step 608).

[0115] The computer performs a second scan of the program code in the downstream platform-specific file corresponding to the heterogeneous computing platform after implementing in the downstream platform-specific file the set of changes retrieved from the upstream file corresponding to the computing platform of the parent software project (stage 610). The computer generates a second function call graph for the downstream platform-specific file corresponding to the heterogeneous computing platform based on the second scan of the program code in the downstream platform-specific file after implementing in the downstream platform-specific file the set of changes retrieved from the upstream file corresponding to the computing platform of the parent software project (stage 612).

[0116] The computer performs a search of the first function call graph and the second function call graph for the downstream platform-specific file corresponding to the heterogeneous computing platform (step 614). Based on the search of the first function call graph and the second function call graph, the computer identifies a set of functions found in both the first function call graph and the second function call graph for the downstream platform-specific file corresponding to the heterogeneous computing platform (step 616).

[0117] The computer forms a selected function by selecting a function from a set of functions found in both the first function call graph and the second function call graph for the downstream platform-specific file corresponding to the heterogeneous computing platform (step 618). The computer identifies a function call subgraph corresponding to the selected function in both the first function call graph and the second function call graph for the downstream platform-specific file corresponding to the heterogeneous computing platform (step 620).

[0118] The computer performs a first analysis of a function call subgraph corresponding to the selected function in both the first function call graph and the second function call graph for the downstream platform-specific file corresponding to the heterogeneous computing platform (step 622). Based on the first analysis of the function call subgraph, the computer determines whether there are differences between the function call subgraph corresponding to the selected function in the first function call graph and the second function call graph for the downstream platform-specific file corresponding to the heterogeneous computing platform (step 624).

[0119] If the computer determines, based on the first analysis of the function call subgraphs, that there is a difference between the function call subgraphs corresponding to the selected function in the first function call graph and the second function call graph for the downstream platform-specific file corresponding to the heterogeneous computing platform, outputting "Yes" in step 624, the computer sends a notification to the developer of the downstream platform-specific file corresponding to the heterogeneous computing platform regarding the difference in the function call subgraphs (step 626).The computer then determines whether there is another function in the set of functions (step 628).

[0120] If the computer determines that there is another function in the set of functions, it outputs yes at step 628 and the process returns to step 618 where the computer selects another function from the set of functions. If the computer determines that there is not another function in the set of functions, it outputs no at step 628 and the process ends thereafter.

[0121] Returning again to step 624, if the computer determines, based on the first analysis of the function call subgraphs, that there are no differences between the function call subgraphs corresponding to the selected function in the first function call graph and the second function call graph for the downstream platform-specific file corresponding to the heterogeneous computing platform, it outputs No in step 624, and then the computer performs a second analysis of the function call subgraph corresponding to the selected function for platform-specific implementations of the selected function in both the first function call graph and the second function call graph for the downstream platform-specific file corresponding to the heterogeneous computing platform (step 630). Thereafter, based on the second analysis of the function call subgraphs, the computer makes a determination as to whether a particular function in the function call subgraph corresponding to the selected function exhibits a different platform-specific implementation (step 632).

[0122] If the computer determines, based on the second analysis of the function call subgraphs, that a particular function in the function call subgraph corresponding to the selected function exhibits a different platform-specific implementation, it outputs yes at step 632, and the process then returns to step 626, where the computer sends a notification to the developer of the downstream platform-specific file corresponding to the heterogeneous computing platform regarding the particular function exhibiting a different platform-specific implementation. If the computer determines, based on the second analysis of the function call subgraphs, that a particular function in the function call subgraph corresponding to the selected function does not exhibit a different platform-specific implementation, it outputs no at step 632, and the process then returns to step 628, where the computer determines whether another function exists in the set of functions.

[0123] 7A-7C, a flowchart illustrating a process for determining platform-specific implementation changes at the statement level for a given function by performing abstract syntax tree analysis, according to an example embodiment, is shown. The process illustrated in Figures 7A-7C may be implemented in a computer, such as computer 101 in Figure 1. For example, the process illustrated in Figures 7A-7C may be implemented by software project port management code 200 in Figure 1.

[0124] The process begins when a computer identifies a first function in an upstream file corresponding to a computing platform of a parent software project and a second function in a downstream platform-specific file corresponding to a heterogeneous computing platform (stage 702). The second function corresponds to the first function. The computer generates a first abstract syntax tree for the first function in the upstream file corresponding to the computing platform of the parent software project before a set of changes are made to the upstream file (stage 704). The computer generates a second abstract syntax tree for the first function in the upstream file corresponding to the computing platform of the parent software project after the set of changes are made to the upstream file (stage 706).

[0125] The computer performs a comparison of the first abstract syntax tree with a second abstract syntax tree for the first function in the upstream file corresponding to the computing platform of the parent software project after the set of changes have been made to the upstream file using a tree edit distance algorithm (step 708). The computer identifies a first set of newly added program code as a first set of newly added subtrees, a first set of deleted program code as a first set of deleted subtrees, and a first set of changed program code as a first set of changed subtrees for the first function in the upstream file corresponding to the computing platform of the parent software project based on the comparison of the first abstract syntax tree with the second abstract syntax tree for the first function after the set of changes have been made to the upstream file (step 710).

[0126] The computer implements the set of changes made to the upstream file corresponding to the computing platform of the parent software project in the downstream platform-specific file corresponding to the heterogeneous computing platform (stage 712). The computer generates a third abstract syntax tree for the second function in the downstream platform-specific file corresponding to the heterogeneous computing platform in response to implementing the set of changes made to the upstream file corresponding to the computing platform of the parent software project in the downstream platform-specific file (stage 714).

[0127] The computer performs a comparison of the third abstract syntax tree for the second function in the downstream platform-specific file corresponding to the heterogeneous computing platform with the second abstract syntax tree for the first function in the upstream file corresponding to the computing platform of the parent software project using a tree edit distance algorithm (step 716). The computer identifies, for the second function in the downstream platform-specific file corresponding to the heterogeneous computing platform, a second set of newly added program code as the second set of newly added subtrees, a second set of deleted program code as the second set of deleted subtrees, and a second set of modified program code as the second set of modified subtrees based on the comparison of the third abstract syntax tree for the second function with the second abstract syntax tree for the first function in the upstream file corresponding to the computing platform of the parent software project (step 718).

[0128] The computer determines differences between a first set of newly added program code as a first set of newly added subtrees, a first set of deleted program code as a first set of deleted subtrees, and a first set of modified program code as a first set of modified subtrees for a first function in the upstream file corresponding to the computing platform of the parent software project, and a second set of newly added program code as a second set of newly added subtrees, a second set of deleted program code as a second set of deleted subtrees, and a second set of modified program code as a second set of modified subtrees for a second function in the downstream platform-specific file corresponding to the heterogeneous computing platform (stage 720). The computer identifies a common ancestor in a second abstract syntax tree for the first function in the upstream file corresponding to the computing platform of the parent software project for each difference determined between the first set of newly added program code as a first set of newly added subtrees, the first set of deleted program code as a first set of deleted subtrees, and the first set of modified program code as a first set of modified subtrees for the first function in the upstream file corresponding to the computing platform of the parent software project, and the second set of newly added program code as a second set of newly added subtrees, the second set of deleted program code as a second set of deleted subtrees, and the second set of modified program code as a second set of modified subtrees for the second function in the downstream platform-specific file corresponding to the heterogeneous computing platform (stage 722).The computer sends a notification to the developer of the downstream platform-specific file corresponding to the heterogeneous computing platform for each determined difference in each common ancestor in the second abstract syntax tree for the first function in the upstream file corresponding to the computing platform of the parent software project (stage 724).

[0129] Thus, exemplary embodiments of the present disclosure provide a computer-implemented method, computer system, and computer program product for managing software project ports. The description of various embodiments of the present disclosure is presented for illustrative purposes and is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the spirit and scope of the described embodiments. The terminology used herein has been selected to best explain the principles, practical applications, or technical improvements to technologies found in the marketplace of the embodiments, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. 1. A computer-implemented method for managing software project ports, the computer-implemented method comprising: performing, by the computer, a comparison of a second hash of content in an upstream file corresponding to the computing platform of the parent software project with a first hash of the content in the upstream file, the first hash being extracted from a hash-based comment inserted in a downstream platform-specific file corresponding to the disparate computing platform; determining, by the computer, to apply a set of changes made to the upstream file corresponding to the computing platform of the parent software project to the downstream platform-specific file corresponding to the heterogeneous computing platform based on the comparison of the second hash of the content in the upstream file with a first hash of the content in the upstream file, the set of changes being extracted from the hash-based comment inserted in the downstream platform-specific file; and sending, by the computer, a notification to a developer of the downstream platform-specific file corresponding to the heterogeneous computing platform regarding the set of changes made to the upstream file corresponding to the computing platform of the parent software project on which the downstream platform-specific file is based. Computer-implemented methods.

2. automatically implementing, by the computer, in the downstream platform-specific file corresponding to the heterogeneous computing platform, the set of changes made to the upstream file corresponding to the computing platform of the parent software project. The computer-implemented method of claim 1 .

3. determining, by the computer, that the downstream platform-specific file corresponding to the disparate computing platform is related to the upstream file corresponding to the computing platform of the parent software project based on a number of common functions and constant variables between the downstream platform-specific file and the upstream file exceeding a specified least common denominator threshold level; generating, by the computer, the first hash of the content in the upstream file corresponding to the computing platform of the parent software project based on determining that the downstream platform-specific file corresponding to the disparate computing platform is related to the upstream file; and inserting, by the computer, the hash-based comment in the downstream platform-specific file corresponding to the heterogeneous computing platform in response to generating the first hash of the content in the upstream file corresponding to the computing platform of the parent software project, the hash-based comment including the first hash of the content in the upstream file. The computer-implemented method of claim 1 .

4. monitoring, by said computer, a centralized source code control repository for any changes; and determining, by the computer, whether the set of changes has been committed to the centralized source code control repository based on monitoring the centralized source code control repository for any changes. The computer-implemented method of claim 1 .

5. generating, by the computer, the second hash of the contents in the upstream file corresponding to the computing platform of the parent software project in response to the computer determining that the set of changes has been committed to the centralized source code control repository based on monitoring the centralized source code control repository for any changes; and deriving, by the computer, the first hash of the content in the upstream file corresponding to the computing platform of the parent software project from the hash-based comment inserted in the downstream platform-specific file corresponding to the heterogeneous computing platform. The computer-implemented method of claim 4.

6. determining, by the computer, platform-specific implementation changes at a function level by performing a function call graph analysis. A computer-implemented method according to any one of claims 1 to 5.

7. determining, by the computer, platform-specific implementation changes at the statement level for a given function by performing an abstract syntax tree analysis. A computer-implemented method according to any one of claims 1 to 5.

8. 1. A computer system for managing a software project port, the computer system comprising: communications fabric; a set of computer-readable storage media connected to the communications fabric, the set of computer-readable storage media collectively storing program instructions; and a set of processors connected to the communications fabric, wherein the set of processors executes the program instructions to: performing a comparison of a second hash of content in an upstream file corresponding to the computing platform of the parent software project with a first hash of the content in the upstream file, the first hash being extracted from a hash-based comment inserted in a downstream platform-specific file corresponding to the heterogeneous computing platform; determining, based on the comparison of the second hash of the content in the upstream file with the first hash of the content in the upstream file, extracted from the hash-based comment inserted in the downstream platform-specific file, to apply a set of changes made to the upstream file corresponding to the computing platform of the parent software project to the downstream platform-specific file corresponding to the heterogeneous computing platform; and sending a notification to a developer of the downstream platform-specific file corresponding to the heterogeneous computing platform regarding the set of changes made to the upstream file corresponding to the computing platform of the parent software project on which the downstream platform-specific file was based. Computer system.

9. The set of processors further executes the program instructions to: automatically implementing the set of changes made to the upstream file corresponding to the computing platform of the parent software project in the downstream platform-specific file corresponding to the heterogeneous computing platform.

9. The computer system of claim 8.

10. The set of processors further executes the program instructions to: determining that the downstream platform-specific file corresponding to the disparate computing platform is related to the upstream file corresponding to the computing platform of the parent software project based on a number of common functions and constant variables between the downstream platform-specific file and the upstream file exceeding a specified least common denominator threshold level; generating the first hash of the content in the upstream file corresponding to the computing platform of the parent software project based on determining that the downstream platform-specific file corresponding to the disparate computing platform is related to the upstream file; and inserting the hash-based comment in the downstream platform-specific file corresponding to the heterogeneous computing platform in response to generating the first hash of the content in the upstream file corresponding to the computing platform of the parent software project, the hash-based comment including the first hash of the content in the upstream file; 9. The computer system of claim 8.

11. The set of processors further executes the program instructions to: Monitoring a centralized source code control repository for any changes; and determining whether the set of changes has been committed to the centralized source code control repository based on monitoring the centralized source code control repository for any changes; 9. The computer system of claim 8.

12. The set of processors further executes the program instructions to: generating the second hash of the contents in the upstream file corresponding to the computing platform of the parent software project in response to determining that the set of changes has been committed to the centralized source code control repository based on monitoring the centralized source code control repository for any changes; and deriving the first hash of the content in the upstream file corresponding to the computing platform of the parent software project from the hash-based comment inserted in the downstream platform-specific file corresponding to the heterogeneous computing platform; 12. The computer system of claim 11.

13. The set of processors further executes the program instructions to: Determine platform-specific implementation changes at the function level by performing function call graph analysis, 13. A computer system according to any one of claims 8 to 12.

14. A computer program for managing software program ports, said computer program comprising program instructions executable by a computer, said program instructions causing said computer to: performing a comparison of a second hash of content in an upstream file corresponding to the computing platform of the parent software project with a first hash of the content in the upstream file, the first hash being extracted from a hash-based comment inserted in a downstream platform-specific file corresponding to the heterogeneous computing platform; determining, based on the comparison of the second hash of the content in the upstream file with the first hash of the content in the upstream file, extracted from the hash-based comment inserted in the downstream platform-specific file, to apply a set of changes made to the upstream file corresponding to the computing platform of the parent software project to the downstream platform-specific file corresponding to the heterogeneous computing platform; and sending a notification to a developer of the downstream platform-specific file corresponding to the heterogeneous computing platform regarding the set of changes made to the upstream file corresponding to the computing platform of the parent software project on which the downstream platform-specific file is based; A computer program that manages software project ports.

15. The program instructions further cause the computer to: automatically implementing the set of changes made to the upstream file corresponding to the computing platform of the parent software project in the downstream platform-specific file corresponding to the heterogeneous computing platform.

15. A computer program according to claim 14.

16. The program instructions further cause the computer to: determining that the downstream platform-specific file corresponding to the disparate computing platform is related to the upstream file corresponding to the computing platform of the parent software project based on a number of common functions and constant variables between the downstream platform-specific file and the upstream file exceeding a specified least common denominator threshold level; generating the first hash of the content in the upstream file corresponding to the computing platform of the parent software project based on determining that the downstream platform-specific file corresponding to the heterogeneous computing platform is related to the upstream file; and inserting a hash-based comment in the downstream platform-specific file corresponding to the heterogeneous computing platform in response to generating the first hash of the content in the upstream file corresponding to the computing platform of the parent software project, the hash-based comment including the first hash of the content in the upstream file; 15. A computer program according to claim 14.

17. The program instructions further cause the computer to: Monitor a centralized source code control repository for any changes; and determining whether the set of changes has been committed to the centralized source code control repository based on monitoring the centralized source code control repository for any changes; 15. A computer program according to claim 14.

18. The program instructions further cause the computer to: generating the second hash of the contents in the upstream file corresponding to the computing platform of the parent software project in response to determining that the set of changes has been committed to the centralized source code control repository based on monitoring the centralized source code control repository for any changes; and deriving the first hash of the content in the upstream file corresponding to the computing platform of the parent software project from the hash-based comment inserted in the downstream platform-specific file corresponding to the heterogeneous computing platform; 18. A computer program according to claim 17.

19. The program instructions further cause the computer to: Performing function call graph analysis to determine platform-specific implementation changes at the function level; 19. A computer program according to any one of claims 14 to 18.

20. The program instructions further cause the computer to: Determine platform-specific implementation changes at the statement level for a given function by performing an abstract syntax tree analysis; 19. A computer program according to any one of claims 14 to 18.