On Mittwoch, 9. Dezember 2020 00:29:42 CET Liviu Ionescu wrote:
> > On 9 Dec 2020, at 00:56, Martin Weber <fifteenknots505@xxxxxxxxx> wrote:
> >
> > Well, after 7 year of driving through CDT code base: It depends on being a
> > masochist or not :-)
>
> Actually the question was different: is CDT without MBS, at this moment,
> able to support something functional? In other words, if I start a new
> build plug-in based on CDT without MBS, can I get multiple build
> configurations and a functional indexer, or I have to patch/rewrite half of
IIRC, CDT currently has three build systems:
- Makefile project: Users have to maintain their buildscripts. Users have to
teach the indexer about include paths and macros.
- MBS aka Managed (Makefile) Build System: CDT generates the build-scripts for
users. CDT itself provides buildscript-generation for the 'make' build tool
only. Tries to teach the indexer about include paths and macros by parsing
build output (focused on gcc). Users may additonally to teach the indexer
about include paths and macros.
- The thing called 'core build'. Its javadoc is poor, and there are no concept
papers explaining what it is supposed to do and the author is no longer with
us. Tries to teach the indexer about include paths and macros by parsing
build output (focused on gcc). Provides no mean for users to teach the
indexer.
The design of Core Build was essentially being done from the ground up. IIRC, Doug's
intention was to simplify build and remove all the fluff that MBS caused and wasn't being
maintained any more. So, Doug came up with basic functionality and asked
for developers to exercise the model and suggest additions where functionality was missing.
I added Container support to correspond to the MBS Container support I added in the past. I also
added Meson support and some CMake changes such as using cmake -LAH to build the options
page dynamically based on the container.
A user of Core Build projects is expected to use the launch bar to select the
configuration. A user can select to run or debug and with the
Container support, can choose to build/run/debug in a Container. In addition, profiling is also
supported via the Profiling Tools menu. A user can choose to build/run/debug the same project in multiple
containers, same as under MBS. Each configuration has a separate build directory.
The indexer needs to know the build commands to figure out the include files and macros required
as these need to be copied to the host for the indexer to correctly index the code (e.g. container may have completely
different version/set of tools/headers). Thus, knowledge of the toolchain used is required in addition to the build commands used so
that knowing how a resource is built and with what options, the command can be used to figure out what macros and header paths are implied.
The build system cannot be treated as a black box for indexing to work properly. It would be possible to add additional properties tabs
to support manual specification of include paths and macros, but some paths/macros are specific to compiling a particular file so it would
get complex to force a user to supply all of this info. There is support in CMake and Meson Core Build projects to look at compile-commands.json.
The current Core Build container support is gcc-based and would require modifications to support clang, but it should
be doable, even if the model needs to be altered, but that would be part of the on-going Core Build evolution. For example,
ContainerGCCToolChain could be made to look for a project property to switch between gcc and clang
or be replaced with a more generic version that defers to tool-specific versions as necessary. Some additional work would probably be
needed for things such as error parsers.
