From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Scott Lewis
Sent: Tuesday, October 17, 2017 12:30 PM
To: cdt-dev@xxxxxxxxxxx
Subject: Re: [cdt-dev] Core Build/CMake update
Hi Doug,
On 10/17/2017 7:37 AM, Doug Schaefer wrote:
<stuff deleted>
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.
Ok that makes sense. To check my assumptions: you would expect that a) IToolChain might expose a few more public methods (as few as possible, obviously); b) GCCToolchain (e.g.) would be extended to implement those methods for a non-local (e.g. Docker) support.
c) *Perhaps* the CBuildConfiguration would need to be extended as well...I'm not sure about that, but I would like to find a way that doesn't require the CBuildConfiguration to be extended to support build and launch remoting.
[Doug3] At the moment, it’s only the addition of getCommandLauncher, no? At least let’s start with that. I don’t think we need to change CBuildConfiguration if you add the default method to the interface.
Create a subclass of GCCToolChain for Docker and go from there. If we see common stuff there we can push it to the superclasses later.
[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 wasn't sure whether the few number of toolchains (2) was an artifact of core build being relatively new. Sounds like you think it is not...i.e. that it is likely to stay that way (relatively few IToolChain impls). Is that right?
[Doug3] Market forces have driven compiler vendors to be GCC compatible. Clang really proved that to me. Even Intel’s compiler is compatible from what I remember. If there’s more than 2 there’s not much
more than 2.
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(2n) isn’t that bad when n = 2
😊.
True. But it grows pretty fast if n grows.
[Doug3] And if it’s does, it’s actually 2n. One per each.
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.
Well...to start, how about remote building and running over Yocto docker containers? :). I get your point though...and that's why I believe ICommandLauncher is the right one (in core already, implemented
Docker, can/could be implemented by others that are not Docker).
[Doug3] Agreed, which is why that’s the only interface change I agree with for now.
Scott
