mirrors/cdt
1
0
Fork 0
mirror of https://github.com/eclipse-cdt/cdt synced 2025-04-29 19:45:01 +02:00
Code Issues Wiki Activity
cdt/launch/org.eclipse.cdt.docker.launcher/plugin.properties

25 lines
1.3 KiB
Properties
Raw Normal View History

Add Docker launching support - use the new docker tooling plug-ins to launch and debug CDT C/C++ applications in docker containers Change-Id: I30689255a3443ce6d49f937f5e2506d86452915b
2015-04-24 19:38:08 -04:00
###############################################################################
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-02-09 18:43:05 -05:00
# Copyright (c) 2015,2017 Red Hat Inc. and others.
Add Docker launching support - use the new docker tooling plug-ins to launch and debug CDT C/C++ applications in docker containers Change-Id: I30689255a3443ce6d49f937f5e2506d86452915b
2015-04-24 19:38:08 -04:00
# All rights reserved. This program and the accompanying materials
# are made available under the terms of the Eclipse Public License v1.0
# which accompanies this distribution, and is available at
# http://www.eclipse.org/legal/epl-v10.html
#
# Contributors:
# Red Hat Inc. - initial API and implementation
###############################################################################
Plugin.name=C/C++ Container Launch Plug-in
Plugin.vendor=Eclipse CDT
Delegate.name=C/C++ Container Launcher
Delegate.desc=This launcher runs C/C++ applications in a specified Docker Container. The Container \
must be set-up to supply the C/C++ application what it needs to run.
LaunchConfigurationType.name=C/C++ Container Launcher
Shortcut.label=C/C++ Container Application
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-02-09 18:43:05 -05:00
DockerLaunchPreferencePage.name=Docker Container
DockerHeaderPreferencePage.name=Cached Headers
ContainerCommandLauncherFactory.name=Container Command Launcher Factory
Container.settings=Container Settings
ContainerBuild.property.enablement=Container Build Enablement
ContainerBuild.property.connection=Container Build Connection
ContainerBuild.property.image=Container Build Image
Reference in a new issue Copy permalink