Feature Compilation with Runtime Configuration

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

In software development, manually changing source code to control feature inclusion in application builds is inconvenient and time-consuming, often leading to broken dependencies and errors when features are removed or enabled/disabled.

Innovation Solution

A system that uses a separate manifest for feature configuration, allowing features to be configured differently through staging options such as always enabled, always disabled, enabled by default, or disabled by default, enabling dynamic enablement/disabling at runtime without modifying the source code, and using a feature compiler to generate multiple builds from a single compiled source code.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If manually changing source code is used to control feature inclusion, then feature configuration flexibility is improved, but development time and complexity increase

Engineering Contradiction:

Improvefeature configuration flexibilityVSAvoiddevelopment time

Core Design Contradiction:

Adaptability or versatilityVSLoss of time

Solution Approach 1:

The source code is segmented into feature-specific code blocks that can be independently controlled through feature flags. Each feature is associated with specific code blocks that can be selectively included or excluded from builds without manually modifying the entire source code base.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

A feature configuration system acts as an intermediary between the source code and the build process. This system manages feature inclusion/exclusion through configuration files and build scripts, eliminating the need for direct manual source code modification while maintaining flexibility.

Inventive Principle:

Principle #24Intermediary (Mediator)

2Adaptability or versatility

If manually changing source code is used to remove features, then feature inclusion control is improved, but error rate increases due to broken dependencies

Engineering Contradiction:

Improvefeature inclusion controlVSAvoiddependency integrity

Core Design Contradiction:

Adaptability or versatilityVSReliability

Solution Approach 1:

The system performs preliminary analysis of feature dependencies before removing or disabling features. Build scripts automatically identify and handle dependent code blocks, ensuring that dependency relationships are maintained even when features are excluded from builds.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The build system provides feedback about dependency relationships when features are configured for inclusion or exclusion. This feedback mechanism helps developers understand the impact of feature configuration changes and prevents broken dependencies through automatic detection and reporting.

Inventive Principle:

Principle #23Feedback

3Adaptability or versatility

If multiple builds with different features are generated, then feature variability is improved, but build time and storage requirements increase

Engineering Contradiction:

Improvefeature variabilityVSAvoidbuild efficiency

Core Design Contradiction:

Adaptability or versatilityVSProductivity

Solution Approach 1:

A single source code base is designed to serve multiple build configurations through feature flags and conditional compilation. The same source code can be compiled into different builds with different feature sets by changing configuration parameters, eliminating the need for separate source code copies for each build variant.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Solution Approach 2:

Build variability is achieved by changing configuration parameters (feature flags, enable/disable settings) rather than creating different source code versions. The build system responds to parameter changes by selectively including or excluding feature code blocks during compilation, maintaining build efficiency while providing feature variability.

Inventive Principle:

Principle #35Parameter changes

4Adaptability or versatility

If multiple builds are stored for different features, then feature options are improved, but storage requirements increase

Engineering Contradiction:

Improvefeature optionsVSAvoidstorage space

Core Design Contradiction:

Adaptability or versatilityVSQuantity of substance

Solution Approach 1:

A single source code base serves multiple build configurations, eliminating the need to store duplicate source code copies for each feature variant. The universal source code can be recompiled with different feature configurations as needed, significantly reducing storage requirements while maintaining all feature options.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Data Source

PatentUS10423406B2Software feature compilation with runtime configuration

Publication Date: 2019.09.24 MICROSOFT TECHNOLOGY LICENSING LLC

AI summary

A statement in a software code segment for an application that associates the software code segment to a feature is identified. The software code segment includes a first code block and a second code block for the feature. A feature configuration for the feature is read from a manifest that lists a set of features in the application. When a staging option corresponds to a first staging option, the statement is evaluated against the staging option to remove one of the first code block and the second code block in executable code. When the staging option corresponds to a second staging option, the first software code block and the second code block are included in the executable code. The first code block and the second code block are configurable at runtime to be selected or not selected. The first version or the second version of the executable code are output.