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

Update Main Tab for Core Build local launch configurations. #940

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

ewaterlander
Copy link
Contributor

A new Main Tab was created for Core Build local projects based on the Main Tab used for the classic Managed Build projects. It adds these features:

  • Option to select a different binary.
  • Option to control launch pre-builds.

The default value for the binary is empty string. With empty string the behaviour for binary selection stays the same as it was.

The project name is fixed and cannot be changed. A Core Build launch configuration is created with the project and tied to it.

This change relates to #758. It affects all Core Build projects, including CMake projects.

@ewaterlander
Copy link
Contributor Author

ewaterlander commented Nov 18, 2024

A picture of the new main tab:

image

@ewaterlander
Copy link
Contributor Author

Hi @jonahgraham and @betamaxbandit , would you like to review this PR?

@betamaxbandit
Copy link
Contributor

Hi @ewaterlander ,
thanks for creating the change.

TBH, I'm not sure about this. Everything I've done recently in this area has gone away from having the main tab in the launch configuration delegate. However, I can see how it might be useful if you have projects that contain multiple binaries.

For projects that build a single binary, can you say what the usecase for this is please? After all, if there is only a single binary then it can be selected automatically.

Can you explain what you mean by "Option to control launch pre-builds.".

Cheers John

@ewaterlander
Copy link
Contributor Author

For projects that build a single binary, can you say what the usecase for this is please?

In our case a binary is built that doesn't run on the local system. The launch starts a local simulator. The simulator will load the binary and run it. So we put the path to simulator in the "C/C++ application" text field, and based on arguments in the Arguments tab the simulator knows what to load.

For plain single binary local programs you just leave the "C/C++ application" text field empty and it will be selected automatically.
And indeed it is helpful for multiple binaries, because currently the automatic selection will pick the first one found.

Can you explain what you mean by "Option to control launch pre-builds.".

You can disable the automatic build before launching, and only trigger a build by manually pushing the build button. This can save you time if you want to do multiple runs and you are only changing input data.

The classic local C/C++ launch configuration also has these features. I think it is good to keep these.

A new Main Tab was created for Core Build local projects based on the Main
Tab used for the classic Managed Build projects. It adds these
features:

* Option to select a different binary.
* Option to control launch pre-builds.

The default value for the binary is empty string. With empty string
the behaviour for binary selection stays the same as it was.

The project name is fixed and cannot be changed. A Core Build launch
configuration is created with the project and tied to it.

There is no option to select a build configuration, because for Core
Build projects this is selected via the LaunchBar's Launch Mode.

This change relates to eclipse-cdt#758. It affects all Core Build projects,
including CMake projects.
@ewaterlander
Copy link
Contributor Author

Update: Instead of adding a new class CoreBuildMainTab2 I updated old class CoreBuildMainTab.

@ewaterlander ewaterlander changed the title New Main Tab for Core Build local launch configurations. Update Main Tab for Core Build local launch configurations. Nov 21, 2024
@betamaxbandit
Copy link
Contributor

Hi @ewaterlander ,
thanks for the extra details.
For your use case I guess this makes sense.
I'll review the code, hopefully early next week. I need to check how/if this impacts the changes I've made in my client code.
Cheers John

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 this pull request may close these issues.

2 participants