Patent Application
20190265959
During the development of a software application, a developer typically writes and debugs code for the application in the context of a build directory that resides on the developer's machine or some other storage location that is accessible to the developer. This build directory defines the hierarchical organization of the application's files and the location of each such file relative to the application executable file(s) (e.g., .exe file(s), .dll file(s), etc.) in the development environment. For example, the build directory may include a main application executable in a “main” subdirectory, asset files in an “assets” subdirectory under the “main” subdirectory (i.e., “main\assets”), configuration files in a “config” subdirectory, and so on.
When development of the application is complete, a builder (who may or may not be the same as the developer) takes all of the application's files from the build directory and packages them into one or more installable software packages. These packages are then made available to end-users via one or more distribution channels (e.g., an online store, physical media, etc.) for installation on their machines.
In some cases, the packaging process can cause the hierarchical organization of the application's files as installed on an end-user's machine—in other words, the application's install directory—to differ from the build directory in the development environment. In scenarios where the builder and the developer are one in the same (i.e., the same individual), the developer will be directly aware of this and can make appropriate changes to the application executable(s) so that the executable(s) can correctly find the application's files within the install directory at runtime.
However, in scenarios wherein the builder and the developer are different individuals or the builder is an automated agent, the developer generally will not have direct knowledge of packaging decisions made by the builder that result in a divergence between the install and build directories. This means that the builder and the developer must closely coordinate their activities in order to ensure that the application will run properly once installed on end-user machines. This coordination can be time-consuming and burdensome, particularly if the application is updated and re-distributed on a frequent basis.
Techniques for automatically synchronizing the install and build directories of a software application are provided. According to one set of embodiments, a computer system can, at a time of installing the application, extract an intent file from a software package comprising at least one file of the application, where the intent file includes a mapping that identifies a first location for the file with respect a build directory of a development environment where the application was developed and a second location for the file with respect to an install directory of the computer system where the application will be, or has been, installed. If the first location is different from the second location, the computer system can create a hard link for the file at the first location within the install directory that points to an instance of the file residing at the second location within the install directory.
In the following description, for purposes of explanation, numerous examples and details are set forth in order to provide an understanding of various embodiments. It will be evident, however, to one skilled in the art that certain embodiments can be practiced without some of these details, or can be practiced with modifications or equivalents thereof
Embodiments of the present disclosure provide techniques for automatically synchronizing the directory structure of a software application as installed on an end-user machine (i.e., the application's install directory) with the directory structure of the application as maintained in a development environment (i.e., the application's build directory). With these techniques, there is no need for the application developer to be aware of how the packaging process carried out by the application builder may change the application's installed file hierarchy; instead, the application developer can simply write his/her code with the assumption that all of the application's files will be located in the same relative locations in the install directory as in the build directory. If the packaging process causes a particular file to move to a different location once the application is installed on an end-user's machine (e.g., from subdirectory “A” in the build directory to subdirectory “B” in the install directory), the techniques described herein can automatically create, in the install directory, a hard link at the old location/file path of the file (as it existed in the build directory) which points to the new location of the file in the install directory. In this way, the application executable(s) can correctly find and access the file via the hard link, even though the file has moved to a different location post-installation.
The foregoing and other aspects of the present disclosure are described in further detail in the sections that follow.
To provide context for the embodiments described herein,
As depicted in
Upon completing development of the application, developer 104 notifies builder 108. In response, builder 108 uses a packaging tool 112 to ingest the file contents/hierarchy of build directory 110 and, based on a number of packaging rules or decisions made by builder 108, generate one or more installable software packages 114(1)-(N) for the application. For instance, builder 108 may determine that the application executable and core libraries should be placed into one package, a first subset of the application's assets should be placed into another package, a second subset of the application's assets should be placed into yet another package, etc.
Finally, software packages 114(1)-(N) are made available to an end-user 116, who can install the packages (and thus, the application) via an installer program 118 onto his/her system 120. The end result of this installation process is the creation of an install directory 122 on end-user system 120 that includes the installed files of the application.
As noted in the Background section, one complication with the development and packaging workflow described above is that, in some cases, the packaging decisions made by builder 108 can change the location of certain application files in install directory 122 relative to build directory 110. This, in turn, can cause the application to break once installed on end-user system 120 (if the changes are not accounted for in the application code).
To better understand this complication, consider example scenario 200 depicted in
As part of the packaging process carried out by builder 108, “app.exe” is packaged into a first software package (in this example an APPX package, although other types of packages are also possible) named “pkg_main.appx.” Further, “level1.txt” is packaged into a second software package named “assets1.appx”; “level2.txt” and “level3.txt” are packaged into a third software package named “assets2.appx”; and “opening.mp4” and “ending.mp4” are packaged into a fourth software package named “movies.appx.”
Due to the nature of the APPX packaging model, this packaging configuration results in an install directory on end-user system 120 where the “assets” and “fmv” subdirectories are no longer children of the “main” subdirectory; rather, as shown in
It is possible to mitigate these problems by having developer 104 modify his/her code accordingly to account for the new locations of files in install directory 122. However, as mentioned previously, if developer 104 and builder 108 are different individuals, this mitigation requires close coordination between the individuals, which can be time-consuming and burdensome. Further, even in scenarios where developer 104 and builder 108 are one in the same, it would be preferable for developer 104 to not have to worry about how his/her packaging decisions may impact the application code.
To address the foregoing and other similar issues,
At a high level, intent file generator 302 can, at the time builder 108 uses packaging tool 112 to generate software packages 114(1)-(N), create an “intent file” that includes, for each file in build directory 110, a mapping between the location (i.e., file path) of that file as it exists in build directory 110 and the location (file path) of that file as it will exist in install directory 122. These mappings will largely depend on how builder 108 decides to partition the files in build directory 110 across packages 114(1)-(N), since this partitioning will control how the files will be laid out in install directory 122. Upon creating the intent file, intent file generator 302 can include the intent file in one or more of packages 114(1)-(N) (or in an aggregated bundle of these packages, such as an APPX bundle).
Then, when end-user 116 installs packages 114(1)-(N) on his/her system 120 via installer 118, intent file processor 304 can extract the intent file and, for each mapping therein, determine whether the “old” location of the application file corresponding to that mapping (i.e., the relative location in build directory 110) is different from the “new” location of the application file (i.e., the relative location in install directory 122). If so, intent file processor 304 can create, in install directory 122, a hard link at the old location that points to the file at the new location. As known in computing, a hard link is a file system entry that associates a name (i.e., the name of the hard link) with an actual file in the file system. In this manner, intent file processor 304 can automatically synchronize the structure of install directory 122 with the structure of build directory 110 and enable the application executable to access all of the files of the application at the relative locations they reside at in build directory 110, even though they may have been moved to different locations within install directory 122.
To illustrate the foregoing,
With the general architecture and approach described above, a number of advantages are realized. First, in scenarios where developer 104 and builder 108 are different individuals, there is no need for these two individuals to stay in sync regarding the packaging decisions made by builder 108 and how those decisions may change the installed file layout of the application. This can save a significant amount of time and effort, particularly if the application is iterated on and updated frequently.
Second, even in cases where developer 104 also packages the application, developer 104 does not need modify any code or make other changes to the application to account for packaging decisions that change the installed locations of files. Instead, developer 104 can simply rely on components 302 and 304 to automatically synchronize the directory structure of install directory 122 with build directory 110, thereby reducing the amount of work for the developer.
It should be appreciated that the system diagram shown in
Starting with blocks 602 and 604, packaging tool 112 can retrieve the files of the application from build directory 110 of development system 102 and a set of packaging rules defined by, e.g., builder 108. The packaging rules can specify how the files in build directory 110 should be partitioned into packages 114(1)-(N) (e.g., files F1 and F2 go in to package P1, file F3 goes in to package P2, etc.). Based on these rules, packaging tool 112 can create packages 114(1)-(N) (block 606) and optionally aggregate packages 114(1)-(N) into a package bundle (block 608).
At block 610, packaging tool 112 can invoke intent file generator 302 to generate an intent file for the application. In response, intent file generator 302 can enter a loop for each application file in build directory 110 (block 612) and, within this loop, create a mapping between the location of the application file within build directory 110 and the location of the application file where it will appear once installed on an end-user system (i.e., within install directory 122) (block 614). In one set of embodiments, intent file generator 302 can determine this mapping based on the packaging rules retrieved at block 604. In other embodiments, intent file generator 302 can determine this mapping based on information manually defined/provided by builder 108.
Once created, intent file generator 302 can add the mapping to the intent file (block 616) and reach the end of the current loop iteration (block 618). Intent file generator 302 can then repeat loop 612 until all of the files in build directory 110 have been processed. Finally, at block 620, intent file generator 302 can add the intent file to the package bundle created at block 608 and workflow 600 can end.
At blocks 702 and 704, installer 118 can first extract the various packages 114(1)-(N) included in the package bundle and can install the files for each package 114 at appropriate locations (e.g., subdirectories) within install directory 122 of system 120.
Once the packages have been installed, installer 118 can invoke intent file processor 304 (block 706). In response, intent file processor 304 can extract the intent file from the package bundle (if not extracted already) (block 708) and can enter a loop for each mapping defined in the intent file (block 710). Within this loop, intent file processor 304 can check whether the old location of the application file corresponding to this mapping in build directory 110 is the same as the new location of the application file within install directory 122 (block 712). If so, no action needs to be taken and intent file processor 304 can proceed to the end of the current loop iteration (block 714).
However, if the old and new locations are not the same (indicating that the relative location of the application file has moved), intent file processor 304 can create, within install directory 122, a hard link for the application file at the old location that points to the actual, installed application file at the new location (block 716). For example, if file “level1.txt” resided under “main\assets” in build directory 110 but moved to “assets” in install directory 122, intent file processor 304 can create a hard link “main\assets\level1.txt” in install directory 122 that points to the actual file “assets\level1.txt” in install directory 122. This hard link can be thought of as a placeholder that can be accessed like a real file, but simply links to a file that exists elsewhere.
Upon creating the hard link, intent file processor can reach the end of the current loop iteration (block 714) and return to block 708 to process additional mappings in the intent file. Once all of the mappings have been processed workflow 700 can end.
Bus subsystem 804 can provide a mechanism for letting the various components and subsystems of computer system 800 communicate with each other as intended. Although bus subsystem 804 is shown schematically as a single bus, alternative embodiments of the bus subsystem can utilize multiple busses.
Network interface subsystem 816 can serve as an interface for communicating data between computer system 800 and other computer systems or networks. Embodiments of network interface subsystem 816 can include, e.g., an Ethernet module, a Wi-Fi and/or cellular connectivity module, and/or the like.
User interface input devices 812 can include a keyboard, pointing devices (e.g., mouse, trackball, touchpad, etc.), a touch-screen incorporated into a display, audio input devices (e.g., voice recognition systems, microphones, etc.), motion-based controllers, and other types of input devices. In general, use of the term “input device” is intended to include all possible types of devices and mechanisms for inputting information into computer system 800.
User interface output devices 814 can include a display subsystem and non-visual output devices such as audio output devices, etc. The display subsystem can be, e.g., a transparent or non-transparent display screen such as a liquid crystal display (LCD) or organic light-emitting diode (OLED) display that is capable of presenting 2D and/or 3D imagery. In general, use of the term “output device” is intended to include all possible types of devices and mechanisms for outputting information from computer system 800.
Storage subsystem 806 includes a memory subsystem 808 and a file/disk storage subsystem 810. Subsystems 808 and 810 represent non-transitory computer-readable storage media that can store program code and/or data that provide the functionality of embodiments of the present disclosure.
Memory subsystem 808 includes a number of memories including a main random access memory (RAM) 818 for storage of instructions and data during program execution and a read-only memory (ROM) 820 in which fixed instructions are stored. File storage subsystem 810 can provide persistent (i.e., non-volatile) storage for program and data files, and can include a magnetic or solid-state hard disk drive, an optical drive along with associated removable media (e.g., CD-ROM, DVD, Blu-Ray, etc.), a removable or non-removable flash memory-based drive, and/or other types of storage media known in the art.
It should be appreciated that computer system 800 is illustrative and other configurations having more or fewer components than computer system 800 are possible.
The above description illustrates various embodiments of the present disclosure along with examples of how aspects of these embodiments may be implemented. The above examples and embodiments should not be deemed to be the only embodiments, and are presented to illustrate the flexibility and advantages of the present disclosure as defined by the following claims. For example, although certain embodiments have been described with respect to particular process flows and steps, it should be apparent to those skilled in the art that the scope of the present disclosure is not strictly limited to the described flows and steps. Steps described as sequential may be executed in parallel, order of steps may be varied, and steps may be modified, combined, added, or omitted. As another example, although certain embodiments have been described using a particular combination of hardware and software, it should be recognized that other combinations of hardware and software are possible, and that specific operations described as being implemented in software can also be implemented in hardware and vice versa.
The specification and drawings are, accordingly, to be regarded in an illustrative rather than restrictive sense. Other arrangements, embodiments, implementations and equivalents will be evident to those skilled in the art and may be employed without departing from the spirit and scope of the present disclosure as set forth in the following claims.
