Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP build-config.sh #171

Draft
wants to merge 2 commits into
base: develop
Choose a base branch
from
Draft

WIP build-config.sh #171

wants to merge 2 commits into from

Conversation

msmcconnell
Copy link
Contributor

@msmcconnell msmcconnell commented Feb 18, 2022

PR Details

Description

This is a Draft PR showing one approach for how we might reduce code duplication.
A build-config.sh file is created at the repo root which will build the config specified by config path as an argument. The script will then copy into the config any files present in template_config which are not currently present in the config being built. This means that the configs can now be thought of as file level diffs only the files which are different from the template_package are required for the config to be built.

Example usage:

./build-config.sh lexus_rx_450h_2019/ -d

Note that the -d argument is forwarded to the build-image.sh script.

Using this approach over 60 duplicate files were able to be deleted. If this approach is used, then future updates to the build system will be limited to the template_package and ./build-config.sh scripts instead of requiring duplication to other configs.

NOTE: I have not investigated how this approach would work with system releases or automated docker builds further work is needed there before this could be merged. There are also a handlful of file changes in drivers.launch.py which are not part of this PR but I accidently merged from another branch. They can be cleaned up during an actual review.

Related Issue

Motivation and Context

How Has This Been Tested?

Types of changes

  • Defect fix (non-breaking change that fixes an issue)
  • New feature (non-breaking change that adds functionality)
  • Breaking change (fix or feature that cause existing functionality to change)

Checklist:

  • I have added any new packages to the sonar-scanner.properties file
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
    CARMA Contributing Guide
  • I have added tests to cover my changes.
  • All new and existing tests passed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant