Re: [cdt-dev] Managed Core Build

[Liviu Ionescu <ilg@xxxxxxxxxx>]

On 29 March 2018 at 19:02:02, William Riley (william.riley@xxxxxxxxxxx) wrote:

> then any custom build system plugin could implement its own
> method instead of parsing the build output. If you have any thoughts
> on this area please share.

personally I would not even consider parsing the build output.

for example, by default, the xmake build does not even output the
actual commands; it is possible to make the xmake output more verbose,
to diagnose possible problems, but usually the output is much shorter.

On 29 March 2018 at 19:09:05, Doug Schaefer (dschaefer@xxxxxxxxxxxxxx) wrote:

> to future proof, we should start looking at generating compile_commands.json
> files for all our build systems.

agree.

yes, the compile_commands.json specs were originated by the clang people.

    https://clang.llvm.org/docs/JSONCompilationDatabase.html


my understanding of a generic build system (with CMake matching this
model, and xmake too), is that it runs in 2 steps:

- generate the build configuration files (for example make or ninja)
- run the actual build

a generic Eclipse build plugin should allow to configure the separate
commands used by these two steps.

for the indexer, in addition to generating the make/ninja files, the
first step should also leave a compile_commands.json file in the build
root.

after running the first step, the Eclipse build plugin should read
this file, update the indexer configuration, and finally update the
index.

CMake seems able to leave this file. my xmake build system will easily
generate this JSON file too.

On 29 March 2018 at 19:00:59, Doug Schaefer (dschaefer@xxxxxxxxxxxxxx) wrote:

> multiple configurations per project automatic configuration
> selection based on toolchain could still be added, though I think
> it would need some form of mapping UI as users could have more than
> 1 applicable configuration.

I would say that these are different issues.

from my perspective, the above mechanism to run custom builds and
update the indexer is the first priority, and can be immediately
useful, for CMake. however the mechanism is generic enough to be
implemented outside the CMake plugin, actually making the CMake use
case a specific case of the more generic one. xmake would also benefit
from it.

separately we can think of a generic way to configure toolchains/tools
from the GUI, and implement a replacement for the current managed
build. xmake/xpacks use several JSONs in the project hierarchy, which,
when brought together, define the list of source folders, the include
folders, the symbols and the compile options. xmake actually
identifies these files and does exactly what the current managed build
does, generating the make files.

to integrate xmake into Eclipse, I would use some generic objects
available in a future managed build plug-in and edit the xmake
specific JSON files.


regards,

Liviu