tag | f17387a5f9ecac6400cfa14071128f22a9566a34 | |
---|---|---|
tagger | Jonah Graham <jonah@kichwacoders.com> | Wed Jun 30 11:52:56 2021 -0400 |
object | dcbb2a51bbc505585ef372a9e3501577c72abf4f |
CDT 10.3.1
commit | dcbb2a51bbc505585ef372a9e3501577c72abf4f | [log] [tgz] |
---|---|---|
author | Jonah Graham <jonah@kichwacoders.com> | Sat Jun 19 15:32:31 2021 -0400 |
committer | Jonah Graham <jonah@kichwacoders.com> | Sat Jun 19 15:32:31 2021 -0400 |
tree | d89ce976faa00557fb908d4689ae53c9964c647b | |
parent | 6b332e35cdb05e642af32c9d6151e1488d1da476 [diff] |
Bug 574331: Set default query results for tests Most of the tests in this bundle already had this bit of code before calling create project. This makes BuildDescriptionModelTests consistent with the rest. Note that this modifies global state and does not restore it. However, as that is consistent with the other tests in this bundle, and the global state is only maintained while running tests on this bundle, I am not fixing this aspect of the code. Change-Id: I2004af177a959e1efbd45b23c960b517d8993b7c
Please see CONTRIBUTING.md for contributing information
Most developers, developing CDT in the Eclipse IDE, should use Getting_started_with_CDT_development.
Eclipse CDT uses the standard Maven and Tycho workflow for building CDT using Maven 3.6.0 and Java 8. 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
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. 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.
There are a number of profiles (-P to mvn) to control the behaviour of the build.
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:
mvn verify -DuseSimrelRepo -f debug/org.eclipse.cdt.debug.application.product
Using the build-standalone-debugger-rcp
profile will include the standalone debugger, located in debug/org.eclipse.cdt.debug.application.product
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/
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
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.
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.
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
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.
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.
Documentation generation for CDT can be time consuming. For local builds this can be skipped with -DskipDoc=true
Running tests for CDT can be time consuming. For local builds this can be skipped with -DskipTests=true
.
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.
Running a build with uncommitted changes will normally cause an error. To run a build with uncommited changes use -Djgit.dirtyWorkingTree-cdtDefault=warning
For running CDT's DSF-GDB tests, this specifies the path to the location of gdb.
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):
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
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 librarieslinux.ppc64le
- uses local tools and builds only linux.ppc64le librariesdocker
- uses CDT's docker releng images to do the native builds for all platformsall
- uses local tools to do the native builds for all platformsTherefore 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.:
mvn process-resources -Dnative=docker -DuseSimrelRepo -f native/org.eclipse.cdt.native.serial
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 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.
Tests in CDT can be marked as Slow or Flaky to prevent them running as part of the standard test suites. See excludedGroups to skip slow or flaky tests sections above.
The proper way to mark a test as slow or flaky is to add a JUnit5 @Tag on the test with flakyTest
or slowTest
. The canonical values for these are in the JUnit5 base test org.eclipse.cdt.core.testplugin.util.BaseTestCase5
.
These tags can only be applied to JUnit5 (aka Jupiter) tests. If a test needs converting, do that in a separate commit before adding the tags so that the test refactoring can be verified before excluding the test from normal runs.
To take advantage of new features, such as excluding flaky and slow tests, individual tests need to JUnit5 (aka Jupiter). If a test is currently written in JUnit4 or JUnit3 style it needs to be converted to JUnit5 first. Those tests that currently derive from org.eclipse.cdt.core.testplugin.util.BaseTestCase
can change to org.eclipse.cdt.core.testplugin.util.BaseTestCase5
and make further adjustments. Common adjustments are:
setUp
/tearDown
methods to use @BeforeEach
and @AfterEach
annotations@BeforeAll
and @AfterAll
.@Test
annotation (make sure to use org.junit.jupiter.api.Test
and not JUnit4's org.junit.Test
)org.junit.jupiter.api.Assertions
(note that in JUnit5 the message is now last instead of first, this generally leads to an error by changing the imports, except in the case of assertEquals
where the first and third parameter are String
)