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?
Adding a new method to a public interface would have required a major release bump. Adding a new interface can be done in
a minor release.
>
> 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.
See org.eclipse.cdt.internal.flatpak.launcher.ui.preferences.FlatpakHeaderPreferencePage.java
>
> 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.
The checkIfIncludesChanged call is expecting that you removed the headers via the UI instead of
manually (i.e. looking at a remove list). It can be modified to check for the folders being manually removed as well.
>
> 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?
Other way round. If you return true, then needRefresh will be set to true in
CBuildConfiguration.startBuildProcess() and the headers should be refreshed when processing
the build output as the scanner info will be refreshed. If there is a scenario where indexing is needed without a build, then additional
logic may be needed elsewhere.
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
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
