Re: [cdt-dev] Core Build/CMake update

[Jesper Eskilson <Jesper.Eskilson@xxxxxxx>]

We're in the middle of making a somewhat painful transition into the Linux domain, so I guess we will sooner or later have to deal with the question about how to handle people wanting to build/debug inside e.g. docker containers, but I haven't given that much thought yet.

About Core Build: I'm finding (as with our DSF integration years back) that being fundamentally different from the gcc/gdb-dominated world of open source, we need to roll our own solutions to many things. Core Build fits us nicely, since it allows us to leverage our own tools to do the building instead of the MBS mess, but I'm a little worried that there are assumptions being made that aren't valid in our situation, especially in the light of the current gcc/gdb-domination.

One particular thing I'm thinking about is how build configurations are created and managed. In a Core Build project which delegates everything to an external tool (think .vcxproj file built by msbuild.exe), the set of configurations is completely controlled by what's in the vcxproj file, and I would expect it to be possible to have a UI somewhere to allow the user to select which configuration to build. As far as I can tell, the current UI for selecting build configurations is tightly bound to MBS, but maybe there are plans to change that?

/Jesper​

Jesper Eskilson Development Engineer
IAR Systems AB

---

From: cdt-dev-bounces@xxxxxxxxxxx <cdt-dev-bounces@xxxxxxxxxxx> on behalf of Doug Schaefer <dschaefer@xxxxxxxxxxxxxx>
Sent: Wednesday, October 18, 2017 9:54 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Core Build/CMake update

 

Your mileage does vary :). And of course as one that does, what are your thoughts on how you would want to support your toolchain in remote build scenarios?

Sent from my BlackBerry - the most secure mobile device - via the Rogers Network

From: Jesper.Eskilson@xxxxxxx

Sent: October 18, 2017 2:02 AM

To: cdt-dev@xxxxxxxxxxx

Reply-to: cdt-dev@xxxxxxxxxxx

Subject: Re: [cdt-dev] Core Build/CMake update

I guess you aren't considering IAR as a "major toolchain". :D

/Jesper

Jesper Eskilson Development Engineer
IAR Systems AB

---

From: cdt-dev-bounces@xxxxxxxxxxx <cdt-dev-bounces@xxxxxxxxxxx> on behalf of Doug Schaefer <dschaefer@xxxxxxxxxxxxxx>
Sent: Tuesday, October 17, 2017 4:37 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Core Build/CMake update

 

 

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Scott Lewis
Sent: Monday, October 16, 2017 9:20 PM
To: cdt-dev@xxxxxxxxxxx
Subject: Re: [cdt-dev] Core Build/CMake update

 

Howdy,

On 10/16/2017 5:15 PM, Doug Schaefer wrote:

<stuff deleted>

    
[Doug] The launch target is where the built application will run. If it’s going to run in the Docker container, then yes, the target should be some sort of target that represents the Docker container. That also implies you’d have launch configurations and delegates that know how to launch the binary in the docker container.

Are launch configs and delegates required then?   (for example:  no 'build but not run in docker container').   Or would it possible to have build in one container and launch in another?

 

[Doug2] So, yes, this is the three way (often called Canadian cross, even though Canada now has 5 major parties, but anyway…). We talked about this a few weeks ago. I think in this case the toolchain would manage where it builds separate from the launch target which would manage where the built app runs. I will have UI to edit properties on toolchains when things are done so this could work.

 

[Doug2] BTW, this is the scenario embedded developers would care about. The launch target would be a development board with the toolchain and SDKs in Docker (including gdb BTW so we’ll need to figure that out too).

 

Question 3:   WRT the ILaunchTarget and it's possible relationship to (e.g.) ICommandLauncher and impls (like DockerContainerCommandLauncher).    Would you expect that the IToolChainManager.getToolChainsMatching(targetProperties) would some how return both 'remoted' toolchains as well as 'local' toolchains (hidden behind IToolChainManager service), or would the IToolChain that it returned be somehow used in ICBuildConfigurationManager.getBuildConfiguration(project, toolChain, mode, monitor) call to get/return a build configuration that is 'remote enabled'?   Would the latter break the managed builder (?).   So the question is:   Where do you see hooking into ICommandLauncher?...or some other way to get a remote-enabled ICBuildConfiguration.build?

[Doug] I would expect the Docker launch target to have a property that specifies it as a Docker launch. I would then expect toolchains that support building in docker to have the same property so that only they “match”.

What I don't understand about this is how to handle the following case:   Some tooling/plugin developer creates a local toolchain and releases it.  Someone *else* comes along and would like to create a command launcher that can works for that toolchain, ideally without modifying the original toolchain code or setting up new properties required to match.

 

[Doug2] A couple of points. First, since things like scannerInfo gathering is different with Docker, you can’t get away from the IToolChain implementation needing to know about Docker. But that should be doable by subclassing and overriding only a couple of methods.

 

[Doug2] Second point that hit me while doing this. There actually aren’t that many toolchains out there. In fact, I think the GCCToolChain covers 99% of the cases we’ll run into. The only other major one would be MSVC. All other toolchains I’ve run into (and your mileage may vary) are compatible with GCC, including Clang.

 

I would then expect all toolchains to return a command launcher and the build configurations’ build and clean methods would use that instead of the current ProcessBuilder. The default would be to return the local command launcher, docker toolchains would return your docker one. Other than that, the CDT Core never needs to know about remoting. So goes the theory…

Ok, sounds good.   Are you thinking that IToolChain interface would get a new method:   ICommandLauncher getCommandLauncher() to implement what you describe above...or some other mechanism?

 

[Doug2] Yes with the default implementation in the interface retuning the local launcher.

 

 

[Doug] Note also, the docker toolchains would know the magic incantation to get the header files copied over and their implementations of getScannerInfo would do the right thing. I assume that the container ids and such would also be properties on the docker target and can get passed onto the toolchain so that it sets up the docker command launcher to point at it, assuming that’s how that works. I’m not totally sure we have a way to pass that info from the target to the toolchain. Work might be needed there.

The part about this that currently confuses me is avoiding having to rewrite a toolchain impl in order to use an ICommandLauncher (whether local or remote).   I think it could be difficult if for every toolchain it had to be reimplemented/rewritten/redeployed to support each new kind of ICommandLauncher (e.g. docker container).

[Doug2] Again, there are only 2. O(2ⁿ) isn’t that bad when n = 2 😊. That and I want to keep the interfaces tight. Unless building in Docker becomes the norm, I’d like to make sure we keep the magic out of the core and keep interface changes for it to a minimum. And I want to make sure whatever we do in the core for Docker can be used generally for other remote build scenarios. i.e. you’d win me over is you show how a change would also help remote building over ssh, or Windows Subsystem for Linux, as examples.

Thanks,

Scott