| Re: [cdt-dev] Unable to install latest nightly build: org.eclipse.launchbar.core 2.0.0 could not be found |
From: <cdt-dev-bounces@xxxxxxxxxxx> on behalf of Sergey Prigogin <eclipse.sprigogin@xxxxxxxxx>
Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Date: Monday, November 30, 2015 at 1:23 AM
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Subject: Re: [cdt-dev] Unable to install latest nightly build: org.eclipse.launchbar.core 2.0.0 could not be found
On Sun, Nov 29, 2015 at 7:10 PM, Doug Schaefer <dschaefer@xxxxxxx> wrote:
I think they are both fundamental. You have heard of Build for Launch, no?
In case of build for launch the is no dependency of the build subsystem on run/debug. Instead run/debug depends on the build subsystem. By introducing a dependency that is going the other way you are breaking this design and getting dangerously close to creating circular references between build and run/debug subsystems.
Except that it doesn’t create a circular dependency. Feel free to look at the code on master where the Qt plug-ins are now using the new build system. I’m pretty happy with how it turned out and how easy it is to switch between building and launching on my local machine and my QNX board.
Having the toolchains know about the launch targets they build for has been a huge advantage in the new build system workflows. It’ll even be more interesting when the toolchains tell debug what debugger to use for a given launch target.
Launch targets is not the only thing that can be built. Consider for a example a shared library, which cannot be launched but can be built. The notion of build in Eclipse is even more flexible and supports code generation and other things.
Yes you build shared libraries, but usually you intend to run them somewhere. The idea is to base what you build on where you intend to run them. I’m still working on the mechanism for that. But likely I’d check the project dependencies and look for the most likely target you’re going to run the library on in the future. Or the user could pick the toolchain manually. We’ll see what provides the best workflow.
Once I get the concept of Launch Target into the Platform post Neon, this conversation wouldn’t be necessary anyway. But, for now, it’s in the launch bar core plug-in.
This is not acceptable. Lauch bar is ugly, violates Eclipse UI guidelines and is shown by default if the corresponding plugins are installed. I understand that you need a place to put interfaces that are used by both, build and launch, but the launchbar plugin is not a right place for them. To preserve the principles of the existing Platform design, these new interfaces have to go into core.resources or another plugin associated with build, not run/debug. If you are concerned with putting immature API into the platform, you can probably avoid that by putting the new interfaces into privately exported packages until they mature.
I appreciate your opinion. And you’re not alone. But you’re also in a pretty small minority. I’ve had a huge amount of praise for the Launch Bar and the simplification of workflows it provides. We can play with the look and feel. But I find Eclipse’s tool bar buttons useless so don’t want to make the launch bar equally useless. And, if you have a pointer to the Eclipse UI guidelines that it’s violating that would be helpful. I’ve yet to find such a document written in the last decade at least. I can easily make the claim that the current Eclipse UI is hurting us competitively with more "modern looking” IDEs.
But that’s independent of the launch target issue. My intention is to move the launch target classes to the debug.core plug-in. If there was a launch plug-in, I’d move it there since it’s not related to debug anyway, other than debug is a mode supported by the launch system. These classes are actually below the launch bar proper in architecture today ready to be pushed down once I get it up to Platform standards. Again, feel free to take a look at the code.
Not sure what you mean by the target platform definition. The launch bar is in there. Builds are working fine for CDT 9/Neon.
I was seeing compilation errors until I installed Launch Bar. This shouldn't be required since the target platform definition is supposed to take care of that.
You do have this in your cdt-e4.6.target file no?
<location includeAllPlatforms="false" includeConfigurePhase="false" includeMode="planner" includeSource="true" type="InstallableUnit">
<unit id="org.eclipse.launchbar.feature.group" version="0.0.0"/>
<repository location="https://hudson.eclipse.org/cdt/job/launchbar-master/lastSuccessfulBuild/artifact/repo/target/repository/"/>
</location>
Doug.
-sergey
From: <cdt-dev-bounces@xxxxxxxxxxx> on behalf of Sergey Prigogin <eclipse.sprigogin@xxxxxxxxx>
Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Date: Sunday, November 29, 2015 at 8:19 PM
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Subject: Re: [cdt-dev] Unable to install latest nightly build: org.eclipse.launchbar.core 2.0.0 could not be found
It doesn't make sense that build.core depends on launchbar. Build is more fundamental than launchbar and should not depend on it. If the dependency were legitimate, it would have to be reflected in the target platform definition.
-sergey
On Sun, Nov 29, 2015 at 9:37 AM, Doug Schaefer <dschaefer@xxxxxxx> wrote:
We no longer support CDT master on Mars. It requires API changes that are
in the Neon version of the launch bar. The CDT target file has the list of
all the dependencies you need and where to get them. You could probably
install the Neon launch bar into Mars but I haven¹t tried that and have no
intention to do so.
You get get the Neon launch bar by pointing p2 here:
https://hudson.eclipse.org/cdt/job/launchbar-master/lastSuccessfulBuild/art
ifact/repo/target/repository/
This will all get cleaned up by Neon M4 when we get this into the simrel
repo.
HTH,
Doug.
On 2015-11-29, 3:02 AM, "cdt-dev-bounces@xxxxxxxxxxx on behalf of Nathan
Ridge" <cdt-dev-bounces@xxxxxxxxxxx on behalf of zeratul976@xxxxxxxxxxx>
wrote:
>Hi,
>
>A user reported [1] being unable to install the latest nightly build into
>a Mars.1 installation. I just tried doing the same thing, and ran into
>the same error.
>
>Steps:
> 1. Start with a clean installation of Mars.1 with CDT.
> 2. In 'Install new software', add the nightly update site
>(http://download.eclipse.org/tools/cdt/builds/master/nightly/)
> 3. Select 'CDT Main Features' and press 'Next'
>
>I get the following error:
>
>Cannot complete the install because one or more required items could not
>be found.
> Software being installed: C/C++ Development Tools 8.8.0.201511281104
>(org.eclipse.cdt.feature.group 8.8.0.201511281104)
> Missing requirement: GCC support for CDT Build Core 1.0.0.201511281104
>(org.eclipse.cdt.build.gcc.core 1.0.0.201511281104) requires 'bundle
>org.eclipse.launchbar.core 2.0.0' but it could not be found
> Cannot satisfy dependency:
> From: C/C++ Development Tools 8.8.0.201511281104
>(org.eclipse.cdt.feature.group 8.8.0.201511281104)
> To: org.eclipse.cdt.gnu.build.feature.group [8.8.0.201511281104]
> Cannot satisfy dependency:
> From: C/C++ GNU Toolchain Build Support 8.8.0.201511281104
>(org.eclipse.cdt.gnu.build.feature.group 8.8.0.201511281104)
> To: org.eclipse.cdt.build.gcc.core [1.0.0.201511281104]
>
>In another thread [2] I reported getting the same error when trying to
>install a CDT I built myself. I had assumed that was a mistake in how I
>built it, but since the same error is happening when trying to install a
>nightly, it looks like that's not the case.
>
>Are we (the user in question, and myself) doing something wrong in how we
>are trying to install a nightly build? Or are the nightly builds broken?
>
>Thanks,
>Nate
>
>[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=479888#c10
>[2] https://dev.eclipse.org/mhonarc/lists/cdt-dev/msg29871.html
>
>_______________________________________________
>cdt-dev mailing list
>cdt-dev@xxxxxxxxxxx
>To change your delivery options, retrieve your password, or unsubscribe
>from this list, visit
>https://dev.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://dev.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://dev.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://dev.eclipse.org/mailman/listinfo/cdt-dev