This adds basic support for VS 2022 by detecting the toolchain.
I.e. include paths, lib paths, and PATH env var are properly detected.
The detection works the same as 2017 and 2019 since vswhere.exe works
the same and the folder layout hasn't changed.
Revived from https://git.eclipse.org/r/c/cdt/org.eclipse.cdt/+/182202
- Configure the JRE for Java 21.
- Clone cdt-lsp
- Include its source locator in the targlet
- Configure both clones to rebase new branches by default.
- Add a working set for the CDT LSP projects.
The simrel and cdt update sites can be used to run partial builds
and are not used by default when doing builds. This change
brings those URLs up to date.
The maintenance of having a streamlined standalone debugger that
starts as fast as possible is no longer possible. See for
example #591 - therefore when using standalone debugger, use
the same sets of plug-ins/features as the product it is installed
in uses. The side effect is that the standalone debugger in this
use case will start slower and extra "stuff" will be present in
this UI.
For people just building the standalone debugger, provide a minimum
feature set. This will be many more bundles than before, but
should still provide a reasonably small set that starts well.
This simplification also includes removing the the duplicates set
of CDT docs (debug/org.eclipse.cdt.debug.application.doc). These
provided a simplified version of CDT's documentation targetted
at just standalone debugger. However there are a few problems related
to this duplication:
- The two sets of docs were not kept in sync
- The standalone docs appear in the online help, leading to
duplicated entries
- With the config.ini changes above, there is no way to exclude
the main docs in the standalone case, so remove the duplicate
A number of directly related clean-ups are included too:
- Remove the `ConfigGenerator.java` that stopped being referenced
in PR #761
- Complete the removal of `build-standalone-debugger-rcp` profile
that was started in #761. There is a small drawback to not having
this profile, the standalone debugger is very slow to build
compared to the rest of CDT. If this becomes a problem, restoring
this profile along with the changes made in #761 is reasonable.
- bring debug.product's licenses up to date
- modernize command line args to eclipse when using debug.product
Fixes#781
Building osxcross is somewhat problematic because the versions
are not fixed and reproducibility of making this docker file
can be problematic. For example new versions of cmake, etc
make be needed. TODO Is there a way to fix the version of
osxcross so that we can rebuild reliably?
- Fix links for cdt-infra
- The cdt-infra git repo is now archived, so this commit updates
the links to the current values.
- Add new Docker related files to the gitattributes as text files
- Update DEFAULT_BUFFER_SIZE for Java 21's value when building JNI,
this also means the dll/exe need a rebuild
- add a toolchains.xml since we use Java 21 toolchain, but most bundles
are Java 17 still
* Switch CI to Java 21
* Remove config generation for debug application
* Remove `org.eclipse.osgi.services` from `proxy.server` product
* Remove `org.eclipse.osgi.services` from
`org.eclipse.cdt.debug.application.product` product
* Move `org.eclipse.cdt.debug.application.product` from profile to
general part
Signed-off-by: Alexander Fedorov <alexander.fedorov@arsysop.ru>
[703] fix NPE when no build binaries on system PATH
- fixes NPE when new cmake project has been created while there are no
C/C++ build binaries on the PATH environment variable. The NPE has been
thrown when the children of the project should be fetched (e.g. in
project explorer view)
- fix NPE cause in ErrorBuildConfiguration
- fix unit test
fixes#703
The Launch Bar Launch Configuration, Build Settings tab allows the user
to customise the CMake Settings (CMake generator, extra arguments, build
command and clean command). But changing these settings did not affect
the CMake build. This is now fixed.
A "Use these settings" checkbox allows the user to choose settings from
the UI or use the operating system defaults.
Display the new more accurate error when all candidates were failed
instantiations. Otherwise, if there is a mix of failed instantiation and
wrong number of arguments, display the old message.
This could really be improved even more...
template<typename T>
void function() {}
Before:
function(); // Invalid arguments 'Candidates are:
After:
function(); // Cannot instantiate template function 'Candidates are:
### Changes
With this PR, `PreprocessorMacro` and its subclasses are no longer package-private but public instead. Same goes for `TokenList`.
### Reasons for the changes
When parsing C/C++ code with CDT as a standalone library I want to track certain macro expansions using the [MacroExpander](https://github.com/eclipse-cdt/cdt/blob/main/core/org.eclipse.cdt.core/parser/org/eclipse/cdt/internal/core/parser/scanner/MacroExpander.java).
It is not actually part of the public API but declared as `public`. It takes an argument `macroDictionary` of type `CharArrayMap<PreprocessorMacro>` in its constructor. Currently, `PreprocessorMacro` is package-privat and thus, not available without shadowing (i.e., implementing my custom macro tracker in the package `org.eclipse.cdt.internal.core.parser.scanner`).
It questionable whether it is a good design decision to have public and private API mixed together here (rendering the usage of the constructor of `MacroExpander` impossible).
Also, another problem occurs once you take the route of shadowing to have access to `PreprocessorMacro`: the CDT jars are all signed during release (makes sense) but, sadly speaking, that will result in a `SecurityException` when trying to call their API from your own (unsigned) code which lives in the shadowed package (in my case in `org.eclipse.cdt.internal.core.parser.scanner`).
### Problem solved
MacroExpander can now be used from the outside because `PreprocessorMacro` and `TokenList` are no longer package-private. Shadowing is no longer needed. Signed jars are no longer a problem.
