|
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.
[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?
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.
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.
Certainly...that's been my working assumption all along (e.g.
using/reusing ICommandLauncher).
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).
Scott
|
