Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Usage of ContainerCommandLauncherFactory(2)::verifyIncludePaths and ..::verifyLanguageSettingEntries

Hi Morty,

There are 3 interfaces: ICommandLauncherFactory, ICommandLauncherFactory2, and ICommandLauncherFactory3 that have been added over time to
support Docker Containers and ultimately Flatpak.

ICommandLaunchFactory was added to support header files when building ManagedBuilder projects that build in Docker Containers.
There is a method that registers the header files/paths needed (which ultimately calls registerLanguageSettingEntries() which ends up copying
headers if needed) and one that massages the language settings so any needed headers point to the cached location (verifyLanguageSettingEntries()).

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.  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.

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.

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.

Regards,

-- Jeff J.



On Mon, Nov 2, 2020 at 3:13 AM Moritz Strübe <moritz.struebe@xxxxxxxxxx> wrote:
Hey,

working with the Docker-Container-Support I have some trouble
implementing ContainerCommandLauncherFactory2::verifyIncludePaths and
ContainerCommandLauncherFactory2::verifyLanguageSettingEntries. The
Documentation of the two is:

verifyLanguageSettingEntries:
Verify language setting entries for a project and change any entries
that have been copied to a local location

verifyIncludePaths:
Process include paths and if necessary copy header files as needed.

However if I open a project only verifyLanguageSettingEntries is called,
which states: "[..] change [..] entries that _have been_ copied". The
problem is, that it might be necessary to update the local files as they
might have changed remotely. I had a quick glance at the
FlatpakCommandLauncherFactory, and that just copies the files in both
functions. Thus:
1) Is the documentation wrong and both functions should copy files?
2) Is there an bug higher up and verifyLanguageSettingEntries should be
called when loading a project?
3) Is there something I didn't understand and this should be solved
differently?

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

Back to the top