Unable to build Eclipse-CDT sources of released builds

[mmx85]

Describe the bug
Cannot build tagged sources of released builds after some time from the moment when Eclipse-CDT release has happened.

To Reproduce
Steps to reproduce the behavior:

1. Clone eclipse-cdt/cdt repo
2. Switch say to cdt_11_2 tag or earlier
3. Build the sources

Expected behavior
Build succeeds.

Actual result
Build fails due to unexisting links for dependent repos (say of Eclipse nightly builds) or references to the latest sources of dependent repos instead of their tagged snapshots that now differ from the ones the were on the moment when the Eclipse-CDT sources were tagged.

[jonahgraham]

We need to build our release builds (e.g. tagged versions such as CDT_11_2_0) against non-released dependencies as all the projects release simultaneously each quarter.

If we decide to do x.x.1 releases of CDT then we do fixup the target platform to work with the released versions of the dependencies, e.g. since we did a CDT 11.1.1 release the target platform was updated in f9eef68 on the cdt_11_1 branch.

The work described above gets scheduled as part of an endgame Steps to prepare, build and release CDT checklist, e.g. for CDT 11.1.1 which has a step that starts Update cdt.target to point to new dependency versions

• CDT 11.1.1 #332

If someone (e.g. you) wants to do the work to maintain older branches in the open source that would be great. I am also happy to help support the community in this area if and when needed. However for now I don't plan to do any work on this.

[mmx85]

If everything releases concurrently and is tagged also concurrently then it is indeed hard to implement in automatic way since build system may not have this data in advance. However, this information is very useful if you need to debug and modify the released sources. So, it is good to add this information say into the release notes or some other document after release happens or duiring the release. In this case you'll not have to guess which versions of dependencies to take to debug released plug-ins. I'm talking now about the repos on which plug-ins depend directly, not about all libraries involved into the build process that are taken from say Maven Central. This is redundant information. сб, 19 серп. 2023, 20:42 користувач Jonah Graham ***@***.***> пише:

…

We need to build our release builds (e.g. tagged versions such as CDT_11_2_0 <https://github.com/eclipse-cdt/cdt/tree/CDT_11_2_0>) against non-released dependencies as all the projects release simultaneously each quarter. If we decide to do x.x.1 releases of CDT then we do fixup the target platform to work with the released versions of the dependencies, e.g. since we did a CDT 11.1.1 release the target platform was updated in f9eef68 <f9eef68> on the cdt_11_1 <https://github.com/eclipse-cdt/cdt/commits/cdt_11_1> branch. The work described above gets scheduled as part of an endgame <https://github.com/eclipse-cdt/cdt/labels/endgame> checklist, e.g. for CDT 11.1.1 which has a step that starts Update cdt.target to point to new dependency versions - #332 <#332> If someone (e.g. you) wants to do the work to maintain older branches in the open source that would be great. I am also happy to help support the community in this area if and when needed. However for now I don't plan to do any work on this. — Reply to this email directly, view it on GitHub <#521 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEGARLV6FXN3SP6ZSJGYFD3XWD3JZANCNFSM6AAAAAA3WNJYRM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[jonahgraham]

Best thing would be to update the target file on the branch after all dependent projects have released. I am more than happy to review PRs that do that, and I will continue making such PRs when a maintenance release is made. Note in the endgame to do lists I mentioned that going forward on branches it may be easiest to just mark the SimRel p2 repo as the target platform.

[jonahgraham]

PS if you are trying to debug a released build of Eclipse plugins there are a bunch of smarts built into Eclipse to import bundles, including source and even the tag of the backing git repo into your workspace. Every eclipse bundle should have the sha of the commit it was built from and the p2 site of the release should have the source bundles. If you find cases where that isn't present that is a bug that should be submitted to the respective project.

[jonahgraham]

Thank you @mmx85 for your insights and fixes already. I look forward to working more with you in the coming months!

[jonahgraham]

@mmx85 if you are interested in maintaining the CDT 11.3 branch that the release was just posted from now is a good time to update cdt.target. I have done a basic pass that should make the branch build today, but as dependent projects have updated snapshots that may change. Have a look at #549 and please consider providing your own PR to either supplement or replace mine.