Patent Description:
Porting computer programs from one platform or source to another is important to enable the computer programs to be used on several platforms. For example, in the case of a cloud computing platform, several computer programs, such as open source programs are available to be used for particular functionality such as container support. Porting such computer programs from one platform (e.g., cloud computing platform, mobile computing platform, operating system, etc.) to another facilitates uninterrupted use of software that use such computer programs.

Existing technical solutions for analyzing computer programs and debugging computer instructions do not contemplate specific technical challenges that occur when updating large-scale enterprise level projects using with source code changes that may not be used by particular target computing platform(s). While several existing solutions exist for porting source code from one platform to the target computing platform, there is a need to improve the ported code, and particularly to filter the ported code specific to the target computing platform.

<NPL>, discloses a change-centric approach to compile configurable systems with #ifdefs by analyzing only configurations impacted by a code change (transformation).

United States Patent Application publication number <CIT>,<NPL>) discloses selectively examining the effects of preprocessing operations on computer source code. Where a preprocessor construct, such as a macro, appears in the source code, a user may selectively expand the construct to see the effects of expansion. If a macro expands into text which contains other macro calls, the user may selectively expand the other macro calls. The present invention allows the user to go back and forth between unexpanded, partly expanded, and fully expanded constructs in order to obtain a better understanding of the effect of macro expansion on the original source code. The present invention applies to any programming language which supports macros and/or other preprocessing constructs. It also applies to preprocessors that are independent of any programming language, such as the M4 preprocessor. The invention may also be included in another computer program, such as a debugger.

<NPL>) discloses a service layer for the Visual Studio to make detailed preprocessor information accessible for any type of IDE extensions. The analyzer tool is wrapped and functionality is presented through an API. ISBN <NUM>-<NUM>-<NUM>-<NUM>-<NUM>.

According to the present invention there are provided a computer implemented method, a system, a computer program product and a computer program according to the independent claims.

The above-described features can also be provided at least by a system, a computer program product, and a machine, among other types of implementations.

Embodiments of the present invention provide technical solutions to analyze/isolate the unneeded files/functions/code pieces in porting large-scale project in an efficient and improved manner compared to existing solutions. Embodiments of the present invention, accordingly, increase the efficiency of keeping large-scale projects current with upstream changes and branches that may include code changes made in an open source community. One or more embodiments of the present invention facilitate finding if the code update in upstream branches is needed to be included in a ported version. If it is not required for the target computing platform <NUM>, the updates need not be analyzed and debugged. Further, one or more embodiments of the present invention facilitate editor/user interfaces of software development tools to provide highly readable and more friendly views of large-scale enterprise projects by marking sections of the computer program based on techniques described herein.

The diagrams depicted herein are illustrative. There can be many variations to the diagrams or the operations described therein without departing from the scope of the invention. For instance, the actions can be performed in a differing order or actions can be added, deleted or modified. Also, the term "coupled" and variations thereof describe having a communications path between two elements and do not imply a direct connection between the elements with no intervening elements/connections between them. All of these variations are considered a part of the specification.

In the accompanying figures and following detailed description of the disclosed embodiments, the various elements illustrated in the figures are provided with two or three-digit reference numbers. With minor exceptions, the leftmost digit(s) of each reference number corresponds to the figure in which its element is first illustrated.

Technical solutions are described herein to validate, in a computer program, computer instructions that are enclosed by macros when the computer program is being updated (i.e., computer instructions are being added/modified). For a computing platform, it is a technical challenge to maintain a robust ecosystem that allows execution of computer programs that are available on other computing platforms, for example, competitor platforms, open source platforms, etc. For example, the computer programs can include libraries, tools, etc. that computer software/hardware developers ("developers") desire to execute as part of, or to support their computer program. To facilitate execution of such computer programs, the computer program instructions (i.e., source code, code, executable instructions, etc.) of such computer programs have to be compiled for the particular computing platform.

Typically, computer programs include one or more macros. In computer programming, macros are a tool that allows a developer to re-use instructions. A macro is generally a rule or pattern that specifies how a certain input should be mapped to an output. The input and output may be a sequence of lexical tokens or characters, or a syntax tree. In programming languages, such as C/C++, a macro is often used to enclose computer program instructions, which are to be compiled only when certain condition(s) is met. Using a macro can make the source code of the computer program compact and avoid duplication efforts. However, the use of macro makes it technically challenging to parse the source code. Further, debugging the source code is also made technically challenging by use of macros.

Checking if computer instructions enclosed by a macro have been included (i.e., macro has been expanded) in an object file (result of compilation) is a technical challenge. This is because, for example, the definition of a macro can be included in a separate file from the file that actually includes (or uses) the macro. Alternatively, or in addition, the macro expansion can be overridden if the source code is compiled with specific runtime option (i.e., when the compiler is executed to compile the source code). Moreover, in enterprise level projects, the source code can be complicated, and can include several (hundreds) directories and (thousands) files in different hierarchy. Determining a macro defined in one of these files, which is then used in another can be a parsing challenge. Further, there can be different macros with the same macro name, but different instructions enclosed. This situation can be exacerbated because of the hierarchy. For example, multiple files can include respective macros with the same name, and a file, say file F1, can include two or more of such macro-defining files. Accordingly, it can be challenging to predict which of the macros was expanded at the time of compiling file F1.

In turn, the technical challenge of unpredictability of macro expansion makes it technically challenging to debug the computer programs that include macros. Accordingly, porting computer programs, such as open source computer programs, to a target computing platform is technically challenging. In addition, several tools such as aclocal, autoconfig, automake, libtool (all are libraries as part of GNU PROJECT®), MESON™ build system, NINJA™ build system, etc. can make the macros configuration and the root cause analyzing / locating (i.e., debugging) more complicated.

For example, consider computer programs developed using the C programming language. It should be understood that the technical challenges described herein may not be limited to particular programming languages. In the case of C, it can be difficult to make a software program portable because the C compiler differs from system to system. Alternatively, or in addition, certain library functions can be missing on some systems. Alternatively, or in addition, header files can have different names. To handle such challenges with portability, programmers generally use conditional code, with code blocks selected by means of preprocessor directives (#ifdef). For example, these preprocessor directives instruct the compiler to only compile certain portions of the computer program if the target system satisfies certain conditions, such as availability of library functions, etc. But because of the wide variety of systems, and build environments this approach can becomes unmanageable and hence, technical challenging.

Certain existing tools, such as AUTOTOOLS® are designed to address this problem more manageably. For example, AUTOTOOLS® includes settings/configuration such as autoheader, autoconf, automake etc., which are used to assume or generate intermediate files such as, configure. ac, Makefile. in, Makefile. am, aclocal. m4, etc. Such tools (e.g., AUTOTOOLS®, LIBTOOLS®, etc.) analyze the operating system, compiler options, etc., and collect and generate the macros definition or macros conditional code automatically. However, the existing tools make the code debugging more complicated because they add several macros and preprocessor directories (i.e., compile time conditions) for the various platforms/compilers to support. Additionally, such tools handle some cross-platform support without explicit knowledge of the user making it difficult for the user to debug the computer program in case of a failure.

Additionally, at present, existing solutions can facilitate pre-processing, for example compiling with a particular option (e.g., gcc with option "-E") to generate one intermediate file which will expand all the macro, and also incorporate all the contents of included files. However, generating such an intermediary file can take a long time (hours) particularly in the case of large projects (thousands of lines of code). Further, such an intermediate file is not easily readable. For example, one source code file with <NUM> lines can expand to the intermediate file with <NUM> lines.

Also, there are tools available such as VSCODE, that can analyze the source code and identify if one specific macro is defined or not within the file. Some existing tools can also change the visual representation of computer instructions enclosed by a macro, for example different color (e.g., grey) font, if the definition of the macro is not located in the same file as the file that is using the macro.

However, these methods are based on static analysis of the source code (i.e., they are unable to resolve the definition of macro in another file). Hence, the result is not accurate in many scenarios especially. For example, macros that are defined in included files or overridden in compiling options are commonly misidentified by such tools.

Further, several open-source software (i.e., computer programs) are now available to support or enhance functionality of enterprise-level projects and/or platforms. For example, there are several open-source tools that developers can avail to support cloud-platform development, especially for container support. Porting such open source tools from one platform to another critical for platform development organizations to build a robust ecosystem for their platform. Such porting of open-source tools that may be available on some platforms ("first platform") to other platforms ("second platform") (e.g., POWER®, AIX®, IBM Z®, etc.) can be a technical challenge. Without such porting, providing the functionality of the first platform on the second platform can be a technical challenge. For example, without such porting computer programs that are executable on the first platform may not be executable on the second platform. Alternatively, to make the computer programs that are executable on the first platform to be executable on the second platform, can require developers to overcome a steep learning curve.

The technical challenges faced during making computer programs from the first platform to be compatible (i.e., able to execute) with the second platform, and particularly with open-source computer programs include removing files/computer instructions that are not applicable with the second platform (i.e., target platform). For example, some files that are part of a computer program can be specific to certain platform or hardware, and not applicable to the target platform. Additionally, the computer program can include one or more functions that are not required in a ported version of the computer program for the target platform.

The technical challenges further include keeping the ported version of the computer program current with an upstream version of the computer program from the open-source community. For example, if there is a new version of the computer program, i.e., a code change in an upstream branch of the computer program, the updated computer instructions have to be checked and the ported version of the computer program for the target platform has to be changed accordingly.

Embodiments of the present invention address such technical challenges. Instead of consuming large-scale enterprise efforts on coding and testing ported versions of an open-source computer program for the target platform every time the computer program is updated, embodiments of the present invention determine if the updated code has to be ported (e.g., if such functionality already exists in the target platform), and if the porting is required, facilitate checking the validity of the source code for the target platform.

Accordingly, embodiments of the present invention are rooted in computing technology, and provide improvements to computing technology, particularly, computer software development. Embodiments of the present invention provide a practical application to check validity of updated computer instructions (i.e., source code) in a computer program that is to be ported to a target platform. Embodiments of the present invention, accordingly, reduce development effort and improve project delivery efficiency. Embodiments of the present invention address the technical challenges described herein by recording pre-processing information about code paragraphs (e.g., macros enclosed) according to compile time condition definition or compilation options. These records facilitate analyzing/debugging the computer instructions to check if the code paragraph has been compiled into object file. The linker also adds information to the records to check if the compiled code is linked into executable or library files. Because the records are generated based on compiling/linking options instead of analyzing static source code of the computer program, embodiments of the present invention provide dynamic result of checking the validity of the computer program, particularly the updates to the computer program.

Embodiments of the present invention provide technical solutions to address such technical challenges with improvements over the existing tools. Embodiments of the present invention are rooted in computing technology, particularly identifying computer program instructions in computer programs (i.e., source code). Further, embodiments of the present invention are rooted in computing technology because, they improve debugging of computer programs (i.e., source code) that include macros. Embodiments of the present invention provide a practical application to identify macros and debug computer programs that include macros. Without using the embodiments of the present invention, such an analysis, particularly for large enterprise projects, can be impractical, or cause significant delays in development, debugging, testing, and release.

Embodiments of the present invention facilitate processing computer programs during compiling and linking the computer program. The preprocessing information about computer instructions enclosed by a macro is recorded according to macro definition or compilation option. These records further facilitate to analyze/debug the computer programs to check if the computer instructions have been compiled into object file (result of compiling). Because embodiments of the present invention generate records based on compiling options instead of analyzing static source code, a dynamic compiling or linking result is provided.

<FIG> depicts a system <NUM> for validating computer instructions enclosed by macros according to one or more embodiments. The depicted system <NUM> includes a computer program <NUM> that is to be compiled by a compiler <NUM> to generate a corresponding object file(s) <NUM>. The computer program <NUM> may be written for a different computing platform, and may be being ported for execution on a target computing platform <NUM>. The compiler <NUM> can be part of a development tool <NUM>, such as an integrated development environment (IDE). The development tool <NUM> can also include a linker <NUM> that generates an executable file <NUM> based on the object file(s) <NUM>. The executable file <NUM> is executed on a target computing platform <NUM>. It is understood that the executable file <NUM> can include multiple files in one or more examples. The compiler <NUM> generates the object file <NUM> specifically for the target computing platform <NUM> in one or more embodiments of the present invention. Alternatively, or in addition, in one or more embodiments of the present invention, the linker <NUM> generates the executable file <NUM> particularly for the target computing platform <NUM>. It should be noted that while a compiler and linker can be separate tools, with separate runtime instructions, as used herein, "compiling" or "building" the computer program <NUM> can include compiling, linking, and any other operations that may be required to convert the computer instructions in the computer program <NUM> into machine instructions that are executable by the target computing platform <NUM>. Generating such machine executable instructions in the executable file <NUM> from the computer program <NUM> is not practically doable by a human, for example, as a mental process.

The target computing platform <NUM> can be cloud computing platform architecture, an operating system, a processor architecture, or any other type of computing platform to which the computer program <NUM> is being ported. In other words, the computer program <NUM> may not have been developed (written) specifically for the target computing platform <NUM>. The compilation and linking by the development tool <NUM> facilitates executing the computer program <NUM> on the target computing platform <NUM>. Alternatively, or in addition, the development tool <NUM> improves the efficiency of execution of the computer program <NUM> when executing on the target computing platform <NUM>.

The computer program <NUM> can include multiple source code files, including, for example but not limited to, a source code file <NUM> ("file" <NUM>), and a source code file <NUM> (file <NUM>). The computer program <NUM> can be open source in some embodiments of the present invention. It is understood that the computer program <NUM> can include several (hundreds, thousands) of source code files, although only two of them are depicted here. Each of the source code files (<NUM>, <NUM>) can include several computer instructions (lines of code), for example, hundreds, thousands, etc. In one or more embodiments of the present invention, the source code files of the computer program <NUM> are organized in a hierarchical manner, for example using a directory structure (not shown).

One or more of the source code files in the computer program <NUM> uses macros <NUM>. For example, the source code file <NUM> includes several macros <NUM>. The depicted macros <NUM> can each be an instance of different macros. Alternatively, or in addition, the macros <NUM> can be associated with a conditional expansion. The conditional expansion can be dependent on one or more configurations of the compiler <NUM>, that a user (e.g., developer) can adjust prior to executing the compiler <NUM>. Alternatively, or in addition, the conditional expansion can be dependent on one or more environmental settings of the computing platform <NUM> (e.g., operating system level variables, hardware type, etc.). Alternatively, or in addition, the conditional expansion can be dependent on runtime option that the user provides at time of execution of the development tool <NUM> (i.e., compiler and linker). Other dependencies of the conditional expansion can be used in other embodiments of the present invention. In one or more embodiments of the present invention, the macros <NUM> that are used in the file <NUM> can be defined in the file <NUM> itself, or any other file in the computer program <NUM>, for example the file <NUM>.

The development tool <NUM> includes a user interface that is used to interact with the source code files <NUM>, <NUM>. A user can navigate the directory structure, and perform operations such as add, delete, copy, paste, move, edit, etc. with the source code files of the computer program <NUM>. The user interface displays the computer instructions of the computer program using one or more contextual visual attributes. For example, computer instructions contents of different types (e.g., conditional statements, function calls, variables, keywords, macros, etc.) can be displayed using different color, different fonts, or other such visual attributes. The visual representation of the computer instructions can be adjusted by the development tool <NUM> based on results of the various features of one or more embodiments of the present invention.

<FIG> depicts an example computer program <NUM> according to one or more embodiments. Two versions of the computer program <NUM> are shown, a first version <NUM>, and a second version <NUM>. The first version <NUM> can be a present version, and the second version <NUM> can be a previous version in some examples. The computer program <NUM> includes several files (<NUM>, <NUM>) that are organized in a directory structure <NUM>.

Comparison results <NUM> of the two versions <NUM>, <NUM> indicate a number of files that are the same, a number of files that are different, a number of files that are similar, a number of orphan files in each version. Here, "same files" includes a file where no change is detected in that file in the two versions <NUM>, <NUM>. "Similar files" includes a file where the change in that file, from the first version <NUM>, to the second version <NUM>, is less than a predetermined amount. For example, if the number of lines that have changed is less than a predetermined number of lines (e.g., <NUM> lines), or less than a predetermined proportion (e.g., <NUM>% change). It is understood that while "changed lines" are used as a metric in the above example, other metrics, such as "changed characters," "changed functions," etc., can be used in other examples. When the change exceeds such a predetermined threshold, the file is deemed to be in the "different files" category. An "orphan file" is a file that exists in one version, but not in the other version. There can be an orphan file in the first version <NUM> (if that file does not exist in the second version <NUM>); and similarly, the second version <NUM> can have an orphan file (second file) if that (second) file does not can exist in the first version <NUM>.

<FIG> depicts two versions of an example source code file <NUM> according to one or more embodiments of the present invention. The first version <NUM> of the source code file <NUM> includes updated computer instructions <NUM> (highlighted portion). The updated computer instructions <NUM> may not be directed to the target computing platform <NUM>. For example, the updated computer instructions <NUM> may not even be compiled by the compiler <NUM> depending on the compile time conditions (specific to the computing platform <NUM>) that may be associated with the updated computer instructions <NUM>. Alternatively, or in addition, in some examples, the object code (<NUM>) corresponding to the updated computer instructions <NUM> may not linked by the linker <NUM> if a determination is made that the object code would not be executable by the computing platform <NUM>.

<FIG> depicts an example source code file according to one or more embodiments of the present invention. Portions of the source code file <NUM> are shown in two columns in <FIG>; however, in some development tools, the source code file <NUM> may be rendered as a single column (i.e., boxes shown on the right in <FIG> may be in same column as the boxes shown on left in <FIG>). The depicted file <NUM> includes several macros <NUM>. It should be noted that all the macros in the file <NUM> are not marked in <FIG>, and also that in other examples, the file <NUM> can include a different number of macros than those depicted. Further, the lines of code depicted in <FIG> can vary in other examples.

One or more of the macros <NUM> are conditional. A dynamic compile time condition <NUM> is associated with such conditional macros, such that the computer instructions in the conditional macros <NUM> are compiled (i.e., converted to object <NUM> code) only if the associated compile time condition <NUM> is satisfied. If the compile time condition <NUM> is not satisfied the computer instructions in the conditional macro <NUM> are not included in the object <NUM>. The compile time conditions <NUM> can indicate a combination type of hardware and software of the target computing platform <NUM>. For example, a compile time condition <NUM> can indicate that the macro <NUM> is to be expanded only if the platform uses a particular operating system such as, LINUX®, AIX®, INTERIX®, Z/OS®, etc. Alternatively, or in addition, the compile time condition <NUM> can indicate that the macro <NUM> is to be expanded only if one or more other source code files (e.g., a header file) is included. In some examples, the expanded macro <NUM> can itself be an inclusion of additional source code files, such as a library, an application programming interface, etc. Alternatively, or in addition, the expanded macro <NUM> can cause a particular type of hardware component or software component to be "mounted. " Here, "mounting" includes acquiring access to the component, e.g., recognizing, reading, and processing a file system structure, a storage medium, etc., before registering the component for use. Several additional or alternative operations can be performed by the computer instructions enclosed in the macros <NUM> in one or more embodiments of the present invention.

<FIG> depicts an example expansion scenario of a macro during debugging according to one or more embodiments of the present invention. In the depicted scenario, the macros TARG 104A, PRO 104B, MYDEF 104C are used. Consider that the computer instructions in the file <NUM> 'a. c' lines <NUM>-<NUM> should be compiled because the compile time condition 202A of macro MYDEF 104C is defined in the runtime command <NUM> to initiate the compiler <NUM> to compile the files <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> into a preprocessed file <NUM>. Here, the desired result is that compile time condition 202A is satisfied, and all corresponding macros are expanded. In the example in <FIG>, the command <NUM> causes IDE <NUM> to execute the compiler <NUM> to export the expanded macros and included files (e.g., a. h <NUM>) information to the preprocessed file a. The preprocessed file <NUM> is used subsequently to generate the object code <NUM>. However, the result of the compilation is not as expected, because the section <NUM>. The reason is that the macro MYDEF 104C got undefined in the file <NUM> 'b. h' line <NUM>. The compile time conditions 202B and 202C cause the subsequent expansion of computer instructions in the object code <NUM> (rather than the desired compile time condition 202A). It can be appreciated that the example scenario here shows a scenario with very few lines of code; however, in large projects with thousands of lines of code, it is a technical challenge to determine such root causes of failures when porting a computer program.

Embodiments of the present invention provide technical solutions that facilitate detecting computer instructions that are enclosed in a macro <NUM>, and further identifying the root cause of a conflict between an enclosed macro and the unenclosed macro. Alternatively, or in addition, embodiments of the present invention can identify macro redefinition paths across several source code files <NUM>, <NUM>, in the computer program <NUM> at the time of compiling. Alternatively, or in addition, one or more embodiments of the present invention facilitate representing (e.g., by highlighting, marking, etc.), in the development tool <NUM>, the portions of the computer program <NUM> (e.g., lines of code) that were compiled into the object file <NUM>, the conflicted macros <NUM>, and macro redefinition paths. In one or more embodiments of the present invention, one or more portions of the computer program <NUM>, such as macros <NUM>, are annotated using predetermined annotations such as, MacroEnclosed, CurrentMacroValue, Preprocesstype, EarlierAssignedMacroValue, etc. In one or more embodiments of the present invention, values are assigned to the predetermined set of variables, such as MacroEnclosed, CurrentMacroValue, Preprocesstype, EarlierAssignedMacroValue, etc. The assigned values are used to facilitate represent the computer program <NUM> in a more readable manner. Further, the values are used to facilitate the user to perform root cause analysis in case of an error.

Further, in one or more embodiments of the present invention, a preprocessor collects and identifies and generates records of the computer instructions that are enclosed (and not enclosed) in macros <NUM>. Further, the compiler <NUM> supports macro definition conflict by comparing compile time conditions <NUM> MacroEnclosed and CurrentMacroValue, to identify the impact on the corresponding macros <NUM>. The compiler (and/or linker) <NUM> supports a macro redefinition path across source code files <NUM>, <NUM> by locating the macro enclosed records with MacroEnclosed 'ON' and runtime options, such as Preprocesstype 'D', to compare AssignedMacroValue and EarlierAssignedMacroValue across the different files. Accordingly, one or more embodiments of the present invention facilitates to analyze and identify the root cause of a macro conflict which can cause computer instructions to be compiled (or not) into the object <NUM> file, and also provide macro redefinition warning across several source code files.

Embodiments of the present invention can achieve such technical solutions by generating the intermediate file <NUM> at compile time of the computer program <NUM>. However, this information is not sufficient to guide the developers and to identify the portions of the computer program <NUM> pieces in the updated version (<NUM>) should be debugged (or analyzed) and which portions can be ignored. In large enterprise size computer programs (millions of lines of code), such information can improve (reduce) the development time and efforts by magnitudes.

For example, in the depicted scenario of <FIG>, lines <NUM>-<NUM> in file 'a. c' (<NUM>) are compiled but the corresponding information is not covered in the intermediate file a. Accordingly, just based on the intermediate file <NUM>, the developer may have chosen to not debug the file a. c (<NUM>), which could be an error. Additionally, in the depicted scenario, the function 'func_cc' in file 'c. c' (<NUM>) is not linked or used, but there are the corresponding macro enclosed records in the intermediate file a. Here, extra resources were expended in capturing information about computer instructions that are not in the executable file <NUM>. Embodiments of the present invention address such technical solutions, and can accordingly, save time and resources, thus providing a practical application to improve technical challenges rooted in computer program development and porting.

<FIG> depicts an example structure of a development tool according to one or more embodiments of the present invention. The development tool <NUM> facilitates identifying macros <NUM>, compile time conditions <NUM>, values of the compile time conditions <NUM>, updating the user interface, debugging the computer program <NUM>, and various other features of the technical solutions described herein. The architecture of the system <NUM> includes a debugger <NUM> that receives a command to initiate identifying macros in the computer program <NUM>. The command can be provided via a command-line, a setting configuration, or any other user interaction by the user.

The development tool <NUM> also includes a macro preprocessor <NUM> that generates macro information <NUM> by analyzing the source code files of the computer program <NUM>. The macro information <NUM> can include the compile time conditions <NUM>, current values of the compile time conditions, assigned compile time condition values, macro names, preprocessor type, referred macro names, etc. The preprocessor type 'S' marks the source code scope enclosed by the macro; whereas 'D' marks the definition of macros. Other preprocessor types can be specified in other embodiments of the present invention. ReferredMacroName specifies a macro name to be used in macro condition during the preprocessing. It is understood that the formatting of the command <NUM> can be varied in other embodiments of the present invention.

The development tool <NUM> also includes an editor <NUM>, for example, a graphical user interface (GUI). The editor <NUM> facilitates viewing and/or editing filenames, computer instructions in the files, line numbers of the computer instructions, macro names, compile time conditions <NUM>, attributes of the compile time conditions <NUM> (e.g., type of value (e.g., integer, character, time, binary, etc.), condition to check, threshold to check, etc.), visual attributes (e.g., color, highlights, font size, font type, etc.), etc..

In addition, the development tool <NUM> includes the compiler <NUM> and the linker <NUM>, which convert the computer program <NUM> into object code <NUM> and machine executable instructions for the target computing platform <NUM>. In one or more embodiments of the present invention, the development tool <NUM> is a separate computing system from the computing platform <NUM>. Alternatively, the development tool <NUM> is part of the computing platform <NUM>, for example, a software executing on the computing platform <NUM>. In other cases, the computing platform <NUM> can be considered as the development tool <NUM>.

<FIG> depicts a flowchart of a method for detecting macros in a computer program and identifying paths of compile time conditions that can cause compilation errors and/or execution errors according to one or more embodiments of the present invention. The method <NUM> can be executed by the development tool <NUM>. The method <NUM> includes receiving a command to compile detect the macros and compile time conditions at time of compiling the computer program <NUM>, at block <NUM>. For example, an option '-p' in the compiling command <NUM> "gcc -DTARG -c a. c -p" triggers the compiler <NUM> to initiate the detection and generate the macro information <NUM> for the computer program <NUM>. Alternatively, or in addition, the trigger could be based on an environment variable associated with the development tool <NUM>, or the operating system of the computing platform <NUM>.

At block <NUM>, in response to the received command, the macro preprocessor <NUM> parses the computer program <NUM> to generate the macro information <NUM>. The macro information <NUM> can identify FileName, MacroEnclosed, LineNoStart/LineNoEnd, PreprocessType, MacroName, AssignedMacroValue, EarlierAssignedMacroValue, SpecificMacroType, ReferredMacroName, CurrentMacroValue, etc. Filename indicates the name of the file <NUM>, <NUM> that uses the macro <NUM>. MacroEnclosed indicates whether the macro <NUM> has a compile time condition <NUM> associated with it. LineNoStart indicates a starting line number in the file <NUM>, <NUM> where the computer instructions of the macro <NUM> start. LineNoEnd indicates an ending line number of the macro <NUM>. PreprocessType indicates an action relative to the compile time condition <NUM>. MacroName indicates a name associated with the macro <NUM>, typically provided by the developer. AssignedMacroValue indicates a value assigned to the compile time condition <NUM>. SpecificMacroType indicates a type of the compile time condition <NUM> and/or the macro <NUM>. ReferredMacroName indicates another macro <NUM> that may be referred by the macro <NUM> that is being parsed. CurrentMacroValue indicates a present value of the compile time condition <NUM>, which can be different from the value that was assigned previously.

Such information can be identified by syntactic and semantic parsing of the computer instructions in the source code files <NUM>, <NUM> of the computer program <NUM>. In some examples, the command can specify particular subset of source code files <NUM>, <NUM> to be parsed to generate the macro information <NUM>.

<FIG> depicts an example scenario of detecting macro information <NUM> according to one or more embodiments of the present invention. In <FIG>, the macro information <NUM> is generated for the example files <NUM>, <NUM>, <NUM> based on the received command <NUM>. It is understood that the macro information <NUM> can be stored in a different format than what is shown in <FIG>. As shown, the macro information <NUM> is parsed to show the location of compile time conditions <NUM> in the source code files <NUM>, <NUM>, <NUM>. Further, values assigned to the compile time conditions <NUM>, either based on the received command or based on the source code is identified. Additionally, where applicable, a previous compile time condition <NUM> (in hierarchy) is also identified and a value assigned to that previous compile time condition <NUM> is also noted. For example, in case of the file "a. h" <NUM>, the compile time condition <NUM> PRO is defined when the previous compile time condition <NUM> TARG is set to <NUM> (in the command line).

The macro information <NUM> that is generated is stored in memory in some embodiments of the present invention. Alternatively, or in addition, the macro information <NUM> is stored in a file. For example, a file "<program name>. p" is created that stores the macro information <NUM>. In some embodiments of the present invention a filename to store the macro information <NUM> can be specified in the command to trigger the preprocessing.

<FIG> depicts an example macro information <NUM> according to one or more embodiments of the present invention. The macro information <NUM> that is depicted is the result of the macro processor <NUM> parsing the computer program <NUM> depicted in <FIG>. As noted elsewhere, FileName denotes the name of the file using a macro <NUM>, e.g., "a. " MacroEnclosed 'ON' indicates that computer instructions are enclosed by a compile time condition <NUM>, which after preprocessing are to be expanded/extracted. MacroEnclosed 'OFF' indicates that computer instructions are not enclosed by a compile time condition <NUM>. LineNoStart and LineNoEnd indicate the start and end line numbers of the computer instructions enclosed by the macro <NUM>, respectively. Preprocesstype 'S' marks the source code scope enclosed by the macro, whereas 'D' marks the definition of macros. MacroName is the name of the macro <NUM> defined. AssignedMacroValue is the value assigned to the compile time condition <NUM> when the compiler <NUM> is triggered. EarlierAssignedMacroValue is the value assigned to the compile time condition <NUM> that is triggered by the last/previous compile time condition <NUM> definition. SpecificMacroType 'T' indicates if the compile time condition <NUM> is related to the target computing platform <NUM>, e.g., _MVS_ for ZOS®, AIX for AIX®. SpecificMacroType 'P' indicates if the macro <NUM> is relative to the target computing platform <NUM>. ReferredMacroName provides the referred name of a compile time condition <NUM> used in computing a compile time condition <NUM> during the preprocessing. CurrentMacroValue is the current value of the compile time condition <NUM> in the corresponding condition check during the preprocessing.

It should be noted that the above provided examples of the various parameters in the macro information <NUM> are not exhaustive, and that in one or more embodiments of the present invention the parameters can have other values assigned.

Referring to the flowchart of the method <NUM>, at block <NUM> the compiler <NUM> compiles the computer instructions, which includes generating source code for the macro(s) <NUM>, depending on the compile time conditions that enclose the macro. <FIG> depicts a flowchart of a method <NUM> for generating the computer instructions for the macro <NUM> according to one or more embodiments of the present invention. For explanation, the description herein includes a walkthrough of the example macro MYDEF <NUM> from <FIG> (lines <NUM>-<NUM> in file "a.

Referring to the flowchart of method <NUM>, the compiler <NUM> checks whether detecting macros has been enabled (block <NUM>), at <NUM>. At block <NUM>, if the macro detection has been triggered, the compiler <NUM> scans the computer program <NUM> using the macro preprocessor <NUM> (at block <NUM>), else, the compiler proceeds with typical macro processing according to existing solutions (at block <NUM>).

At each computer instruction, the compiler <NUM> checks whether the present computer instruction is a definition of a compile time condition <NUM>, at block <NUM>. If the present computer instruction is a definition of a compile time condition <NUM> (e.g., "#undef MYDEF"), the compiler <NUM> assigns flag 'D' to the Preprocesstype, at block <NUM>. Instead, if the computer instruction is a condition of a compile time condition <NUM> (e.g., "a. c" line <NUM>-<NUM>), the compiler <NUM> assigns flag 'S' to Preprocesstype, at block <NUM>. Further, in this case (flag S), the macro name, present value, and type are noted from the computer instruction, at block <NUM>. Further, at block <NUM>, there are computer instructions that are enclosed in the compile time condition <NUM>, the MacroEnclosed is set to 'ON', (e.g., "a. c" line <NUM>-<NUM>), otherwise, it is set to 'OFF' (e.g., "a. c" line <NUM>-<NUM>). Macro information parameters including SpecificMacroType, ReferredMacroName, and and CurrentMacroValue are also recorded at this time in one or more embodiments of the present invention.

In the case of encountering a definition of a compile time condition <NUM> (flag D), the compiler <NUM> checks if the compile time condition <NUM> (e.g., 'MYDEF') was defined before, at block <NUM>. The check is performed by searching the macro name through the existing information in the macro information <NUM>. If the compile time condition <NUM> was defined before, the compiler <NUM> searches and obtains the last value assigned to the compile time condition <NUM> (e.g., '<NUM>' in the ongoing example of MYDEF; <NUM> is passed by compiling command option '-DMYDEF'), at block <NUM>. The obtained value is recorded into EarlierAssignedMacroValue.

The compiler <NUM> also collects the metadata associated with the macro <NUM> such as, file name, line numbers (start, end), etc., at block <NUM>. The captured information is stored in the macro information <NUM> structure (e.g., separate file, database, memory, etc.), at block <NUM>.

The compiler <NUM> repeats this process for each computer instruction in the computer program <NUM>, and at least for macros <NUM> in the computer program. Once all of the macros <NUM> have been processed in this manner and the macro information <NUM> is captured, the compiler <NUM> continues to expand the macros <NUM> and compile the computer instructions in the computer program <NUM> as it typically does, at block <NUM>.

Continuing with the flowchart of the method <NUM>, at block <NUM>, macro conflicts are checked in the source code that is expanded by the compiler <NUM>. <FIG> depicts a flowchart of a method <NUM> for operations performed for checking the macro conflicts according to one or more embodiments of the present invention. For explanation, the description herein includes a walkthrough of the example macro MYDEF <NUM> from <FIG> (lines <NUM>-<NUM> in file "a. In this example, the definition of macro 'MYDEF' is passed as part of the compiling command. Consider that, all computer instruction that meet the condition including 'MYDEF' being defined are to be expanded in the object file <NUM>, however, the computer instructions in the file 'a. c' <NUM> lines <NUM>-<NUM> are not expanded, and hence not compiled.

The conflict checking facilitates identifying the root cause of the conflict between a macro <NUM> that is to be enclosed, but is not because of conflicting compile time conditions <NUM>, as in this case. At blocks <NUM>, <NUM>, the compiler <NUM> selects the macro to be checked and checks it specific macro type, (i.e., the macro type is 'T' (target), or set by the user). In this example, 'MYDEF' is the selected macro to check. If the type of macro <NUM> is not a predetermined type, (such as 'T'), the conflict check does not have to be performed, at block <NUM>.

If the macro <NUM> is of the predetermined type(s), the compiler <NUM> searches macro information <NUM> for the ReferredMacroName (e.g., 'MYDEF'), at block <NUM>. In the example of file "a. c" <NUM>, two records are identified (lines <NUM>-<NUM>, and lines <NUM>-<NUM>, which both use MYDEF in compile time condition <NUM>).

At blocks <NUM> and <NUM>, the next macro information <NUM> is read and the current value of the compile time condition <NUM> associated with the macro <NUM> is checked with the current value. If the compile time condition <NUM> is satisfied, the next record(s) are checked for conflicts in the same manner (repeat block <NUM>). Alternatively, if the compile time condition <NUM> has an ambiguous evaluation (e.g., values switched between <NUM> and <NUM>), the compiler <NUM> denotes the record in the macro information <NUM> as a potential conflict, at block <NUM>.

Further, at block <NUM>, the development tool <NUM> notifies the user of the potential conflict. The notification can be a popup window, a message, or any other type of electronic notification. Further, in the development tool <NUM>, the computer instructions associated with the macro <NUM> are marked, at block <NUM>. The marking can be performed by highlighting the computer instructions, for example, by changing one or more of: a foreground color, a background color, a font, etc. Alternatively, or in addition, the marking can include changing a border, annotations, etc. associated with the computer instructions of the macro <NUM>. The method <NUM> is repeated for any additional records (block <NUM>) of the macro <NUM>.

In addition, the development tool also marks computer instructions associated with other compile time conditions <NUM> which trigger the conflict (e.g., compile time condition 'PRO = <NUM>' impacts 'MYDEF'). The other compile time conditions <NUM> that interact with the macro <NUM> being checked can be identified from the macro information <NUM> record for the macro <NUM>. For example, the macro information <NUM> can be searched to get the definition of the other compile time condition <NUM> (e.g., 'PRO').

In one or more examples, the user can specify one or more target macros <NUM> for which the conflicts are to be checked, for example, via the initiating command. Alternatively, or in addition, every distinct macro <NUM> is checked for conflicts in this manner.

Referring to the flowchart of method <NUM>, once the conflicting macros are highlighted, at block <NUM>, the development tool provides support for macro redefinition path. <FIG> depicts a flowchart of a method <NUM> for macro redefinition path support according to one or more embodiments of the present invention. For explanation, the description herein includes a walkthrough of the example macro MYDEF <NUM> from <FIG> (lines <NUM>-<NUM> in file "a.

The method <NUM> includes, at block <NUM>, initiating a path-change detection of a macro <NUM>, where the macro is defined in one file and used in one or more other files in the computer program <NUM>. Further, a macro path-check option of the linker <NUM> is checked, at block <NUM>. If macro path-check option is not switched ON, for example, via the initiating command (block <NUM>), via an environment variable, or any other setting that the linker <NUM> can check, the path change detection is terminated, at block <NUM>. Alternatively, if the setting is switch ON, a record from the macro information <NUM> is read for further analysis, at block <NUM>.

The analysis includes checking at least four conditions. Is MacroEnclosed ON (<NUM>); is PreprocessType = D (<NUM>); does EarlierAssignedMacroValue exists (<NUM>); and is new compile time condition value equal to previous compile time condition value (<NUM>). Based on the outcome of each of these condition checks, the record can be deemed to require a redefining a path, i.e., where the compile time condition is set and where it is used, at block <NUM>. This process is repeated for every record in the macro information <NUM>.

In the ongoing example scenario, the value '<NUM>' of macro 'MYDEF' is passed from the option '-DMYDEF' in the compiling command. Considering that the path check is to be performed a records from files 'a. p' is read. If the value of MacroEnclosed is 'ON' (<NUM>) then 'b. h' line <NUM> is read, else, 'b. h' line <NUM>-<NUM> are read. Further, if the value of Preprocesstype is 'D' (<NUM>), one set of computer instructions are to be used (i. h' line <NUM>); else, a second set of computer instructions is to be used (i.e., 'b. h' line2-<NUM>). Next, if EarlierAssignedMacroValue exists (<NUM>), (i.e., PRO exists per 'b. h' line <NUM>); else other option has to be performed (i.e., 'b. Further, if new value of compile time condition <NUM> is equal to earlier macro value (<NUM>), then use the compile time condition <NUM> value (i.e., 'b. c' line3); else, if the values do not match, the record is marked for macro redefinition path.

In addition to detecting and using the above described macro information <NUM>, one or more embodiments of the present invention facilitate updating source code in large-scale (enterprise) projects with support for multi-level and compiling-unit-crossed isolation including identifying compiled and linked source code. For this, in addition to the above information, the compiler <NUM> detects and provides a StatementCompiledValid states for each macro <NUM> (see <FIG>). The macro preprocessor <NUM> provides the information to the linker <NUM>, which can further add to the macro information <NUM> information about ObjectLinkedValid and FuncSectionLinkedValid based on checking if the object file <NUM> and a function are linked into the executable file(s) <NUM>. The flags added in the macro information <NUM> along with the identity of the macro (e.g., name) are used to isolate the portion of the computer program <NUM> that has been compiled and linked into the execution file <NUM> hierarchically.

Accordingly, the macro preprocessor <NUM> in combination with the linker <NUM>, can generate, at build time, the macro information <NUM> that can facilitate detecting a portion of source code in the compute program <NUM> that has not (or has) been compiled and linked into the execution file <NUM>. or library files. The detection can further be used to update the user interface so as to guide the user to focus (i.e., analyze, edit, debug, etc.) on portions of the computer program <NUM>, which is compiled and linked validly. Embodiments of the present invention, accordingly, reduce development effort and improves project efficiency of delivery.

The improvements are achieved based on generating the macro information <NUM> using the macro preprocessor, and further enhancing the macro information <NUM> using the linker <NUM> to preprocess the source code files <NUM> to determine the status values, for each macro <NUM>, representing ObjectLinkedValid, FuncSectionLinkedValid and StatementCompiledValid. ObjectLinkedValid represents linking invalidity when the object file is not linked into the executable file <NUM>. FuncSectionLinkedValid represents whether linking invalidity of a function in the computer program <NUM> when the (unused) function section is removed from the computer program <NUM>. Using such information, the development tool <NUM> analyzes and removes computer instructions, such as objects and function sections that are not part of the executable file <NUM>, and then updates the macro information <NUM>, particularly the status of ObjectLinkedValid, and FuncSectionLinkedValid. The compiler <NUM> marks the flag StatementCompiledValid with the compiling validity if the computer instructions unenclosed by the compile time condition <NUM> are compiled into the object file <NUM>.

In some embodiments of the present invention, the development tool <NUM> includes a source code isolation module <NUM> that determines the linking validity of portions of the object file <NUM> based on the value of the flag 'ObjectLinkedValid' from the macro information <NUM>. If the value is invalid (e.g., 'OFF'), then the source code isolation module <NUM> skips all the macro information records of the object file. Else, source code isolation module <NUM> continues to determine the validity of a linked function section, and indicates the validity based on the value of flag 'FuncSectionLinkedValid'. For example, if the value is invalid (e.g., 'OFF'), then the source code isolation module <NUM> skips the macro enclosed records of the function section. Otherwise, the source code isolation module <NUM> continues to determine validity of the source code segment compilation, and represents the validity using the flag 'StatementCompiledValid'. If the value is valid (e.g., 'ON'), then the source code isolation module <NUM> inserts the record into valid source sections. Otherwise, the source code isolation module <NUM> continues to determine validity of the macro and represent the validity using the flag 'MacroEnclosed'. If the value is valid (e.g., 'ON'), then the source code isolation module <NUM> inserts the record into valid source sections. The editor and user interface <NUM> can highlight the records of valid source code sections in one or more embodiments of the present invention.

<FIG> depicts a mapping of computer instructions and the macro information <NUM> according to one or more embodiments of the present invention. It is understood that a particular example scenario using the files from <FIG> is depicted, and that in other embodiments of the present invention the macro information <NUM> can be different. In some embodiments of the present information the macro information <NUM> with the additional flag values based on the linker <NUM> is generated in response to the command <NUM> specifying that such information is to be generated. For example, the command <NUM> includes the parameter 'p' and the names of the source code files <NUM> to be processed in this manner to generate the macro information <NUM>.

<FIG> depicts an example macro information <NUM> according to one or more embodiments of the present invention. The macro information <NUM> in <FIG> includes the three macro enclosed fields ObjectLinkedValid, FuncSectionLinkedValid, and StatementCompiledValid, which are generated when the development tool <NUM>, using the macro preprocessor <NUM> and the linker <NUM> generates the intermediate file <NUM> (e.g., 'a. p'), which includes the macro information <NUM> related to the source code files <NUM>. In addition to the macro information <NUM> depicted in another example (in which the linker information was not included), the macro information <NUM> in this case includes ObjectLinkedValid, which has a value 'ON' if an object (in the object file <NUM>) corresponding to the macro <NUM> is linked in the execution file <NUM>; and has a value 'OFF' otherwise. The value of FuncSectionLinkedValid is set to 'ON' if a function enclosed by a macro <NUM> is linked in the execution file <NUM>; and is set to 'OFF' otherwise. Further, the value of StatementCompiledValid is set to 'ON' if a computer instruction enclosed in the macro <NUM> is compiled into the object file <NUM>; and is set to 'OFF' otherwise. Further yet, in one or more embodiments of the present invention, the MacroEnclosed flag is set to 'ON' for a macro <NUM> if the computer instructions of the macro <NUM> are enclosed by a compile time condition <NUM> that is active after preprocessing; and set to 'OFF' otherwise. It is understood that 'ON' and 'OFF' can be replaced with other values in other embodiments.

<FIG> depicts a flowchart of a method <NUM> for generating the computer instructions for the macro <NUM> according to one or more embodiments of the present invention. For explanation, the description herein includes a walkthrough of the example macro MYDEF <NUM> from <FIG> (lines <NUM>-<NUM> in file "a. The compiler <NUM> checks whether detecting macros has been enabled (block <NUM>), at <NUM>. At block <NUM>, if the macro detection has been triggered, the compiler <NUM> scans the computer program <NUM> using the macro preprocessor <NUM> (at block <NUM>), else, the compiler <NUM> proceeds with typical macro processing according to existing solutions (at block <NUM>).

At each computer instruction, the compiler <NUM> checks whether the present computer instruction is a definition of a compile time condition <NUM>, at block <NUM>. If the present computer instruction is a definition of a compile time condition <NUM> (e.g., "#undef MYDEF"), the compiler <NUM> assigns flag 'D' to the Preprocesstype, at block <NUM>. Instead, if the computer instruction is a condition of a compile time condition <NUM> (e.g., "a. c" line <NUM>-<NUM>), the development tool <NUM> checks if the value of the compile time condition <NUM>, is ON, at block <NUM>. In other words, it is checked if the value of the compile time condition <NUM> facilitates compiling the enclosed macro <NUM>.

If the compile time condition <NUM> exists, and if it is ON, the compiler <NUM> assigns flag 'S' to Preprocesstype, at block <NUM>. Further, in this case (flag S), the macro name, present value, and type are noted from the computer instruction, at block <NUM>. If the compile time condition <NUM> exists, and if it is OFF, the StatementCompiledValid flag is set to 'ON,' at block <NUM>.

Further, at block <NUM>, if there are computer instructions that are enclosed in the compile time condition <NUM>, the MacroEnclosed is set to 'ON', (e.g., "a. c" line <NUM>-<NUM>), otherwise, it is set to 'OFF' (e.g., "a. c" line <NUM>-<NUM>). Macro information parameters including SpecificMacroType, ReferredMacroName, and and CurrentMacroValue are also recorded at this time in one or more embodiments of the present invention.

In the case of encountering a definition of a compile time condition <NUM> (flag D), the compiler <NUM> checks if the compile time condition <NUM> (e.g., 'MYDEF') was defined before, at block <NUM>. The check is performed by searching the macro name through the existing information in the macro information <NUM>. If the compile time condition <NUM> was defined before, the development tool <NUM> searches and obtains the last value assigned to the compile time condition <NUM> (e.g., '<NUM>' in the ongoing example of MYDEF; <NUM> is passed by compiling command option '-DMYDEF'), at block <NUM>. The obtained value is recorded into EarlierAssignedMacroValue.

The development tool <NUM> also collects the metadata associated with the macro <NUM> such as, file name, line numbers (start, end), etc., at block <NUM>. The captured information is stored in the macro information <NUM> structure (e.g., separate file, database, memory, etc.), at block <NUM>.

The development tool <NUM> repeats this process for each computer instruction in the computer program <NUM>, and at least for macros <NUM> in the computer program. Once all of the macros <NUM> have been processed in this manner and the macro information <NUM> is captured, the development tool <NUM> continues to expand the macros <NUM> and compile and link the computer instructions in the computer program <NUM> as it typically does, at block <NUM>.

<FIG> depicts a flowchart of a method to update a macro enclosed data with information about removal of an unused function (i.e., section) from the source code files or object files according to one or more embodiments of the present invention. <FIG> depicts an example implementation of the method <NUM> from <FIG> in an example scenario. The linker <NUM> is triggered to determine parts of the macro information <NUM> by the parameters specified in the input command <NUM>.

The development tool <NUM> determines if MacroEnclosed flag is ON, at <NUM>, and <NUM>. If the flag is OFF, the linker information is not added in the macro information <NUM>. Otherwise, if the MacroEnclosed is ON, at block <NUM>, an object from the object file <NUM> is parsed, where the object is corresponding to computer instructions that are enclosed in a macro <NUM> based on a compile time condition <NUM>. The compile time condition <NUM> that encloses the macro can be the one specified/defined in the command <NUM>. (e.g., MYDEF).

At block <NUM>, the linker <NUM> determines if the object identified was included in the executable file <NUM>, or if it was removed prior to generating the executable file <NUM>. Here, "object" can be a source code file <NUM>, for example, "c. " If the object has been removed, at block <NUM>, the development tool iterates over all records (in the macro information <NUM>) of that object, which have the same conditions, i.e., MacroEnclosed = ON, and object removed. For each of these records, the development tool <NUM> sets the ObjectLinkedValid = OFF, at block <NUM>. For example, in the scenario of <FIG>, the file "c. c" is not linked, and thus is an object that is unused and removed by the linker <NUM>. Accordingly, the ObjectLinkedValid of all the records in the macro information <NUM> corresponding to that file are marked 'OFF' (marked as "<NUM>" in <FIG>).

Alternatively, if the object has not been removed (<NUM>), the development tool parses and reads a function section, at block <NUM>. Here, a function section is a set of computer instructions that are designated as a "function" in computing programming language. The development tool <NUM> determines whether the function section is unused, and removed prior to generating the executable file <NUM>, at block <NUM>. For example, the function section may be unused and removed if that function is never used in the rest of the computer program <NUM>. Alternatively, or in addition, the function section may be unused and removed if the entire function is enclosed in a compile time condition <NUM> that is not ON at time of compiling. Alternatively, or in addition, the function can be removed because the computer instructions inside the function are enclosed in a compile time condition <NUM> that is not ON, and hence during optimization, the linker removes that function. In the example of <FIG>, the function func_ee() is removed for such optimization. There can be several other reasons why the function is unused and hence, removed prior to generating the executable file <NUM>.

In the case the function is unused and removed, the development tool <NUM> traverses the macro information <NUM> to identify other records/entries corresponding to that function with MacroEnclosed = ON, at block <NUM>. For each of these entries, the FuncSectionLinkedValid is set to OFF, at block <NUM>. In the example of <FIG>, because the func_ee() is removed during optimization by the linker <NUM>, then all MacroEnclosed records of the function section are identified and the field 'FuncSectionLinkedValid' is assigned 'OFF' for each of them as shown (see "<NUM>" that shows processing computer instructions from a source code file "d.

The method <NUM> is completed when all the objects and functions in the object file <NUM> are parsed and the macro information <NUM> updated as described. In this manner, the development tool can add/update entries/records to the macro information <NUM>, and further use the records/entries in the macro information <NUM> to identify parts of the computer program <NUM> that are not being included in the executable file <NUM>.

<FIG> depicts a flowchart of a method <NUM> for isolating source code portions according to one or more embodiments of the present invention. The development tool <NUM> traverses through the macro information <NUM> and reads the next record/entry to be processed, at block <NUM>. If the record satisfies all three conditions, ObjectLinkedValid=ON, FuncSectionLinkedValid=ON, StatementCompiledValid=ON, then the record is marked as a valid code section, i.e., that section of computer instructions is compiled, linked, and included in the executable file <NUM> (blocks <NUM>, <NUM>, <NUM>, and <NUM>). Alternatively, if ObjectLinkedValid=ON, FuncSectionLinkedValid=ON, StatementCompiledValid=OFF, and MacroEnclosed=OFF, then the record is marked as a valid code section (blocks <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>). The marking can include adding a flag to each record that indicates Valid/Invalid. Alternatively, or in addition, the marking can include moving the record to a section of the macro information <NUM>, where all records in that section are deemed to be associated with valid computer instructions. Here 'valid' indicates that the computer instruction in the computer program is compiled, linked, and included in the executable file <NUM>; whereas an 'invalid' computer instruction does not result in machine executable code that is included in the executable file <NUM>.

If, for a record in the macro information, the ObjectLinkedValid = OFF, the filename associated with that record is assigned as an InvalidObjFile, at blocks <NUM>, <NUM>. All the records in the macro information <NUM> that are associated with the same filename are skipped from further processing, at blocks <NUM>, <NUM>. In some embodiments, the records associated with the same filename are marked invalid.

In this manner, the method <NUM> can isolate the records in the macro information <NUM> that are corresponding to valid computer instructions.

<FIG> depicts an example of code isolation being performed using the method <NUM> according to one or more embodiments of the present invention. The example scenario is shown for the various source code files <NUM>, where the intermediate file <NUM> with the macro information <NUM> is generated. Records for the various sections in the source code files <NUM> are identified with arrows and numbers. As can be seen, once the file "c. c" is identified as InvalidObjFile, all the records that are associated with that file are deemed invalid (see "<NUM>"). If the FuncSectionLinkedValid=OFF is found in a record, the development tool <NUM> continues to the next record. Instead, if the FuncSectionLinkedValid=ON, and if the StatementCompiledValid=ON is found in the record, the record is deemed to be valid (see "<NUM>"). Instead, if StatementCompiledValid=OFF, and if the MacroEnclosed=ON, the records are deemed invalid (see "<NUM>").

Embodiments of the present invention provide technical solutions to analyze/isolate the unneeded files/functions in porting large-scale project in an efficient and improved manner compared to existing solutions. embodiments of the present invention, accordingly, increase the efficiency of keeping large-scale projects current with upstream changes and branches that may include code changes made in an open source community. One or more embodiments of the present invention facilitate finding if the code update in upstream branches is needed to be included in a ported version. If it is not required for the target computing platform <NUM>, the updates need not be analyzed and debugged. Further, one or more embodiments of the present invention facilitate editor/user interfaces of software development tools to provide highly readable and more friendly views of large-scale enterprise projects by marking sections of the computer program based on techniques described herein.

Additionally, the technical solutions described herein provide a practical application to support source code macro analysis by identifying and using macro information, which includes determining MacroEnclosed, CurrentMacroValue, Preprocesstype, and EarlierAssignedMacroValue, among other parameters as part of a record for each macro and compile time condition. In one or more embodiments of the present invention, a preprocessor collects and generates the macro information records for all macros in a computer program, and identifies computer instructions that are enclosed or unenclosed based on the macro definition. A compiler and/or linker analyzes the macro information to detect macro definition conflicts by comparing MacroEnclosed status and CurrentMacroValue of the user-specified or default specified type macro. The tools then search records in the macro information to determine the corresponding definition of macros which make possible impact. Further, the linker supports the macro redefinition path across compiling units, e.g., files, by locating the records of macro information with the status of macroEnclosed and the value of Preprocesstype, determining the valid redefinition after comparing AssignedMacroValue and EarlierAssignedMacroValue.

The technical solutions described herein provide an improvement to computing technology, and particularly debugging. In one or more embodiments of the present invention, technical solutions herein facilitate to analyze/figure out the root cause of macro conflict which causes one or more computer instructions to not be compiled into object file as expected and give macro redefinition warning across compiling units, e.g., files. The technical solutions herein also increase the efficiency of the root cause locating using the macro information. The technical solutions herein also improve identifying macro redefinition for developers, especially for large enterprise opensource projects with complicated macros used. The technical solutions facilitate an editor/GUI to provide readable and more user-friendly views of the macros and compile time conditions that cause conflicts during compilation.

The technical solutions described herein can be, or can be part of compilers and IDEs, like ECLIPSE®, VISUAL STUDIO®, etc. It is understood that although examples herein are described using a particular computer programming language, the technical solutions herein are not limited to any particular computer programming language.

<FIG> depicts an example output according to one or more embodiments of the present invention. The file 'a. c' is analyzed to generate the macro information in response to a command to preprocess the computer program (step <NUM>). The macro information is read by the editor to highlight/mark one or more computer instructions in the computer program (steps <NUM>, <NUM>). <FIG> shows another output according to one or more embodiments of the present invention. Here, file 'a. h' is preprocessed in response to a command to generate the macro information. The macro information is used to display pop ups to the user with notifications. Alternatively, or in addition, during user interaction with the computer program, even with a different file, the computer instructions that will be part of the object code are marked, for example, on mouse-over or other such user interactions. The user interfaces in <FIG> and <FIG> also depict code sections that are not included in the executable file <NUM> using embodiments of the present invention (e.g., method <NUM>).

Workloads layer <NUM> provides examples of functionality for which the cloud computing environment may be utilized. Examples of workloads and functions which may be provided from this layer include: mapping and navigation <NUM>; software development and lifecycle management <NUM>; virtual classroom education delivery <NUM>; data analytics processing <NUM>; transaction processing <NUM>; and computer program processing and analyzing <NUM>.

Turning now to <FIG>, a computer system <NUM> is generally shown in accordance with an embodiment. The computer system <NUM> can be an electronic, computer framework comprising and/or employing any number and combination of computing devices and networks utilizing various communication technologies, as described herein. The computer system <NUM> can be easily scalable, extensible, and modular, with the ability to change to different services or reconfigure some features independently of others. The computer system <NUM> may be, for example, a server, desktop computer, laptop computer, tablet computer, or smartphone. In some examples, computer system <NUM> may be a cloud computing node. Computer system <NUM> may be described in the general context of computer system executable instructions, such as program modules, being executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, and so on that perform particular tasks or implement particular abstract data types. Computer system <NUM> may be practiced in distributed cloud computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media including memory storage devices.

As shown in <FIG>, the computer system <NUM> has one or more central processing units (CPU(s)) 2301a, 2301b, 2301c, etc. (collectively or generically referred to as processor(s) <NUM>). The processors <NUM> can be a single-core processor, multi-core processor, computing cluster, or any number of other configurations. The processors <NUM>, also referred to as processing circuits, are coupled via a system bus <NUM> to a system memory <NUM> and various other components. The system memory <NUM> can include a read only memory (ROM) <NUM> and a random access memory (RAM) <NUM>. The ROM <NUM> is coupled to the system bus <NUM> and may include a basic input/output system (BIOS), which controls certain basic functions of the computer system <NUM>. The RAM is read-write memory coupled to the system bus <NUM> for use by the processors <NUM>. The system memory <NUM> provides temporary memory space for operations of said instructions during operation. The system memory <NUM> can include random access memory (RAM), read only memory, flash memory, or any other suitable memory systems.

The computer system <NUM> comprises an input/output (I/O) adapter <NUM> and a communications adapter <NUM> coupled to the system bus <NUM>. The I/O adapter <NUM> may be a small computer system interface (SCSI) adapter that communicates with a hard disk <NUM> and/or any other similar component. The I/O adapter <NUM> and the hard disk <NUM> are collectively referred to herein as a mass storage <NUM>.

Software <NUM> for execution on the computer system <NUM> may be stored in the mass storage <NUM>. The mass storage <NUM> is an example of a tangible storage medium readable by the processors <NUM>, where the software <NUM> is stored as instructions for execution by the processors <NUM> to cause the computer system <NUM> to operate, such as is described herein below with respect to the various Figures. Examples of computer program product and the execution of such instruction is discussed herein in more detail. The communications adapter <NUM> interconnects the system bus <NUM> with a network <NUM>, which may be an outside network, enabling the computer system <NUM> to communicate with other such systems. In one embodiment, a portion of the system memory <NUM> and the mass storage <NUM> collectively store an operating system, which may be any appropriate operating system, such as the z/OS or AIX operating system from IBM Corporation, to coordinate the functions of the various components shown in <FIG>.

Additional input/output devices are shown as connected to the system bus <NUM> via a display adapter <NUM> and an interface adapter <NUM> and. In one embodiment, the adapters <NUM>, <NUM>, <NUM>, and <NUM> may be connected to one or more I/O buses that are connected to the system bus <NUM> via an intermediate bus bridge (not shown). A display <NUM> (e.g., a screen or a display monitor) is connected to the system bus <NUM> by a display adapter <NUM>, which may include a graphics controller to improve the performance of graphics intensive applications and a video controller. A keyboard <NUM>, a mouse <NUM>, a speaker <NUM>, etc. can be interconnected to the system bus <NUM> via the interface adapter <NUM>, which may include, for example, a Super I/O chip integrating multiple device adapters into a single integrated circuit. Suitable I/O buses for connecting peripheral devices such as hard disk controllers, network adapters, and graphics adapters typically include common protocols, such as the Peripheral Component Interconnect (PCI). Thus, as configured in <FIG>, the computer system <NUM> includes processing capability in the form of the processors <NUM>, and storage capability including the system memory <NUM> and the mass storage <NUM>, input means such as the keyboard <NUM> and the mouse <NUM>, and output capability including the speaker <NUM> and the display <NUM>.

In some embodiments, the communications adapter <NUM> can transmit data using any suitable interface or protocol, such as the internet small computer system interface, among others. The network <NUM> may be a cellular network, a radio network, a wide area network (WAN), a local area network (LAN), or the Internet, among others. An external computing device may connect to the computer system <NUM> through the network <NUM>. In some examples, an external computing device may be an external webserver or a cloud computing node.

It is to be understood that the block diagram of <FIG> is not intended to indicate that the computer system <NUM> is to include all of the components shown in <FIG>. Rather, the computer system <NUM> can include any appropriate fewer or additional components not illustrated in <FIG> (e.g., additional memory components, embedded controllers, modules, additional network interfaces, etc.). Further, the embodiments described herein with respect to computer system <NUM> may be implemented with any appropriate logic, wherein the logic, as referred to herein, can include any suitable hardware (e.g., a processor, an embedded controller, or an application specific integrated circuit, among others), software (e.g., an application, among others), firmware, or any suitable combination of hardware, software, and firmware, in various embodiments.

The computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions thereon for causing a processor to carry out aspects of the present invention.

The computer-readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer-readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

Computer-readable program instructions described herein can be downloaded to respective computing/processing devices from a computer-readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. A network adapter card or network interface in each computing/processing device receives computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing/processing device.

Computer-readable program instructions for carrying out operations of the present invention may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or either source-code or object code written in any combination of one or more programming languages, including an object-oriented programming language such as Smalltalk, C++, or the like, and procedural programming languages, such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer-readable program instruction by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present invention.

It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer-readable program instructions.

These computer-readable program instructions may be provided to a processor of a general-purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer-readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.

The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer-implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks.

Claim 1:
A computer-implemented method comprising:
receiving, by a processor, an updated version of a computer program (<NUM>), the updated version comprises a plurality of source code changes;
preprocessing, by a compiler (<NUM>), the source code changes for a target computing platform, wherein preprocessing the source code changes by the compiler comprises:
identifying a compile time condition (<NUM>) associated with one or more computer instructions enclosed by a macro;
determining a current value of the compile time condition at the time of compiling the updated version of the computer program for the target computing platform;
wherein determining the current value comprises:
in response to the macro defined before, getting (<NUM>) a macro information record for the macro;
in response to the compile time condition being met, determining object code corresponding to the one or more computer instructions based on the current value of the compile time condition; and
storing the macro information record (<NUM>) for the macro, the macro information record including the compile time condition, the current value of the compile time condition, and an identification of the one or more computer instructions and an indication that the code of the macro has been compiled;
and
preprocessing, by a linker (<NUM>), the source code changes for the target computing platform,
wherein preprocessing the source code changes by the linker comprises:
in response to the checking in a macro information record that the code of the macro has not been compiled, updating the macro information record to indicate that the macro is not linked into the executable file.