Split apart the README file and update Contributing file from the wiki

This includes migrating the following pages from the wiki to
the source:

- https://wiki.eclipse.org/CDT/contributing
- https://wiki.eclipse.org/Getting_started_with_CDT_development
- https://wiki.eclipse.org/CDT/policy
- https://wiki.eclipse.org/CDT/git

Note that much of the content on those pages was redundant or
obsolete, therefore the files are not copied over as is
from the wiki.

In addition the content from https://www.eclipse.org/cdt/ has
migrated over as appropriate too. Much of https://www.eclipse.org/cdt/
was also redundant or obsolete too.

Change-Id: I2b38a4fbb3351c8eb8bbf8c910eb3a3118eda142

BUILDING.md

@@ -0,0 +1,168 @@
+# Eclipse CDT Command Line Build Instructions
+
+This document covers how to build Eclipse CDT from the command line (e.g. like you may do on Jenkins).
+
+## Contributing to and Editing Eclipse CDT
+
+Please see [CONTRIBUTING.md](./CONTRIBUTING.md) for contributing information, including setting up a development environment.
+
+## Command-line Build instructions with Maven
+
+Eclipse CDT uses the standard Maven and Tycho workflow for building CDT using Maven 3.8 and Java 17. Therefore to package CDT do:
+
+```
+mvn package
+```
+
+and the resulting p2 repository will be in `releng/org.eclipse.cdt.repo/target/repository`
+
+The current set of options to Maven used for building on the CI can be seen in the Jenkinsfiles on [cdt-infra](https://github.com/eclipse-cdt/cdt-infra/tree/master/jenkins/pipelines/cdt)
+
+To build CDT plug-ins you need a standard Maven & Java developement environment. The Dockerfiles used for CDT's images are published in [cdt-infra](https://github.com/eclipse-cdt/cdt-infra/tree/master/docker). The requirements for running all tests successfully and for rebuilding non-Java parts of CDT are much more extensive than standard Maven & Java and include items such as GCC, GDB, yarn, Node, etc. Refer to the Dockerfiles for the current versions of those dependencies.
+
+### Profiles
+
+There are a number of profiles (-P to mvn) to control the behaviour of the build.
+
+#### cdtRepo, simrelRepo, defaultCdtTarget
+
+Individual p2 repos can be turned on and off to allow building CDT, or parts of CDT against different target platforms easily. For example, you can:
+- test CDT against a pre-built CDT by using the cdtRepo profile.
+- build the standalone rcp debugger against the latest simrel `mvn verify -DuseSimrelRepo -f debug/org.eclipse.cdt.debug.application.product`
+
+#### build-standalone-debugger-rcp
+
+Using the `build-standalone-debugger-rcp` profile will include the standalone debugger, located
+in `debug/org.eclipse.cdt.debug.application.product`
+
+#### skip-all-tests, skip-tests-except-cdt-ui, skip-tests-except-dsf-gdb, skip-tests-except-lsp, skip-tests-except-cdt-other
+
+Using any of the above profiles can skip large sets of tests. The CI build uses this to parallelize tests. See https://ci.eclipse.org/cdt/view/Gerrit/
+
+#### terminal-only
+
+The terminal directory has a special profile that enables only the terminal and its dependencies when used. The allows
+running maven like this `mvn -f terminal/pom.xml verify -P only-terminal` to build and test only the terminal
+and its dependencies. A special terminal only p2 site is created in `terminal/repo/target/repository`. The CI build
+uses this to speedup turnaround on changes only affecting the terminal. See https://ci.eclipse.org/cdt/view/Gerrit/
+
+#### baseline-compare-and-replace
+
+`baseline-compare-and-replace` profile controls whether baseline replace and compare
+is performed. On a local build you want to avoid baseline replace and compare, 
+especially if you have different versions of Java than the baseline was built with.
+
+If you have the same version of Java as the build machine you can run baseline comparison and
+replace. To do that run with the `baseline-compare-and-replace` profile.
+
+Requires verify phase of maven to run, i.e. will not run with `mvn package` even if profile is specified.
+
+#### production
+
+Runs the production steps of the build. This profile can only be run on the CDT CI machines
+as access to Eclipse key signing server is needed to sign the jars.
+
+#### regenHelp
+
+Some of the help systems in Eclipse CDT require the `regenHelp` profile to rebuild their HTML from the source documents. For example, to regenerate the help
+for Autotools or Meson do:
+
+```
+mvn generate-resources -DuseSimrelRepo -f build/org.eclipse.cdt.meson.docs -PregenHelp
+```
+
+```
+mvn generate-resources -DuseSimrelRepo -f build/org.eclipse.cdt.autotools.docs -PregenHelp
+```
+
+#### jniheaders
+
+The `jniheaders` profile can be used on the `core/org.eclipse.cdt.core.native` and
+`native/org.eclipse.cdt.native.serial` to rebuild the header files for JNI natives.
+See also `native` property below.
+
+### Properties
+
+There are a number of properties (-D to mvn) to control the behaviour of the build. Refer to the
+pom.xml for the full list. Many of the properties are not intended to be set at the command
+line.
+
+#### skipDoc
+
+Documentation generation for CDT can be time consuming. For local builds this can be skipped
+with `-DskipDoc=true`
+
+#### skipTests
+
+Running tests for CDT can be time consuming. For local builds this can be skipped
+with `-DskipTests=true`.
+
+#### excludedGroups to skip slow or flaky tests
+
+Some tests in CDT are fairly slow to run and rarely are exercising actively changing code. Some tests in CDT are fairly flaky to run and rarely are exercising actively changing code. These tests are excluded from the main CDT builds (both master/branch and gerrit verify jobs) and are instead run in a special job. Therefore the Jenkinsfiles for master/branch and gerrit use excludedGroups by default.
+
+To skip slow tests use `-DexcludedGroups=slowTest`
+To skip flaky tests use `-DexcludedGroups=flakyTest`
+To skip both use `-DexcludedGroups=flakyTest,slowTest`
+
+See section below on marking tests for how to annotate a test properly.
+
+#### jgit.dirtyWorkingTree-cdtDefault
+
+Running a build with uncommitted changes will normally cause an error. To run a build with
+uncommited changes use `-Djgit.dirtyWorkingTree-cdtDefault=warning`
+
+#### dsf.gdb.tests.gdbPath
+
+For running CDT's DSF-GDB tests, this specifies the path to the location of gdb.
+
+#### cdt.tests.dsf.gdb.versions
+
+For running CDT's DSF-GDB tests, this specifies the executable names of the gdbs to run, comma-separated.
+
+There are a few special values that can be specified (see BaseParametrizedTestCase for source):
+
+- all: run all versions listed in ITestConstants.ALL_KNOWN_VERSIONS
+- supported: run all versions listed in ITestConstants.ALL_SUPPORTED_VERSIONS
+- unsupported: run all versions listed in ITestConstants.ALL_UNSUPPORTED_VERSIONS
+
+The default, defined in the root pom.xml, should be the most recent released version of gdb.
+
+To build all gdb versions for testing CDT see [download-build-gdb.sh](https://github.com/eclipse-cdt/cdt-infra/blob/master/docker/scripts/download-build-gdb.sh)
+
+#### native
+
+The `native` property can be used to build the native libraries. Defining the `native` property will activate profiles to add the extra steps to compile the natives libraries used by CDT. The main CDT build by default will not build the libraries, but instead use the versions of the libraries checked into git. Therefore when users modify the sources of the native libraries, they have to build and commit the changed library binaries as part of the commit.
+
+The `releng/scripts/check_code_cleanliness.sh`, which is run on the build machine as part of the gerrit and main build flows, will ensure that the libraries that are checked in are indeed up to date with their sources.
+
+The `native` property can be one of the following:
+
+- `linux.x86_64` - uses local tools and builds only linux.x86_64 libraries
+- `linux.ppc64le` - uses local tools and builds only linux.ppc64le libraries
+- `docker` - uses CDT's docker releng images to do the native builds for all platforms
+- `all` - uses local tools to do the native builds for all platforms
+
+Therefore to build all the natives using docker add `-Dnative=docker` to your maven command line (e.g. `mvn verify -Dnative=docker`). 
+
+To build only the native libraries `mvn process-resources` can be used on the individual bundles with the simrel target platform, e.g.:
+
+- Serial library: `mvn process-resources -Dnative=docker  -DuseSimrelRepo -f native/org.eclipse.cdt.native.serial`
+- Core library: `mvn process-resources -Dnative=docker  -DuseSimrelRepo -f core/org.eclipse.cdt.core.native`
+
+However, the challenge is that dll files on Windows have a timestamp in them. To have reproducible builds, we need to have a reproducible timestamp. As [Microsoft](https://devblogs.microsoft.com/oldnewthing/20180103-00/?p=97705) has moved away from using a timestamp to rather use a hash of the source files as the value, we therefore hash the source files used by the library and the header files for the Java API and use that as the value.
+
+An additional tip is to set the following in `.gitconfig` to allow you to diff `.dll` files. This will show the timestamp of the DLL in the diff as part of the DLL headers.
+
+```
+[diff "dll"]
+    textconv = objdump -x
+    binary = true
+```
+
+When the host is Windows, getting docker to behave as encoded in the pom.xml may be challenging, instead a command like this will probably work (replace your path to git root). Note that running this in git bash causes problems because of the /work in the command line arguments. (TODO integrate this command line way of running into the pom.xml so the original instructions work.)
+
+`docker 'run' '--rm' '-t' '-v' 'D:\cdt\git\org.eclipse.cdt:/work' '-w' '/work/core/org.eclipse.cdt.core.native' 'quay.io/eclipse-cdt/cdt-infra-eclipse-full:latest' 'make' '-C' 'native_src' 'rebuild'`
+
+See also `jniheaders` profile above.
+

CODE_OF_CONDUCT.md

@@ -0,0 +1,46 @@
+# Community Code of Conduct
+
+**Version 1.2  
+August 19, 2020**
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as community members, contributors, committers, and project leaders pledge to make participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment include:
+
+*   Using welcoming and inclusive language
+*   Being respectful of differing viewpoints and experiences
+*   Gracefully accepting constructive criticism
+*   Focusing on what is best for the community
+*   Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+*   The use of sexualized language or imagery and unwelcome sexual attention or advances
+*   Trolling, insulting/derogatory comments, and personal or political attacks
+*   Public or private harassment
+*   Publishing others' private information, such as a physical or electronic address, without explicit permission
+*   Other conduct which could reasonably be considered inappropriate in a professional setting
+
+## Our Responsibilities
+
+With the support of the Eclipse Foundation staff (the “Staff”), project committers and leaders are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
+
+Project committers and leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies within all project spaces, and it also applies when an individual is representing the Eclipse Foundation project or its community in public spaces. Examples of representing a project or community include posting via an official social media account, or acting as a project representative at an online or offline event. Representation of a project may be further defined and clarified by project committers, leaders, or the EMO.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the Staff at codeofconduct@eclipse.org. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The Staff is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
+
+Project committers or leaders who do not follow the Code of Conduct in good faith may face temporary or permanent repercussions as determined by the Staff.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant](https://www.contributor-covenant.org) , version 1.4, available at [https://www.contributor-covenant.org/version/1/4/code-of-conduct.html](https://www.contributor-covenant.org/version/1/4/code-of-conduct/)