WO2002015007A1 - Platform independent project built and management tool - Google Patents

Platform independent project built and management tool Download PDF

Info

Publication number
WO2002015007A1
WO2002015007A1 PCT/US2001/024924 US0124924W WO0215007A1 WO 2002015007 A1 WO2002015007 A1 WO 2002015007A1 US 0124924 W US0124924 W US 0124924W WO 0215007 A1 WO0215007 A1 WO 0215007A1
Authority
WO
WIPO (PCT)
Prior art keywords
file
platform
project
list
directory
Prior art date
Application number
PCT/US2001/024924
Other languages
French (fr)
Inventor
Jonathan Shapiro
Original Assignee
Bbnt Solutions Llc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/879,750 external-priority patent/US6694778B2/en
Application filed by Bbnt Solutions Llc filed Critical Bbnt Solutions Llc
Priority to AU2001283211A priority Critical patent/AU2001283211A1/en
Publication of WO2002015007A1 publication Critical patent/WO2002015007A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/70Software maintenance or management
    • G06F8/71Version control; Configuration management

Definitions

  • the present mvention relates to computer software project build and management tools and, in particular, to platform-independent and configurable project build and management tools.
  • Computer source code is the human-readable format of instructions to a computer, and source code is generally written using symbols and expressions that comprise a particular programming language. Common programming languages include C, C++, and JavaTM.
  • Computer software is the intangible set of computer readable information and instructions that cause a computer to operate in a desired way, and a complete unit of computer software is sometimes called a computer software package.
  • a computer software module is a component of a computer software package.
  • Object code format is an intermediate format between source code and a linked executable.
  • the linking process combines multiple object code format modules into one or more executable modules with appropriately configured interrelationships among the constituent object code modules.
  • Computer software modules are commonly built or compiled from source-code files into an object code format and then linked into an executable format that can be run on a particular type of a target computer system.
  • the computer system on which the executable software is built is called the "host platform,” because it "hosts" the construction process.
  • the computer system on which the software will eventually execute is referred to as the "target platform.”
  • Computer systems are sometimes called platforms, because of the analogy to a foundation on which the computer software is built to create a functional application.
  • source-code is written with conditional parameters so that the source code can be built to run on a number of platforms.
  • the set of source code that is sufficient to be built into a software package providing a predefined set of functionality is sometimes called a project.
  • Project build and management tools are typically used to automate the task of examining and compiling projects that may comprise many source-code files.
  • Atypical commercial software product maybe made up of source code comprising hundreds or thousands of source code files, and each source code file may have multiple versions corresponding to multiple platforms and projects.
  • Project build and management tools may automatically obtain the appropriate source code files corresponding to a particular project, set the appropriate platform parameters corresponding to the desired platform, and then build the project.
  • a tool called "make” which is generally known to those skilled in the art, is capable of inspecting source-code files to determine whether a corresponding object code or executable file needs to be built or rebuilt based on whether the corresponding source-code file has been modified.
  • the configuration-input information to the "make" program is generally referred to as a Makefile.
  • Makefile information such as project version and platform parameters may be specified.
  • Autoconf is a freely available tool for the host and target platform specific building of software. According to its authors, "Autoconf is a tool for producing shell scripts that automatically configure software source-code packages to adapt to many kinds of UNIX® compatible systems.” David MacKenzie and Ben Elliston, Autoconf, Creating Automatic Configuration Scripts, Edition 2.13, for Autoconf version 2.13, December 1998, available at www.gnu.org/manual/autoconf/html_mono/autoconf.html. Autoconf has several deficiencies, however .First, Autoconf would allow source code developed for one client to be delivered to another. Autoconf manages a single set of source files and creates different object files by using macros inside the source. Specific software features are then enabled or disabled using preprocessor directives in a header file. Autoconf does not manage separate sets of source files for each project and platform on a single shared directory tree while also allowing any file to be shared among any set of projects or platform builds.
  • Autoconf does not inherently interact with a version control system such as the Revision Control System (“RCS”) or The Concurrent Versions System (“CVS”). Therefore, Autoconf itself does not provide for a platform- independent build environment that can be easily configured and modified through the use of project specific database files. In fact, no known system satisfies these needs.
  • RCS Revision Control System
  • CVS Concurrent Versions System
  • Autoconf imposes certain restrictions on a software developer.
  • Autoconf imposes restrictions on certain conditional preprocessor directives.
  • Autoconf does not support having, in the same directory tree both directories that are parts of a larger package and directories that are independent packages.
  • Autoconf also requires versions of the "make" tool that support the VPATH variable, which specifies a directory search list that "make” searches when determining which files to rebuild, in order to build a new software package.
  • Bourne shell Scripting languages such as the Bourne shell are useful for implementing processes on multiple platforms.
  • the Bourne shell can be used as a high-level programming language on any system that supports the Bourne shell command interpreter.
  • the Bourne shell is available on essentially all UNIX-like systems and on other systems, such as, for example, Windows, using the Cygwin tools available from Red Hat, Inc. of Research Triangle Park, North Carolina.
  • Known systems cannot utilize project and platform specific database information to store information used by programs which are normally statically configured using various scripts. For example, in known systems, Makefiles are configured statically with a SOURCE statement that defines what the Makefile will build when the "make" tool is invoked. Alternate targets inside the Makefile are commonly used to allow a single Makefile to define different sets of objects to build, and separate Makefiles are typically used to create separate projects. Known systems do not allow a single database to be updated in order to add a new file to the list of objects to be built by make and to be checked in and out of a version control system.
  • the present invention meets the above needs that are lacking in the art as well as creating additional advantages that maybe learned by practicing the invention.
  • Systems and methods consistent with the present invention provide an extensible mechanism whereby a software developer may update a database to add source-code files and directories to particular projects. Furthermore, the use of free software foundation tools provides a developer with a uniform "make" environment, thus allowing the use of the invention on different platforms such as Windows as well as UNIX and Linux.
  • a method for archiving documentation files in a manner similar to the mechanism in the present invention for archiving source code files is provided.
  • the documentation files can be archived using standard source-code-control systems.
  • documentation can be stored, tagged and retrieved for customer delivery along with the source-code files. In this way, the invention is extensible and capable of managing many forms of source-code and documentation files across multiple platforms.
  • Systems and methods consistent with the present invention provide a platform independent project build and management tool, comprising a database and a control program that may be implemented as a portable script to facilitate platform independence.
  • the control program performs the jobs of building the code tree and controlling a source code control system.
  • this tool set is completely transportable between operating systems, such as, for example, Windows, UNIX and Linux.
  • the script and database mechanisms provide the user an ability to define subsets of directories and files that comprise a particular project build for a given platform.
  • the overall directory structure can contain a vast number of projects and platforms, each configured and built differently.
  • At least one external-action-engine control source is generated based on a configuration file, a directory list, and a file list.
  • An external action engine is executed to manipulate files corresponding to a software package in a directory tree defined by the directory list, using the external action engine control source.
  • a separate set of files is used for each project and platform combination of a plurality of project and platform combinations, and any file in the file list maybe shared between different project and platform combinations.
  • a software package suitable for customer delivery maybe built across a plurality of project and platform combinations.
  • a software package identifier is received.
  • Software build information is accessed from at least one data source, which is comprised of at least one configuration source and at least one database source including a directory list and a file list.
  • a software-build-tool control source is generated based on a software package identifier.
  • At least one software build tool is executed based on the software-build-tool control source to build the software package in a directory tree defined by a directory list.
  • the methods use a separate set of said files for each project and platform combination. Any file in the file list maybe shared between different project and platform combinations.
  • a cross-platform data-processing system for managing software packages across a plurality of project and platform combinations.
  • the system includes computer-readable instructions for generating at least one external-action-engine control source based on a configuration file, a directory list, and a file list.
  • the system also includes computer-readable instructions for executing an external action engine using the external-action-engine control source to manipulate files corresponding to a software package in a directory tree defined by the directory list.
  • the system uses a separate set of files for each project and platform combination, and the system allows the sharing of any file in the file list between different project and platform combinations. Additional benefits of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The benefits of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims.
  • Figure l is a block diagram of a computer system in which the present invention may be practiced.
  • Figure lA is a block diagram of an environment in which the present invention maybe practiced
  • Figure lB is a block diagram illustrating an example of the functional blocks illustrated in Figure lA, consistent with the present invention
  • Figure 2 is a flow diagram illustrating a method for implementing a command-parsing action engine, consistent with the present invention
  • Figure 3 is a flow diagram illustrating a method for implementing an internal action engine, consistent with the present invention
  • Figure 3A is a flow diagram illustrating a method for generating platform independent documentation, consistent with the present invention
  • Figure 4 is a block diagram illustrating a sample directory structure, consistent with the present invention.
  • Figure 5 is a table illustrating sample configuration and database files, consistent with the present invention
  • Figure 6 is a table showing a list of files used in an embodiment, consistent with the present invention.
  • An embodiment consistent with the present invention includes an "action engine” and database information.
  • An action engine is a computer-executable process for accepting input and generating output information based on the input and an internal state of the action engine.
  • the internal state is defined by predetermined variables including variables specified in the configuration of the action engine.
  • the action engine performs operations on a set of source-code files and documentation as identified by the action engine's current configuration and input database information.
  • the database information comprises objects depending on user definable configuration.
  • Action engine operations comprise (i) translating the output database object list into a form understandable by an external action engine such as "make" or CVS; and (ii) providing the resulting output to an external action engine that performs further actions on the objects, thereby carrying out the requested user action.
  • CVS is a freely available version control system well known to those of ordinary skill in the art.
  • source- code files may have various versions, such as, for example 1.1 or 1.1.5.
  • a project may contain many source-code files, and the source code files associated with various projects may have many versions. Therefore, it is sometimes desirable to identify a set of source-code files having particular versions. Identifying a set of files having specific versions is sometimes referred to as "stamping" the set of files.
  • FIG. 1 is a block diagram of a computer system in which the present invention may be practiced.
  • Central processing unit (“CPU") 102 is a computer processor capable of executing computer-readable instructions to perform certain actions.
  • CPU 102 receives input 104 and produces output 106.
  • Input 104 maybe of the form of commands received from a user, configuration information regarding desired state information of the computer system, or database information specifying parameters to be used in the construction of output 106.
  • Output 106 maybe a control file used to control the operation of another process.
  • Output 106 may also be software executable code capable of being executed by a computer processor.
  • CPU 102 operates in connection with instructions stored in a memory 114.
  • the instructions stored in memory 114 include a command processor 108 for processing user commands reflecting a desired action to be performed.
  • Database selector 110 is also stored in memory 114, and database selector includes instructions for selecting database information, such as, for example, lists of files, to be used in performing the desired action.
  • Translator 112 is used to translate commands and database information into an action-engine control source capable of causing an action engine to perform a predetermined action.
  • Figure lA is a block diagram of an environment in which the present invention may be practiced.
  • the present invention is capable of accepting user commands 116.
  • User commands 116 are transmitted to a command parser, within internal action engine 120.
  • the commands are parsed by command parser 125.
  • Command parser 125 breaks down the user commands into component parts and interprets the meaning of the component parts to determine the requested action communicated by user commands 116.
  • appropriate database components are selected by database selector or filter 130.
  • filter 130 Based on the user commands, filter 130 performs a database selection of the database components corresponding to project and platform specific databases such as databases 140.
  • a database selection maybe based on the particular project and platform as further described in connection with Figure 6.
  • a command translator and formatter translates and formats commands suitable to be presented to external action engines.
  • Command translator and formatter 150 receives input from selected databases 140 and generates output information in a suitable format to be transmitted to external action engines 160. Finally, external action engines 160 are caused to perform actions that satisfy commands requested in user command 116.
  • Figure lB is a block diagram illustrating an example of functional blocks illustrated in Figure lA, consistent with the present invention.
  • a system accepts a command from a user, where the command is of the form "bmake" and where the command optionally includes command line parameters.
  • bmake and optional parameters are shown in block 172. Receipt of the bmake command and optional parameters 172 results in the execution of shell script code 174, which further invokes a configuration parser 176.
  • Configuration parser 176 reads in configuration files and appropriately sets state variables within action engine 171 based on contents of the configuration files.
  • project and platform specific database text files 178 are read to obtain appropriate project and platform specific information, such as, for example, the directory structure in which the project and platform specific build will occur.
  • the database is centralized and encoded with fields such that a single database is used to define the directory structure and file lists.
  • ASCII files may be used. ASCII files are convenient to read and understand and, therefore, ASCII files maybe conveniently maintained by software developers using systems consistent with the present invention.
  • Database information is then used by command translator and formatter 180 to generate output files appropriate for external action engines, such as, for example, make and CVS as indicated in block 182. Finally, based on the generated output files the system invokes at least one external action engine to build appropriate software packages based on the source-code files and configuration information as generated by action engine 171.
  • a bmake script is implemented as a Bourne shell script and a database is implemented as a series of ASCII files. The shell script reads a configuration file and retrieves a list of file names from the database.
  • bmake translates this file list into an appropriate form, such as a SOURCE macro, as known in the art, for providing a list of files, such as source-code files to the make tool or a list of files and versions to be obtained using CVS. Bmake then generates appropriate control files and provides them to appropriate external action engines, such as, for example, make and CVS, to perform the desired user action.
  • a SOURCE macro as known in the art
  • FIG. 2 is a flow diagram illustrating a method for implementing a command-parsing action engine.
  • An action engine consistent with the present invention first accepts user commands (step 210). These commands include commands as shown in table 2A, below. Next, the action engine selects database objects based on input user commands (step 220). Next, the command-parsing action engine generates external action engine control files based on user commands and information contained in the database objects (step 230). Finally, the command-parsing action engine causes the external action engines to be executed with the generated action engine control files (step 240).
  • FIG. 3 is a flow diagram illustrating a method for implementing an internal action engine, consistent with the present invention.
  • the action engine is invoked without parameters, and it first reads its associated config ration information (step 310). Next, the action engine generates a database object list based on information obtained from the configuration information (step 320).
  • FIG. 3A is a flow diagram illustrating a method for generating platform independent documentation, consistent with the present invention.
  • a software developer prepares engineering documentation using the Microsoft Word® documentation preparation system (step 350).
  • the software developer saves the document in the rich text ("RTF") format in an appropriate directory (step 360). Once the documentation is stored in the appropriate directory, it can be maintained using platform independent management systems consistent with the present invention.
  • the documentation files maybe converted from RTF format to portable-document (“PDF") format using known tools (step 370).
  • PDF files Once the PDF files have been generated, they may be published in conveniently located web-page locations so that the engineering documentation may be viewed on any platform that supports a web browser and an Adobe Acrobat® PDF reader.
  • Figure 4 is a block diagram illustrating a sample directory structure, consistent with the present invention.
  • /projroot is the root directory of the directory structure in an illustrative embodiment.
  • the root directory contains two subdirectories separately depicted in Figure 4 as blocks 410 and 420.
  • Block 410 shows the documentation, tools, and experimental subdirectories, respectively.
  • subdirectory "/doc” the structure contains documentation including project-wide documentation, regarding architectural specifications and other documentation, such as, for example, project plans.
  • project specific directories such as, for example "/aaaa” and “/bbbbb," corresponding to projects named “aaaa” and "bbbbb” respectively.
  • Block 420 represents one embodiment, in which the "/src" subdirectory is the storage location for source-code files related to a particular project and platform.
  • the /opnet subdirectory contains a /tools subdirectory, that may in turn contain other subdirectories, such as the /traffic_gen subdirectory corresponding to particular tools related to opnet, which is a set of software tools associated with a Solaris® development environment.
  • the /opnet subdirectory also contains the /main, /public, and /drivers subdirectories.
  • the /main subdirectory contains operating specific scripts and executables to enable building the project and platform specific build.
  • the /main there may be project specific subdirectories, such as /aaaa and /bbbb.
  • the /pubinc subdirectory is for the storage of public header files used by files stored within the /opnet subdirectory.
  • the /drivers subdirectory contains source-code for device drivers within a project and platform specific build, and the drivers subdirectory may contain a /common subdirectory containing device driver source code that is common to multiple projects, and the /drivers subdirectory may also contain project specific directories containing device- driver source code in subdirectories such as /aaaa or /bbbb.
  • /opnet subdirectory there are other host-platform- specific subdirectories under the /src subdirectory. These subdirectories maybe named /solaris, /linux, /FreeBSD, or /windows98, etc. and these subdirectories have a similar internal structure to the /opnet directory. There may also be a directory with a user specific naming convention such as, for example, /xyzcode, wherein the subdirectory contains a /public subdirectory containing public headers used throughout the user's environment and an /apps subdirectory containing shared source-code files that comprise a base-line configuration for a particular application.
  • /lib subdirectory under the /xyzcode directory, and the /lib directory may contain commonly used library routines, such as, for example, linked list, configuration, and error log processing software modules.
  • library routines such as, for example, linked list, configuration, and error log processing software modules.
  • Figure 5 is a table illustrating example configuration and database files, consistent with the present invention.
  • a configuration file is placed in the /build subdirectory.
  • the configuration file contains information about project and platform identifications.
  • configuration file 510 has file name bmake.config 502 and contains project and platform variables of "xyz" and "linux" respectively.
  • Configuration file 510 also contains an output directory specification of /home/jshapiro/xyzwork/out.
  • Database file 520 contains a list of directories in which there are additional databases containing a list of files.
  • the directories in the list of directories contained in the database file, also contain the source-code files contained in a file list, such as file-list name bmake.xyz.linux.filelist 522.
  • the listed files contained in file list 530 are the source-code files necessary to produce the software build.
  • Figure 6 is a table showing a list of files and file specifications that may be used in an embodiment, consistent with the present invention.
  • Element 602 is an exemplary representation of an action engine consistent with the present invention.
  • the action engine script is named "bmake.”
  • Element 604 is the current configuration file, and for convenience, it maybe named “bmake.config.”
  • Alog file maybe used in an embodiment, and as indicated in element 606, it maybe named “bmake.project.platform.log, " where project and platform represent an arbitrary project and platform.
  • the logfile, represented by element 606, contains a listing of all actions performed by the bmake script.
  • a project name maybe, for example, "aaaa,” “bbbb,” “projecti,” or “i23router.”
  • a platform name maybe "i386,” or "linux,” or "mc68ooo.”
  • Elements 610 and 612 represent file names of files containing directory lists such as the directory list 520 as shown in Figure 5.
  • Elements 616, 618, and 620 correspond to files containing file lists such as file list 530 as described in connection with Figure 5.
  • Element 622 is a Makefile containing platform-specific information, such as, for example platform specific preprocessor directives.
  • Elements 624, 626, 628, and 630 contain definitions used to define variables, such as, for example environment variables or preprocessor macros.
  • Element 624 contains definitions for all source code, whereas elements 626, 628, and 630 contain platform-specific definitions.
  • script and database mechanisms provide a user the ability to define subsets of directories and files that comprise a particular project build for a given platform.
  • the overall directory structure may contain a number of projects and platforms that is limited only by capabilities of the file system on which corresponding files are stored.
  • each project and platform combination is configured and built separately using a distributed database.
  • the internal action engine script, or the bmake script comprises a mechanism to use project and platform specific Makefiles, as well as to obtain and use source-code files with project and platform names suitable for conditional compilation.
  • a complete software package built fo a particular customer is called a "customer build. "
  • a particular project and platform view of the entire directory can be extracted using a particular stamp, and this view can be tagged, thus providing the user with the ability to produce reliable customer builds.
  • the bmake script provides mechanisms to (i) build an entire project or platform directory tree; (ii) build a single project or platform directory; (iii) stamp all files in a project or platform directory; (iv) retrieve an entire directory tree using a predefined stamp; (iv) create a copy of the directory tree for a delivery (v) invoke the make command on all directories in a project, or on a single directory; or (vi) convert a directory tree from one tagged project or platform build to another.
  • the action engine generates file and directory lists in the same manner as it generates project and platform configuration. This embodiment provides enhanced reliability with respect to directory and file maintenance.
  • the bmake script is implemented as an executable file without otherwise impacting structural or functional aspects of the present invention. In this embodiment, multiple bmake executables are required for each platform.
  • configuration information is provided in environment variables.
  • configuration information is provided by passing parameters into the script on the command line when the script is invoked.
  • schematics and gate array databases are managed in the project build and management tool either in addition to source-code files or in the alternative to source-code files.

Abstract

An extensible mechanism is disclosed (Fig. 1B), whereby a software developer may update a database (171) to add source-code files and directories to particular projects (178). The use of free software foundation tools provides a developer with a uniform built environment, thus allowing portability between different platforms such as Windows TM, UNIX, and Linux. Similarly, a mechanism is disclosed for archiving documentation files. By storing files in rich text format, the documentation files can be archived using standard source-code-control systems (184).

Description

PLATFORM INDEPENDENT PROJECT BUILD AND MANAGEMENT
TOOL
Technical Field
The present mvention relates to computer software project build and management tools and, in particular, to platform-independent and configurable project build and management tools.
Background Computer source code is the human-readable format of instructions to a computer, and source code is generally written using symbols and expressions that comprise a particular programming language. Common programming languages include C, C++, and Java™. Computer software is the intangible set of computer readable information and instructions that cause a computer to operate in a desired way, and a complete unit of computer software is sometimes called a computer software package. A computer software module is a component of a computer software package.
Object code format is an intermediate format between source code and a linked executable. The linking process combines multiple object code format modules into one or more executable modules with appropriately configured interrelationships among the constituent object code modules. Computer software modules are commonly built or compiled from source-code files into an object code format and then linked into an executable format that can be run on a particular type of a target computer system. The computer system on which the executable software is built is called the "host platform," because it "hosts" the construction process. Similarly, the computer system on which the software will eventually execute is referred to as the "target platform."
Computer systems are sometimes called platforms, because of the analogy to a foundation on which the computer software is built to create a functional application. Frequently, source-code is written with conditional parameters so that the source code can be built to run on a number of platforms. The set of source code that is sufficient to be built into a software package providing a predefined set of functionality is sometimes called a project. Project build and management tools are typically used to automate the task of examining and compiling projects that may comprise many source-code files. Atypical commercial software product maybe made up of source code comprising hundreds or thousands of source code files, and each source code file may have multiple versions corresponding to multiple platforms and projects. Project build and management tools may automatically obtain the appropriate source code files corresponding to a particular project, set the appropriate platform parameters corresponding to the desired platform, and then build the project. For example, a tool called "make," which is generally known to those skilled in the art, is capable of inspecting source-code files to determine whether a corresponding object code or executable file needs to be built or rebuilt based on whether the corresponding source-code file has been modified. The configuration-input information to the "make" program is generally referred to as a Makefile. Within a Makefile, information such as project version and platform parameters may be specified. When building a project containing thousands of source-code files it is most efficient to compile only the files that have been updated. In fact, for many projects, rebuilding all files may be prohibitively time consuming, meaning software development could not proceed in an economically feasible manner if all source-code files needed to be recompiled any time a change is made. Therefore, tools such as "make" are essential to effective software development.
However, when there are multiple projects with multiple versions for multiple platforms, tools such as "make" are insufficient to enable the building and management of projects. Therefore, in order to build complex projects, frequently software developers write individual, custom scripts or programs to invoke standard source-code-build programs such as "make" in various ways, on multiple Makefiles, in multiple source-code directories. These custom scripts are generally written on an as needed basis. As those skilled in the art appreciate, these ad hoc custom scripts are not usually reliable, extensible or reusable.
"Autoconf is a freely available tool for the host and target platform specific building of software. According to its authors, "Autoconf is a tool for producing shell scripts that automatically configure software source-code packages to adapt to many kinds of UNIX® compatible systems." David MacKenzie and Ben Elliston, Autoconf, Creating Automatic Configuration Scripts, Edition 2.13, for Autoconf version 2.13, December 1998, available at www.gnu.org/manual/autoconf/html_mono/autoconf.html. Autoconf has several deficiencies, however .First, Autoconf would allow source code developed for one client to be delivered to another. Autoconf manages a single set of source files and creates different object files by using macros inside the source. Specific software features are then enabled or disabled using preprocessor directives in a header file. Autoconf does not manage separate sets of source files for each project and platform on a single shared directory tree while also allowing any file to be shared among any set of projects or platform builds.
Second, Autoconf does not inherently interact with a version control system such as the Revision Control System ("RCS") or The Concurrent Versions System ("CVS"). Therefore, Autoconf itself does not provide for a platform- independent build environment that can be easily configured and modified through the use of project specific database files. In fact, no known system satisfies these needs.
Finally, Autoconf imposes certain restrictions on a software developer. In particular, Autoconf imposes restrictions on certain conditional preprocessor directives. And Autoconf does not support having, in the same directory tree both directories that are parts of a larger package and directories that are independent packages. Autoconf also requires versions of the "make" tool that support the VPATH variable, which specifies a directory search list that "make" searches when determining which files to rebuild, in order to build a new software package.
Additionally, many UNIX programmers use the "make" tool in an environment having the standard UNIX tools like sed, awk, and grep. On the other hand, many Windows® programmers use the Microsoft® specific "make" tool or a graphical user interface to manage their projects. Therefore code developed on one host platform is not easily, if at all, capable of being built when moved from one host build platform to another for example, from Windows to UNIX or Linux. Prior to the present invention, developers were forced to use very different tools in these environments.
Scripting languages such as the Bourne shell are useful for implementing processes on multiple platforms. For example, the Bourne shell can be used as a high-level programming language on any system that supports the Bourne shell command interpreter. The Bourne shell is available on essentially all UNIX-like systems and on other systems, such as, for example, Windows, using the Cygwin tools available from Red Hat, Inc. of Research Triangle Park, North Carolina.
Additionally, there is a need for a rich software documentation environment that can interoperate between host platforms. Known systems of documentation construction include TeX, LaTeX, SGML, and HTML. None of these systems include the rich interactive environment as provided by the Microsoft Office™ suite of office automation tools. As a result, many documentation authors prefer to use a Microsoft Office application to create software documentation and do not want to use tools such as TeX to produce their documentation. As a result, a computer using the Microsoft Windows operating system must be used to produce the documentation. But in order to meet requirements of cross-platform interoperability, the final output of the documentation authoring system must have the ability to retain the rich documentation characteristics and still be interoperable for document viewing, on different computer systems. Known systems are not able to satisfy this need.
Known systems cannot utilize project and platform specific database information to store information used by programs which are normally statically configured using various scripts. For example, in known systems, Makefiles are configured statically with a SOURCE statement that defines what the Makefile will build when the "make" tool is invoked. Alternate targets inside the Makefile are commonly used to allow a single Makefile to define different sets of objects to build, and separate Makefiles are typically used to create separate projects. Known systems do not allow a single database to be updated in order to add a new file to the list of objects to be built by make and to be checked in and out of a version control system.
By defining a platform-independent build environment, management, and documentation system, the present invention meets the above needs that are lacking in the art as well as creating additional advantages that maybe learned by practicing the invention.
SUMMARY
Systems and methods consistent with the present invention provide an extensible mechanism whereby a software developer may update a database to add source-code files and directories to particular projects. Furthermore, the use of free software foundation tools provides a developer with a uniform "make" environment, thus allowing the use of the invention on different platforms such as Windows as well as UNIX and Linux. A method for archiving documentation files in a manner similar to the mechanism in the present invention for archiving source code files is provided. By storing files in rich text format, the documentation files can be archived using standard source-code-control systems. By integrating rich-text-format documentation files into the directory and file lists, within the database, documentation can be stored, tagged and retrieved for customer delivery along with the source-code files. In this way, the invention is extensible and capable of managing many forms of source-code and documentation files across multiple platforms.
Systems and methods consistent with the present invention provide a platform independent project build and management tool, comprising a database and a control program that may be implemented as a portable script to facilitate platform independence. The control program performs the jobs of building the code tree and controlling a source code control system. By invoking portable tools in the control program, this tool set is completely transportable between operating systems, such as, for example, Windows, UNIX and Linux. The script and database mechanisms provide the user an ability to define subsets of directories and files that comprise a particular project build for a given platform. The overall directory structure can contain a vast number of projects and platforms, each configured and built differently.
Consistent with the present invention, at least one external-action-engine control source is generated based on a configuration file, a directory list, and a file list. An external action engine is executed to manipulate files corresponding to a software package in a directory tree defined by the directory list, using the external action engine control source. A separate set of files is used for each project and platform combination of a plurality of project and platform combinations, and any file in the file list maybe shared between different project and platform combinations.
In methods consistent with the present invention, a software package suitable for customer delivery maybe built across a plurality of project and platform combinations. A software package identifier is received. Software build information is accessed from at least one data source, which is comprised of at least one configuration source and at least one database source including a directory list and a file list. A software-build-tool control source is generated based on a software package identifier. At least one software build tool is executed based on the software-build-tool control source to build the software package in a directory tree defined by a directory list. The methods use a separate set of said files for each project and platform combination. Any file in the file list maybe shared between different project and platform combinations.
According to the present invention, a cross-platform data-processing system for managing software packages across a plurality of project and platform combinations is provided. The system includes computer-readable instructions for generating at least one external-action-engine control source based on a configuration file, a directory list, and a file list. The system also includes computer-readable instructions for executing an external action engine using the external-action-engine control source to manipulate files corresponding to a software package in a directory tree defined by the directory list. The system uses a separate set of files for each project and platform combination, and the system allows the sharing of any file in the file list between different project and platform combinations. Additional benefits of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The benefits of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.
BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate exemplary embodiments of the invention and together with the description, serve to explain the principles of the invention. In the drawings,
Figure l is a block diagram of a computer system in which the present invention may be practiced;
Figure lA is a block diagram of an environment in which the present invention maybe practiced;
Figure lB is a block diagram illustrating an example of the functional blocks illustrated in Figure lA, consistent with the present invention; Figure 2 is a flow diagram illustrating a method for implementing a command-parsing action engine, consistent with the present invention;
Figure 3 is a flow diagram illustrating a method for implementing an internal action engine, consistent with the present invention;
Figure 3A is a flow diagram illustrating a method for generating platform independent documentation, consistent with the present invention;
Figure 4 is a block diagram illustrating a sample directory structure, consistent with the present invention;
Figure 5 is a table illustrating sample configuration and database files, consistent with the present invention; Figure 6 is a table showing a list of files used in an embodiment, consistent with the present invention.
DETAILED DESCRIPTION
Reference will now be made in detail to exemplary embodiments of the invention, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts.
An embodiment consistent with the present invention includes an "action engine" and database information. An action engine is a computer-executable process for accepting input and generating output information based on the input and an internal state of the action engine. The internal state is defined by predetermined variables including variables specified in the configuration of the action engine. The action engine performs operations on a set of source-code files and documentation as identified by the action engine's current configuration and input database information. The database information comprises objects depending on user definable configuration. Action engine operations comprise (i) translating the output database object list into a form understandable by an external action engine such as "make" or CVS; and (ii) providing the resulting output to an external action engine that performs further actions on the objects, thereby carrying out the requested user action.
CVS is a freely available version control system well known to those of ordinary skill in the art. Within a version control system such as CVS, source- code files may have various versions, such as, for example 1.1 or 1.1.5. A project may contain many source-code files, and the source code files associated with various projects may have many versions. Therefore, it is sometimes desirable to identify a set of source-code files having particular versions. Identifying a set of files having specific versions is sometimes referred to as "stamping" the set of files.
Figure 1 is a block diagram of a computer system in which the present invention may be practiced. Central processing unit ("CPU") 102 is a computer processor capable of executing computer-readable instructions to perform certain actions. CPU 102 receives input 104 and produces output 106. Input 104 maybe of the form of commands received from a user, configuration information regarding desired state information of the computer system, or database information specifying parameters to be used in the construction of output 106. Output 106 maybe a control file used to control the operation of another process. Output 106 may also be software executable code capable of being executed by a computer processor.
CPU 102 operates in connection with instructions stored in a memory 114. The instructions stored in memory 114 include a command processor 108 for processing user commands reflecting a desired action to be performed. Database selector 110 is also stored in memory 114, and database selector includes instructions for selecting database information, such as, for example, lists of files, to be used in performing the desired action. Translator 112 is used to translate commands and database information into an action-engine control source capable of causing an action engine to perform a predetermined action.
Figure lA is a block diagram of an environment in which the present invention may be practiced. The present invention is capable of accepting user commands 116. User commands 116 are transmitted to a command parser, within internal action engine 120. The commands are parsed by command parser 125. Command parser 125 breaks down the user commands into component parts and interprets the meaning of the component parts to determine the requested action communicated by user commands 116. Based on the meaning of the parsed commands, appropriate database components are selected by database selector or filter 130. Based on the user commands, filter 130 performs a database selection of the database components corresponding to project and platform specific databases such as databases 140. A database selection maybe based on the particular project and platform as further described in connection with Figure 6. Based on information contained in database components selected from databases 140, a command translator and formatter translates and formats commands suitable to be presented to external action engines.
Command translator and formatter 150 receives input from selected databases 140 and generates output information in a suitable format to be transmitted to external action engines 160. Finally, external action engines 160 are caused to perform actions that satisfy commands requested in user command 116.
Figure lB is a block diagram illustrating an example of functional blocks illustrated in Figure lA, consistent with the present invention. In this embodiment, a system accepts a command from a user, where the command is of the form "bmake" and where the command optionally includes command line parameters. In Figure lB, bmake and optional parameters are shown in block 172. Receipt of the bmake command and optional parameters 172 results in the execution of shell script code 174, which further invokes a configuration parser 176. Configuration parser 176 reads in configuration files and appropriately sets state variables within action engine 171 based on contents of the configuration files. Next, based on the state of action engine 171, which is established based on bmake command and optional parameters 172 and the configuration obtained by configuration parser 176, project and platform specific database text files 178 are read to obtain appropriate project and platform specific information, such as, for example, the directory structure in which the project and platform specific build will occur. In an alternative embodiment, the database is centralized and encoded with fields such that a single database is used to define the directory structure and file lists. In one embodiment, ASCII files may be used. ASCII files are convenient to read and understand and, therefore, ASCII files maybe conveniently maintained by software developers using systems consistent with the present invention.
Database information is then used by command translator and formatter 180 to generate output files appropriate for external action engines, such as, for example, make and CVS as indicated in block 182. Finally, based on the generated output files the system invokes at least one external action engine to build appropriate software packages based on the source-code files and configuration information as generated by action engine 171. In one embodiment, a bmake script is implemented as a Bourne shell script and a database is implemented as a series of ASCII files. The shell script reads a configuration file and retrieves a list of file names from the database. Then, depending on the action being performed, bmake translates this file list into an appropriate form, such as a SOURCE macro, as known in the art, for providing a list of files, such as source-code files to the make tool or a list of files and versions to be obtained using CVS. Bmake then generates appropriate control files and provides them to appropriate external action engines, such as, for example, make and CVS, to perform the desired user action.
Figure 2 is a flow diagram illustrating a method for implementing a command-parsing action engine. An action engine consistent with the present invention first accepts user commands (step 210). These commands include commands as shown in table 2A, below. Next, the action engine selects database objects based on input user commands (step 220). Next, the command-parsing action engine generates external action engine control files based on user commands and information contained in the database objects (step 230). Finally, the command-parsing action engine causes the external action engines to be executed with the generated action engine control files (step 240).
Figure imgf000014_0001
Table 2A In table 2A, when executing the "bmake dir" and "bmake dirtree" commands, files are obtained using CVS, with the optional tag as specified in the "bmake.config" file, if the tag parameter is present in the file. If a directory already exists it is not overwritten or changed and a warning is displayed. Figure 3 is a flow diagram illustrating a method for implementing an internal action engine, consistent with the present invention. The action engine is invoked without parameters, and it first reads its associated config ration information (step 310). Next, the action engine generates a database object list based on information obtained from the configuration information (step 320). Next, the action engine translates the information referenced in the database object list into a form that is appropriate for being sent to external action engines (step 330). Finally, the action engine provides the translated information, in the form of an external action engine control file, to at least one external action engine (step 340), and executes the external action engine. Figure 3A is a flow diagram illustrating a method for generating platform independent documentation, consistent with the present invention. First, a software developer prepares engineering documentation using the Microsoft Word® documentation preparation system (step 350). Next, the software developer saves the document in the rich text ("RTF") format in an appropriate directory (step 360). Once the documentation is stored in the appropriate directory, it can be maintained using platform independent management systems consistent with the present invention. Once the documentation is stored in an appropriate directory structure, the documentation files maybe converted from RTF format to portable-document ("PDF") format using known tools (step 370). Finally, once the PDF files have been generated, they may be published in conveniently located web-page locations so that the engineering documentation may be viewed on any platform that supports a web browser and an Adobe Acrobat® PDF reader.
Figure 4 is a block diagram illustrating a sample directory structure, consistent with the present invention. As indicated in Figure 4, /projroot, is the root directory of the directory structure in an illustrative embodiment. The root directory contains two subdirectories separately depicted in Figure 4 as blocks 410 and 420. Block 410 shows the documentation, tools, and experimental subdirectories, respectively. First, in subdirectory "/doc," the structure contains documentation including project-wide documentation, regarding architectural specifications and other documentation, such as, for example, project plans. Below the "/doc" subdirectory are located project specific directories, such as, for example "/aaaa" and "/bbbb," corresponding to projects named "aaaa" and "bbbb" respectively. Within the product specific subdirectories, there maybe other subdirectories as represented by the /??? subdirectory below the /aaaa subdirectory. Within the /tools subdirectory, are tools for building, configuring, and testing source code. These directories are named /build, /config, and /test, respectively. Within the /test subdirectory, there are target platform specific test tools, such as /opnet and /linux. The /exper subdirectory contains experimental work, and may contain subdirectories for each software developer using a naming convention, such as, for example, the initials of developers' first and last names. Block 420 represents one embodiment, in which the "/src" subdirectory is the storage location for source-code files related to a particular project and platform. In this embodiment, below the /src subdirectory are the /opnet, /linux, and /xyzcode subdirectories. The /opnet subdirectory contains a /tools subdirectory, that may in turn contain other subdirectories, such as the /traffic_gen subdirectory corresponding to particular tools related to opnet, which is a set of software tools associated with a Solaris® development environment. The /opnet subdirectory also contains the /main, /public, and /drivers subdirectories. The /main subdirectory contains operating specific scripts and executables to enable building the project and platform specific build. Within /main, there may be project specific subdirectories, such as /aaaa and /bbbb. The /pubinc subdirectory is for the storage of public header files used by files stored within the /opnet subdirectory. The /drivers subdirectory contains source-code for device drivers within a project and platform specific build, and the drivers subdirectory may contain a /common subdirectory containing device driver source code that is common to multiple projects, and the /drivers subdirectory may also contain project specific directories containing device- driver source code in subdirectories such as /aaaa or /bbbb. In addition to the /opnet subdirectory, there are other host-platform- specific subdirectories under the /src subdirectory. These subdirectories maybe named /solaris, /linux, /FreeBSD, or /windows98, etc. and these subdirectories have a similar internal structure to the /opnet directory. There may also be a directory with a user specific naming convention such as, for example, /xyzcode, wherein the subdirectory contains a /public subdirectory containing public headers used throughout the user's environment and an /apps subdirectory containing shared source-code files that comprise a base-line configuration for a particular application. Finally, there maybe a /lib subdirectory under the /xyzcode directory, and the /lib directory may contain commonly used library routines, such as, for example, linked list, configuration, and error log processing software modules. Of course the above choice of directory structure and directory names is merely illustrative, and persons of ordinary skill in the art will appreciate that substitutes maybe employed without departing from the scope of the present invention.
Figure 5 is a table illustrating example configuration and database files, consistent with the present invention. In one embodiment, a configuration file is placed in the /build subdirectory. The configuration file contains information about project and platform identifications. For example, in Figure 5, configuration file 510 has file name bmake.config 502 and contains project and platform variables of "xyz" and "linux" respectively. Configuration file 510 also contains an output directory specification of /home/jshapiro/xyzwork/out. In the embodiment, there is also a database file 520 having file name bmake.xyz.linux.dirlist 512. Database file 520 contains a list of directories in which there are additional databases containing a list of files. The directories, in the list of directories contained in the database file, also contain the source-code files contained in a file list, such as file-list name bmake.xyz.linux.filelist 522. The listed files contained in file list 530 are the source-code files necessary to produce the software build. Figure 6 is a table showing a list of files and file specifications that may be used in an embodiment, consistent with the present invention. Element 602 is an exemplary representation of an action engine consistent with the present invention. As indicated in Figure 6, in one embodiment, the action engine script is named "bmake." Element 604 is the current configuration file, and for convenience, it maybe named "bmake.config." Alog file maybe used in an embodiment, and as indicated in element 606, it maybe named "bmake.project.platform.log, " where project and platform represent an arbitrary project and platform. In one embodiment, the logfile, represented by element 606, contains a listing of all actions performed by the bmake script. A project name maybe, for example, "aaaa," "bbbb," "projecti," or "i23router." A platform name maybe "i386," or "linux," or "mc68ooo." Elements 610 and 612 represent file names of files containing directory lists such as the directory list 520 as shown in Figure 5. Elements 616, 618, and 620 correspond to files containing file lists such as file list 530 as described in connection with Figure 5. Element 622 is a Makefile containing platform-specific information, such as, for example platform specific preprocessor directives. Elements 624, 626, 628, and 630 contain definitions used to define variables, such as, for example environment variables or preprocessor macros. Element 624 contains definitions for all source code, whereas elements 626, 628, and 630 contain platform-specific definitions.
In an illustrative embodiment, script and database mechanisms provide a user the ability to define subsets of directories and files that comprise a particular project build for a given platform. The overall directory structure may contain a number of projects and platforms that is limited only by capabilities of the file system on which corresponding files are stored. Within the directory structure, each project and platform combination is configured and built separately using a distributed database. The internal action engine script, or the bmake script comprises a mechanism to use project and platform specific Makefiles, as well as to obtain and use source-code files with project and platform names suitable for conditional compilation.
A complete software package built fo a particular customer is called a "customer build. " A particular project and platform view of the entire directory can be extracted using a particular stamp, and this view can be tagged, thus providing the user with the ability to produce reliable customer builds. Thus, the bmake script provides mechanisms to (i) build an entire project or platform directory tree; (ii) build a single project or platform directory; (iii) stamp all files in a project or platform directory; (iv) retrieve an entire directory tree using a predefined stamp; (iv) create a copy of the directory tree for a delivery (v) invoke the make command on all directories in a project, or on a single directory; or (vi) convert a directory tree from one tagged project or platform build to another.
In another embodiment, the action engine generates file and directory lists in the same manner as it generates project and platform configuration. This embodiment provides enhanced reliability with respect to directory and file maintenance. In an alternative embodiment, the bmake script is implemented as an executable file without otherwise impacting structural or functional aspects of the present invention. In this embodiment, multiple bmake executables are required for each platform.
In another embodiment, configuration information is provided in environment variables. In yet another embodiment, configuration information is provided by passing parameters into the script on the command line when the script is invoked. In another embodiment, schematics and gate array databases, are managed in the project build and management tool either in addition to source-code files or in the alternative to source-code files. Other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the invention being indicated by the following claims.

Claims

- l8 -WHAT IS CLAIMED IS:
1. Platform-independent method for managing software packages across a plurality of project and platform combinations, said packages including a configuration file, a directory list, and a file list, said directory list defining a directory tree containing a software package, and said file list containing a plurality of files, said method comprising: generating at least one external-action-engine control source based on said configuration file, said directory list, and said file list; and executing an external action engine using said external-action-engine control source to manipulate said files corresponding to said software package in said directory tree defined by said directory list, in a manner to
(1) use a separate set of said files for each one of said plurality of project and platform combinations, and (2) share any file in said file list between different said project and platform combinations.
2. A method according to claim 1, wherein generating at least one external action engine control source further comprises: receiving input reflecting information about an action to be performed.
3. A method according to claim 1, wherein said external action engine is a make program.
4. A method according to claim 1, wherein said external action engine is a concurrent versions system program.
5. A method according to claim 4, wherein executing an external action engine using said external-action-engine control source further comprises: executing said concurrent versions system program to retrieve files corresponding to a predetermined project and platform combination.
6. A method according to claim 4, wherein executing an external action engine using said external-action-engine control source further comprises: executing said concurrent versions system program to check-in files corresponding to a predetermined project and platform combination.
7. A method according to claim 4, wherein executing an external action engine using said external-action-engine control source further comprises: executing said concurrent versions system program to tag a set of files corresponding to a predetermined project and platform combination.
8. A method according to claim 1, wherein said file list is obtained from a database source comprising at least one ASCII file located in at least one directory identified in said directory list.
9. A method according to claim 1, wherein the step of generating at least one external action engine control file is performed by a platform independent action engine.
10. A method according to claim 9, wherein said platform independent action engine is a Bourne shell script.
11. A method according to claim 1, wherein said file list comprises at least one source-code file.
12. A method according to claim 1, wherein said file list comprises at least one engineering documentation file.
13. A method according to claim 12, wherein said engineering documentation file further comprises a documentation file in rich text format.
14. A method according to claim 1, wherein said external action engine control source further comprises a Makefile.
15. A method for building a software package suitable for customer delivery, across a plurality of project and platform combinations, said software package being identified by a software package identifier comprising a combination of a project identifier and a platform identifier, said software package capable of being built using software build information including at least one directory list, at least one file list, and at least one software-build-tool control source, said file list containing a plurality of files and said directory list defining a directory tree, and said method comprising: receiving said software package identifier including said project identifier and said platform identifier; accessing said software build information from at least one data source comprising: at least one configuration source; and at least one database source including said directory list and said file list; generating said software-build-tool control source based on said software package identifier; and executing at least one software build tool based on said software-build-tool control source to build said software package in said directory tree defined by said directory list, in a manner to
(1) use a separate set of said files for each one of said project and platform combinations; and (2) share any file in said file list between different said project and platform combinations.
16. A cross-platform data-processing system for managing software packages across a plurality of project and platform combinations, said packages including a configuration file, a directory list, and a file list, said directory list defining a directory tree containing a software package, and said file list containing a plurality of files, said system comprising: computer-readable instructions for generating at least one external- action-engine control source based on said configuration file, said directory list, and said file list; and computer-readable instructions for executing an external action engine using said external-action-engine control source to manipulate said files corresponding to said software package in said directory tree defined by said directory list, in a manner to
(1) use a separate set of said files for each one of said plurality of project and platform combinations, and
(2) share any file in said file list between different said project and platform combinations.
17. A system according to claim 16, wherein said computer-readable instructions for generating at least one external action engine control source further comprise: computer-readable instructions for receiving input reflecting information about an action to be performed.
18. A system according to claim 16, wherein said external action engine is a make program.
19. A system according to claim 16, wherein said external action engine is a concurrent versions system program.
20. A system according to claim 19, wherein the computer-readable instructions for executing an external action engine further comprise: computer-readable instructions for executing said concurrent versions system program to retrieve files corresponding to a predetermined project and platform combination.
21. A system according to claim 19, wherein the computer-readable instructions for executing an external action engine further comprise: computer-readable instructions for executing the concurrent versions system program to check-in files corresponding to a predetermined project and platform combination.
22. A system according to claim 19, wherein the computer-readable instructions for executing an external action engine further comprise: computer-readable instructions for executing the concurrent versions system program to tag a set of files corresponding to a predetermined project and platform combination.
23. A system according to claim 16, wherein said file list is obtained from a database source comprising at least one ASCII file located in at least one directory identified in said directory list.
24. A system according to claim 16, wherein said computer-readable instructions for generating at least one external-action-engine control source is performed by a platform independent action engine.
25. A system according to claim 24, wherein said platform independent action engine is a Bourne shell script.
26. A system according to claim 16, wherein said file list comprises at least one source-code file.
27. A system according to claim 16, wherein said file list comprises at least one engineering documentation file.
28. A system according to claim 27, wherein said engineering documentation file further comprises a documentation file in rich text format.
29. A system according to claim 16, wherein said external action engine control source further comprises a Makefile.
30. A data processing system for building a software package suitable for customer delivery, across a plurality of project and platform combinations, said software package being identified by a software package identifier comprising a combination of a project identifier and a platform identifier, said software package capable of being built using software build information including at least one directory list, at least one file list, and at least one software-build-tool control source, said file list containing a plurality of files and said directory list defining a directory tree, and said system comprising: means for receiving said software package identifier including said project identifier and said platform identifier; means for accessing said software build information from at least one data source comprising: at least one configuration source; and at least one database source including said directory list and said file list; means for generating said software-build-tool control source based on said software package identifier; and means for executing at least one software build tool based on said software-build-tool control source to build said software package in said directory tree defined by said directory list, in a manner to
(1) use a separate set of said files for each one of said project and platform combinations; and
(2) share any file in said file list between different said project and platform combinations.
PCT/US2001/024924 2000-08-10 2001-08-07 Platform independent project built and management tool WO2002015007A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2001283211A AU2001283211A1 (en) 2000-08-10 2001-08-07 Platform independent project built and management tool

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US22430100P 2000-08-10 2000-08-10
US60/224,301 2000-08-10
US09/879,750 2001-06-12
US09/879,750 US6694778B2 (en) 2000-08-25 2001-06-12 Cut design of diamond for ornamental use

Publications (1)

Publication Number Publication Date
WO2002015007A1 true WO2002015007A1 (en) 2002-02-21

Family

ID=26918587

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/024924 WO2002015007A1 (en) 2000-08-10 2001-08-07 Platform independent project built and management tool

Country Status (2)

Country Link
AU (1) AU2001283211A1 (en)
WO (1) WO2002015007A1 (en)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20030075097A (en) * 2002-03-16 2003-09-22 박민성 Remote controlling method on the Linux System through the internet
CN102289374A (en) * 2011-08-31 2011-12-21 中兴通讯股份有限公司 Method and device for constructing cross-platform software running environment
WO2012062063A1 (en) * 2010-11-12 2012-05-18 中兴通讯股份有限公司 Method and apparatus for generating and uninstalling software installation package
US10095499B2 (en) 2016-09-16 2018-10-09 Microsoft Technology Licensing, Llc Optimization for multi-project package manager
CN109669914A (en) * 2018-11-15 2019-04-23 深圳壹账通智能科技有限公司 Item file storage method, device, equipment and computer readable storage medium
CN116107628A (en) * 2022-12-21 2023-05-12 山东未来网络研究院(紫金山实验室工业互联网创新应用基地) Document sorting method based on node. Js

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4809170A (en) * 1987-04-22 1989-02-28 Apollo Computer, Inc. Computer device for aiding in the development of software system
US5574898A (en) * 1993-01-08 1996-11-12 Atria Software, Inc. Dynamic software version auditor which monitors a process to provide a list of objects that are accessed
US5960196A (en) * 1996-12-18 1999-09-28 Alcatel Usa Sourcing, L.P. Software release metric reporting system and method
US6170081B1 (en) * 1998-09-17 2001-01-02 Unisys Coporation Method and system for interfacing to a variety of software development tools

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4809170A (en) * 1987-04-22 1989-02-28 Apollo Computer, Inc. Computer device for aiding in the development of software system
US5574898A (en) * 1993-01-08 1996-11-12 Atria Software, Inc. Dynamic software version auditor which monitors a process to provide a list of objects that are accessed
US5960196A (en) * 1996-12-18 1999-09-28 Alcatel Usa Sourcing, L.P. Software release metric reporting system and method
US6170081B1 (en) * 1998-09-17 2001-01-02 Unisys Coporation Method and system for interfacing to a variety of software development tools

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
HIRANO ET AL.: "Extendible hashing for concurrent insertions and retrievals", IEEE PROCEEDINGS OF PDP, 1996, pages 235 - 242, XP002949546 *
WEIN ET AL.: "Evolution is essential for software tool development", IEEE, 1995, pages 272 - 281, XP002949547 *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20030075097A (en) * 2002-03-16 2003-09-22 박민성 Remote controlling method on the Linux System through the internet
WO2012062063A1 (en) * 2010-11-12 2012-05-18 中兴通讯股份有限公司 Method and apparatus for generating and uninstalling software installation package
CN102289374A (en) * 2011-08-31 2011-12-21 中兴通讯股份有限公司 Method and device for constructing cross-platform software running environment
US10095499B2 (en) 2016-09-16 2018-10-09 Microsoft Technology Licensing, Llc Optimization for multi-project package manager
CN109669914A (en) * 2018-11-15 2019-04-23 深圳壹账通智能科技有限公司 Item file storage method, device, equipment and computer readable storage medium
CN116107628A (en) * 2022-12-21 2023-05-12 山东未来网络研究院(紫金山实验室工业互联网创新应用基地) Document sorting method based on node. Js
CN116107628B (en) * 2022-12-21 2023-09-08 山东未来网络研究院(紫金山实验室工业互联网创新应用基地) Document sorting method based on node. Js

Also Published As

Publication number Publication date
AU2001283211A1 (en) 2002-02-25

Similar Documents

Publication Publication Date Title
US7152229B2 (en) Workflow code generator
US6807548B1 (en) System and methodology providing automated selection adjustment for refactoring
US7263699B2 (en) Preparation of a software configuration using an XML type programming language
US5761510A (en) Method for error identification in a program interface
US5325533A (en) Engineering system for modeling computer programs
US6430556B1 (en) System and method for providing a query object development environment
US5519866A (en) Method and apparatus of incrementally linking components of a modeled computer program
US5911074A (en) Process for manipulating data models used in software engineering
US7725524B2 (en) Process automation system and method having a hierarchical architecture with multiple tiers
US20030093433A1 (en) Method and system for software application development and customizible runtime environment
US7886265B2 (en) Process automation system and method employing property attachment techniques
JPH0334018A (en) Method and instrument for capsulating computer program
WO2009140154A1 (en) Methods and systems for developing, debugging, and executing data integration applications
EP2013713A2 (en) A method and system for generating application data editors
EP0814403B1 (en) Computer system with context switch and program development therefor
US20050273398A1 (en) Collection content classifier
US8042089B2 (en) Process automation system and method employing multi-stage report generation
US6944620B2 (en) File system creator
CA2453605C (en) Integrated visual and language-based system and method for reusable data transformations
WO2002015007A1 (en) Platform independent project built and management tool
US7058651B2 (en) Method, computer program product, and system for automatic class generation with simultaneous customization and interchange capability
JP2003535415A (en) A software development system that presents a logical view of project components before compilation, facilitates selection, and indicates missing links
Laurila Comparison of javascript bundlers
II User's Manual
Linka Visual Studio refactoring and code style management toolset

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP