Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Future Standalone debugger (cdtdebug.sh) - remove it/other ideas? #781

Closed
jonahgraham opened this issue May 10, 2024 · 5 comments · Fixed by #782
Closed

Future Standalone debugger (cdtdebug.sh) - remove it/other ideas? #781

jonahgraham opened this issue May 10, 2024 · 5 comments · Fixed by #782
Milestone

Comments

@jonahgraham
Copy link
Member

The Standalone debugger has not worked in installed EPP builds for a while. This is because the way standalone debugger is built requires that the set of bundles available during CDT build matches exactly what is installed in the final product. There keep being problems with that (see recent details in #591 and its referenced PRs)

@jonahgraham
Copy link
Member Author

@ruspl-afed made a simplification to the build process in #761 that in the short term may have broken the standalone debugger, but long term may lead to a better solution:

The install script can't find the config.ini because the generator step was removed: If I run the install script I get this:

$ bash ./install.sh
cp: cannot stat './config.ini': No such file or directory
Installation complete

The cdtdebug.sh starts properly, but with the missing config.ini, the loaded UI doesn't prompt for executable and much of the simplification of the UI is missing (i.e. there is too much stuff present)

image

However forcing the application back in the command line -application org.eclipse.cdt.debug.application.app does get roughly the correct result:

This:

image

Followed by:

image

which has the mostly simplified menu. The startup time is longer as all features are enabled:

image

But that may be better than leaving things broken or removing the standalone debugger entirely.

@ruspl-afed
Copy link
Member

TBH I was not aware of cdtdebug.sh at all, I did a regular maven build locally and then launched an eclipse application extracted from %cdt_sources_home%\debug\org.eclipse.cdt.debug.application.product\target\products\org.eclipse.cdt.debug.application.product\cdt-stand-alone-debugger-11.6.0-20240419-1619-win32.win32.x86_64.zip

Are you sure that all these scripts are really required @jonahgraham ?

@jonahgraham
Copy link
Member Author

TBH I was not aware of cdtdebug.sh at all, I did a regular maven build locally and then launched an eclipse application

That is good to know, thanks for confirming - the "manual" for the debugger is https://github.com/eclipse-cdt/cdt/blob/main/StandaloneDebugger.md which is linked from the release pages such as https://github.com/eclipse-cdt/cdt/releases/tag/CDT_11_5_0

%cdt_sources_home%\debug\org.eclipse.cdt.debug.application.product\target\products\org.eclipse.cdt.debug.application.product\cdt-stand-alone-debugger-11.6.0-20240419-1619-win32.win32.x86_64.zip

That zip isn't published anywhere (it used to be a long time ago). That zip is basically how distros build the package they include.

Are you sure that all these scripts are really required @jonahgraham ?

The scripts provide three benefits:

  • User doesn't need to pass special command line arguments to normal eclipse.
  • Help is produced instantly (cdtdebug.sh --help) and some command line checking is done
  • And finally consistency with how it has been before, i.e cdtdebug.sh continues to be the entry point

Before the config.ini generation was removed in #761 the script also passed the command line arguments that meant the reduced config was used. As the command line is getting simplified now, users can certainly just run eclipse -application org.eclipse.cdt.debug.application.app

@ruspl-afed
Copy link
Member

In this case please accept my apologies for breaking it. Perhaps we can restore it using something simple, like maven-exec

@jonahgraham
Copy link
Member Author

No worries - the breakage was with no real effect since the generated config.ini often didn't work anyway. I'm preparing an alternative solution now.

jonahgraham added a commit to jonahgraham/cdt that referenced this issue May 12, 2024
The maintenance of having a streamlined standalone debugger that
starts as fast as possible is no longer possible. See for
example eclipse-cdt#591 - therefore when using standalone debugger, use
the same sets of plug-ins/features as the product it is installed
in uses. The side effect is that the standalone debugger in this
use case will start slower and extra "stuff" will be present in
this UI.

For people just building the standalone debugger, provide a minimum
feature set. This will be many more bundles than before, but
should still provide a reasonably small set that starts well.

This simplification also includes removing the the duplicates set
of CDT docs (debug/org.eclipse.cdt.debug.application.doc). These
provided a simplified version of CDT's documentation targetted
at just standalone debugger. However there are a few problems related
to this duplication:

- The two sets of docs were not kept in sync
- The standalone docs appear in the online help, leading to
  duplicated entries
- With the config.ini changes above, there is no way to exclude
  the main docs in the standalone case, so remove the duplicate

A number of directly related clean-ups are included too:

- Remove the `ConfigGenerator.java` that stopped being referenced
  in PR eclipse-cdt#761
- Complete the removal of `build-standalone-debugger-rcp` profile
  that was started in eclipse-cdt#761. There is a small drawback to not having
  this profile, the standalone debugger is very slow to build
  compared to the rest of CDT. If this becomes a problem, restoring
  this profile along with the changes made in eclipse-cdt#761 is reasonable.

Fixes eclipse-cdt#781

- bring debug.product's licenses up to date
- modernize command line args to eclipse when using debug.product
jonahgraham added a commit to jonahgraham/cdt that referenced this issue May 12, 2024
The maintenance of having a streamlined standalone debugger that
starts as fast as possible is no longer possible. See for
example eclipse-cdt#591 - therefore when using standalone debugger, use
the same sets of plug-ins/features as the product it is installed
in uses. The side effect is that the standalone debugger in this
use case will start slower and extra "stuff" will be present in
this UI.

For people just building the standalone debugger, provide a minimum
feature set. This will be many more bundles than before, but
should still provide a reasonably small set that starts well.

This simplification also includes removing the the duplicates set
of CDT docs (debug/org.eclipse.cdt.debug.application.doc). These
provided a simplified version of CDT's documentation targetted
at just standalone debugger. However there are a few problems related
to this duplication:

- The two sets of docs were not kept in sync
- The standalone docs appear in the online help, leading to
  duplicated entries
- With the config.ini changes above, there is no way to exclude
  the main docs in the standalone case, so remove the duplicate

A number of directly related clean-ups are included too:

- Remove the `ConfigGenerator.java` that stopped being referenced
  in PR eclipse-cdt#761
- Complete the removal of `build-standalone-debugger-rcp` profile
  that was started in eclipse-cdt#761. There is a small drawback to not having
  this profile, the standalone debugger is very slow to build
  compared to the rest of CDT. If this becomes a problem, restoring
  this profile along with the changes made in eclipse-cdt#761 is reasonable.
- bring debug.product's licenses up to date
- modernize command line args to eclipse when using debug.product

Fixes eclipse-cdt#781
jonahgraham added a commit to jonahgraham/cdt that referenced this issue May 12, 2024
The maintenance of having a streamlined standalone debugger that
starts as fast as possible is no longer possible. See for
example eclipse-cdt#591 - therefore when using standalone debugger, use
the same sets of plug-ins/features as the product it is installed
in uses. The side effect is that the standalone debugger in this
use case will start slower and extra "stuff" will be present in
this UI.

For people just building the standalone debugger, provide a minimum
feature set. This will be many more bundles than before, but
should still provide a reasonably small set that starts well.

This simplification also includes removing the the duplicates set
of CDT docs (debug/org.eclipse.cdt.debug.application.doc). These
provided a simplified version of CDT's documentation targetted
at just standalone debugger. However there are a few problems related
to this duplication:

- The two sets of docs were not kept in sync
- The standalone docs appear in the online help, leading to
  duplicated entries
- With the config.ini changes above, there is no way to exclude
  the main docs in the standalone case, so remove the duplicate

A number of directly related clean-ups are included too:

- Remove the `ConfigGenerator.java` that stopped being referenced
  in PR eclipse-cdt#761
- Complete the removal of `build-standalone-debugger-rcp` profile
  that was started in eclipse-cdt#761. There is a small drawback to not having
  this profile, the standalone debugger is very slow to build
  compared to the rest of CDT. If this becomes a problem, restoring
  this profile along with the changes made in eclipse-cdt#761 is reasonable.
- bring debug.product's licenses up to date
- modernize command line args to eclipse when using debug.product

Fixes eclipse-cdt#781
@jonahgraham jonahgraham added this to the 11.6.0 milestone May 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants