cdt/launch/org.eclipse.cdt.docker.launcher/icons/warning_obj.gif
Jeff Johnston c96d126b86 Bug 513589 - Add support to build CDT projects in a Docker Container
- add IOptionalBuildObjectPropertiesContainer interface to use for
  objects that supply optional build properties
- add new IOptionalBuildProperties interface that defines
  optional build properties donated by external plug-ins
- add new
- change IConfiguration to an IOptionalBuildObjectPropertiesContainer
- change IManagedProject to be an
  IOptionalBuildObjectPropertiesContainer
- fix ProcessClosure to ensure that readers are not null before
  accessing them
- fix Container launch delegate to look at project optional
  build properties for active configuration to fetch connection
  and image info and use said info to find a matching
  launch or create a new one
- have Container launch delegate use the image name as part of
  the launch config name
- have Container launch short-cut also use the project's
  optional build properties for the active config to get
  connection and image information before any defaulting
- change AutotoolsNewMarkerGenerator to store the command
  launcher as an ICommandLauncher
- add new CommandLauncherFactory extension to cdt.core that
  allows plug-ins to specify a CommandLauncherFactory that
  will return an ICommandLauncher based on the project
- add macros for new extension to CCorePlugin
- add new CommandLauncherManager class that loads
  CommandLauncherFactory extensions and is used to give
  an ICommandLauncher wrapper that will go through the list
  of CommandLauncherFactory extensions until one returns
  non-null ICommandLauncher
- add code to RemoteCommandLauncher so it will use the
  CommandLauncherManager to get the local launcher
- also change RemoteCommandLauncher to check at execution
  time whether the command is local and in that case use
  the local command launcher
- add new ICommandLauncherFactory interface
- add new ContainerCommandLauncher to launch
- add new ContainerCommandLauncherFactory class for returning
  a ContainerCommandLauncher instance to launch commands
  in a Docker Container
- change MakeBuilder to use CommandLauncherManager to get
  its ICommandLauncher
- change CommandBuilder to use CommandLauncherManager too
- ditto for Builder and AbstractBuiltinSpecsDetector and
  ExternalToolInvoker
- change Configuration to load/store optional build properties
  as well as return the properties to get/set
- ditto for MultiConfiguration
- change ManagedProject to implement IOptionalBuildOptionProperties
  interface
- ditto for ProjectType
- create new OptionalBuildProperties class to store optional
  build properties for a configuration
- bump cdt.docker.launcher to 1.1.0
- use CommandLauncherFactory extension to define
  ContainerCommandLauncherFactory
- add optional ContainerPropertyTab which allows the end-user to
  optionally choose to build a C/C++ project in a Container
  and specify the connection/image to use
- in LanguageSettingsSerializableSettings class, call the
  CommandLauncherManager getLanguageSettingEntries method
  to get the massaged language setting entries based on the
  current list
- in LanguageSettingsProviderSerializer, try and get the
  pooled entries using the cfg description so that it will
  have the project and can use the CommandLauncherManager
  to get entries from image
- in ContainerCommandLauncherFactory move cached headers under
  a HEADERS directory in the plug-in area
  - create a sub-directory for the connection and a sub-directory
    for the image based on cleansed names
  - store the real names of the connection and image to use
    later in the DockerHeaderPreferencePage
- modify LanguageSettingsEntriesTab to force the horizontal
  scroll bar to appear (this is a bug in SWT SashForm support
  and the fix here isn't quite correct, but is better)
- add new DockerHeaderPreferencePage that allows user to
  remove cached headers from images
- change C/C++ Docker preferences to be titled: Docker Container
- fix LanguageSettingsWorkspaceProvider.getSettingEntries method
  to use the CommandLauncherManager so entries will be transformed
  to use cached headers
- add BaseDatabindingModel class
- add DataVolumeModel class to model a volume mount
- add ContainerPropertyVolumes model to model volume specification
  and selected volumes
- add properties to ContainerCommandLauncher to represent
  volumes and selected volumes for a configuration
- add ContainerDataVolumeDialog for specifying a volume
  mount by the end-user
- add a null detector for cfgDescription in
  LanguageSettingsSerializableProvider
- fix AutotoolsNewMakeGenerator.getWinOSType to not specify "." for
  working dir
- fix GCCBuiltinSpecsDetectorCygwin to not map paths to Cygwin if
  the current configuration is enabled for container build
- add logic to ContainerCommandLauncher to look for Windows
  file formats and change them to unix format and map
  any "." working dir to be /tmp
- fix ContainerLauncherConfigurationDelegate similarly
- fix AbstractBuiltinSpecsDetector to pass in the current
  configuration description when getting the CommandLauncher
  since the current configuration may not be the active
  configuration
- change ContainerPropertyTab to add Elf and GNU Elf binary parsers
  when build in Container is chosen so that output executables
  are treated as Binaries by the CDT project
- add documentationl for the ContainerPropertyTab in Build Settings and
  the Data Volume dialog pop-up it brings up
- change CommandBuilder to accept a project as an argument
  to its constructor and to pass this as an argument to
  the CommandLauncherManager
- have StepBuilder pass project when creating a CommandBuilder

Change-Id: Ia78488b93056e6ec7ca83a6c87b3a9d2b9424943
2017-10-22 05:38:51 -04:00

337 B
16x16px