Re: [cdt-dev] Usage of ContainerCommandLauncherFactory(2)::verifyInclude

[Moritz Strübe <moritz.struebe@xxxxxxxxxx>]

Hey Jeff,

thanks for the answer.


Am 02.11.2020 um 21:28 schrieb Jeff Johnston:
> There are 3 interfaces: ICommandLauncherFactory, 
> ICommandLauncherFactory2, and ICommandLauncherFactory3 that have been 
> added over time to
> support Docker Containers and ultimately Flatpak.

Out of curiosity: Why wasn't ICommandLauncherFactory extended, but new 
interfaces introduced?


> Note, that for Containers, the system headers don't change without the 
> Image changing.  Thus, in most cases, a single copy is needed
> per include path.  There is logic to recognize if the Image has 
> updated or changed and the cache may be cleared.

Yep. I'm currently preparing a MR for linux-tools. I'm still a bit 
scared of adding the rm-functionalty if the container-id changes, but I 
hope to get there this week.  ;)

>  There is also a UI page
> where a user can delete the cached headers for an image and thus force 
> a recopy if they have some complicated scenario where they
> are changing the headers manually via a shell session.

Ok. Where is that? This stuff needs more documentation or maybe the 
documentation should be placed more visible. :-) I'm planning to do some 
once I got all the features I need implemented.

> When the new CBuild model was added, the old methods for 
> ICommandLauncherFactory do not get called in the build sequence.  Thus,
> ICommandLauncherFactory2 was added to deal with CBuild projects and 
> the verifyIncludePaths() was added that does both copying and 
> massaging in a
> single call.  Again, we are supporting Containers so the image headers 
> are expected to be static.

Ok, but verifyIncludePaths is only called by providers, not when the 
project is loaded, right?
Background: As long as I don't touch my workspace, everything is fine. 
Yet if delete the .../HEADERS/ folder to trigger copying the files, 
things break.


> For Flatpak, the scenario changed yet again.  Initially CDT wasn't 
> working properly with Flatpak as it only had a subset of tools/headers 
> installed. I modified Flatpak CDT so
> it uses local tools and local headers, leaving it up to the end-user 
> as is done for regular CDT.  The local headers are copied
> into a cache that the flatpak can access in the sandbox much like we 
> do for Docker Images.  If the headers change, the user may have to do 
> a manual remove of the headers
> and allow the system to recopy as needed.  A new interface: 
> IContainerCommandLauncherFactory3 was added which adds the 
> checkIfIncludesChanged()
> method to see if header files have been removed since the last copy.  
> The Flatpak change is very recent and hasn't been thoroughly 
> tested/exercised in the wild.  There
> was a bug in Flatpak which didn't allow a Docker Connection to work 
> (can't access the unix socket) and I haven't looked at Flatpak CDT 
> since I reported that issue as Mat
> was on vacation at the time and Flatpak wasn't being updated.

So, if I implement checkIfIncludesChanged (checking whether the 
docker-image still has the same ID and all necessary include folders are 
available) and return false, this should trigger verifyIncludePaths?

Cheers
Morty

--
MATHEMA Software GmbH
Schillerstraße 14 | 90409 Nürnberg

Telefon: +49 (0)911 180778-50
E-Mail: moritz.struebe@xxxxxxxxxx | Web: www.mathema.de

Geschäftsführer: Andreas Hanke, Thomas Haug
Handelsregister: HR B 35517, Nürnberg/Bayern