mainCrossplex - Summary

 
 
Membership Info
Group Admin:
1 active member

Group identification
Id: 10362
System Name: crossplex
Name: Crossplex
Group Type: non-GNU software and documentation

Search in this Group


 

This group is not part of the GNU Project.

The Crossplex Package is a library of macros for make that enable enterprise-scale development of embedded operating system distributions, such as (but not limited to) those based on the Linux kernel and the GNU family of compiler tools and libraries.

Crossplex was designed from the ground up to support many advanced features that are important to professionals responsible for quickly prototyping and efficiently maintaining a large number of related distributions.  Here is a partial list of features that Crossplex supports:

1. The build should be able to output all configurations simultaneously in unique segments of the output tree without interference. This means that object files (intermediate or deployable) generated from different configurations should be output to different paths. If multiple configurations share component objects that are built identically, those components may be consolidated to the point that the build only builds them once. To the extent that any object (intermediate or deployable) is specific to a configuration, it must be output to a unique path. Benefit: doing "make clean" is not required in order to ensure the integrity of your build. However, if this requirement is not met, "make clean" is always required.

2. All configuration should be contained in checked-in files. This means that the command line to build does not contain configuration information, and the environment is not used to transmit configuration information. Benefits: 1) builds are repeatable, and 2) builds are fully specified by checked-in source. If this requirement is not met, i.e. if configuration information is sent in via the environment or the build command line, the build is not necessarily repeatable.

3. Maintain third party software in original packaging (according to license). This means that if you download a tarball from an open source project or a vendor, you store that tarball in the source control system as the actually downloaded tarball. Benefits: 1) since all manipulations of the software are performed by the build system, those manipulations are explicit and manageable. 2) if the vendor releases a new version of the package, re-integration work (i.e. the work of porting your project to their new software) is minimized.

4. Support build and use of multiple toolchains in a single build. This is required to target multiple hardware platforms in a single build, but also has the benefit of simplifying toolchain maintenance.

5. Specify build dependencies explicitly. This improves build performance three ways: by only rebuilding objects whose source has been changed, by allowing arbitrarily parallelized builds, and by making partial clean targets more trustworthy. It also has the benefits of better documentation of the build process and enforcement of strict hygiene in the build system.

6. Maintain built objects in directories named for the configuration. This makes it easy to switch between the version you're testing. You might maintain several different patch sets (think "mallocdb", "trace toolkit", or "performance enhancements") , several different source versions (eg "linux-2.6.28" vs "linux-2.6.29"), and several different build modes (think "RELEASE" vs "DEVEL"). You can have all of these builds coexist for easy comparison. Naming the directories according to the configuration makes it easy to identify what build is where.

Registration Date: Tue 06 Oct 2009 06:26:56 PM UTC
License: GNU General Public License v2 or later
Development Status: 4 - Beta

 

Latest News rss feed

No news found

Quick Overview
 Memberlist (1 member)

Communication Tools
 Mailing Lists (1 public mailing list)

Development Tools
 Task Manager (open items: 0, total: 0)

Back to the top

Powered by Savane 3.13-4b48.
Corresponding source code