Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Unable to install local build of CDT master
I don't see a big difference between building and requiring when talking about target platform. If you build against a specific platform, only that version or newer can be required safely, otherwise we end up with runtime failures where things go wrong. I do agree that requiring latest (pre-release) platform can be a problem sometime, especially with regressions in the platform. That said, if we don't catch the regressions in the platform before it is released, then we end up in a worse situation.

Perhaps I am being too pedantic, and we should just loosen up the bundle requirements. As long as the code paths requiring newer platform aren't hit, the user will be fine.

As an interesting coincidence, EASE are having a very similar conversation today on their dev list.

Jonah

~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Mon, 15 Jul 2019 at 22:46, Marc-Andre Laperle <malaperle@xxxxxxxxx> wrote:
I think it’s OK to build against the newest platform using the target definition. *Requiring* the latest platform through the required plugins versions is a bit more tricky. Some of us run daily on CDT master and upgrading platforms frequently is much more risky than just upgrading CDT, at least historically. I used to run on platform integration builds and I did spend a significant amount of time working around severe regressions, filling/fixing bugs and downgrading. Perhaps every milestone will be manageable, I’m not opposed to trying that, just wanted to give another perspective.

Marc-André

On Jul 15, 2019, at 5:15 PM, Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:

Hi Doug,

I am using latest (nightly) of LSP4E and LSP4E builds against latest platform I-build too, so to safely consume LSP4E, we need to also build and run only against latest platform. I don't know if there is any feature in 4.13 that is being used yet, other than a small cleanup I did - and could roll back if needed. However, doing that would mean that we also change LSP4E (and all other projects we depend on) to be versions built against that same version of the platform too, which would imply having a different target platform for newer code than for the existing codebase. 

Jonah
~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Mon, 15 Jul 2019 at 16:29, Doug Schaefer <cdtdoug@xxxxxxxxx> wrote:
Is there something in 4.13 we or LSP4E are using?

On Mon, Jul 15, 2019 at 4:04 PM Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:
On Mon, 15 Jul 2019 at 15:10, Nathan Ridge <zeratul976@xxxxxxxxxxx> wrote:
> How do I install that? I downloaded a .tar.gz from there, but it's not recognized as
> either "Archive" or "Local" in Install new Software -> Add Repository.

Ok, I figured it out: it's not meant to be installed into an existing installation, it's a new installation altogether, without CDT, into which I can then install CDT for the first time.

I'm glad you got it. Let me know if there is anything else I can do to help. 

Another question: is there a technical reason for us to depend on such a recent platform? Have we actually, in the few weeks since CDT's 2019-06 release, introduced uses of platform APIs that were not present in Platform 2019-06?

Short answer, yes.

I believe we decided as a community to track CDT against latest platform earlier this year. The result of this is that I regularly bump the target file to track latest platform builds so that by release time everything is lined up nicely. Going forward this requirement is needed because we depend on latest version of, for example, LSP4E and that also tracks latest platform. Once we are building with a version of the platform, we cannot run on older versions. In other words, we must prevent being installed in any older version of platform than we built against. This latter part comes down to some subtle Java issues which means even if CDT's source code has not changed, the dependent project's changes can cause our binary code to be different, and that difference means we can't run in older versions of the dependency. See Bug 536448 for an example of what happened before we added this restriction, and gerrit for what I do in practice to resolve issue.

I am happy to revisit the original decision as getting the balance right is very tricky. For example, it may even make sense to have different target platforms for "core"ish parts of CDT than for newer parts of CDT.

I hope that answers the question,
Jonah
 
Thanks,
Nate
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev

Back to the top