Debug Launch Configuration - Allow use of ${project_name} in Project: field on Main tab

[smagee-as]

In Eclipse debug launch configurations, I'd like to use a variable like ${project_name} in the Project: field on the Main tab so I can reuse .launch files across projects without modification. Currently, this doesn't seem to be supported. I'm able to use ${project_name} in other fields of the debug configuration. But, if I replace the actual project name with ${project_name} in the Project: field, then I get the error:
Error while launching command: ${cross_prefix}gdb${cross_suffix} --version

I'm using the following versions:
Eclipse IDE Neon.3 Release (4.6.3) Build id: 20170314-1500
GNU MCU Eclipse plug-ins v4.3.1-201801092051
GNU MCU Eclipse Windows Build Tools v2.10-20180103
GCC Arm Embedded Tool Chain - GCC 7.0-2017-q4-major
Java Developer Kit - JDK 8u161
Segger J-Link Tools - JLINK V631b
Windows 10 Pro v1809 build 17763.379

[AntonKrug]

At first it was not making any sense, the value ${project_name} is feed from the Project Name field, so you can't be populating variable from itself. But then I realize the mechanics and meaning of the variables change. In the debug launcher it's feed from the variable Project Name, BUT in the external launchers the meaning change a bit, and the ${project_name} is different: "The name of the currently selected resource's project or of the project being built if the external tool is run as part of a build."

https://help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Fconcepts%2Fconcepts-exttools.htm

If we would be able to have a option to switch between the 2 different logic (or being able to populate the Project name field with ${project_name}). Then using this would allow more dynamic launchers and therefore you might end up needing less launchers satisfying more projects, have less mess and not have to worry as much about so many launchers.

If this is achievable on GME level (and not on the CDT) then I would like look at it (time permitting) as it sounds as a good feature.

[AntonKrug]

So it might be inherited in the TabMain.java and extending the CMainTab2 class, would it be ok to re-implement the CMainTab2 just with that different feature, or to add another ILaunchConfigurationTab tab to be able to affect it separately?

[ilg-ul]

next week I plan to make a new GME plug-ins release, and I'll take a look at this issue too.

[AntonKrug]

I was trying quickly slam the CMainTab2 functionality into your TabMain with small changes and now I can't even get it compiling. And even after I would change that tab, it would need to change the macro resolution functionality, so the feature might be more involved than it looks like on the surface, but it would be great addition, the Eclipse is clunky and sometimes bloated. This would reduce the bloat a bit. I will park it for time being, but do not hesitate to contact if you will figure out how it could be implemented and would need help writing it.

[smagee-as]

Thank you for considering this enhancement!

Taking a step back and looking at the top level, my coworker was mentioning that other IDEs let you choose the debugger for the project first, let's say J-Link, CMSIS-DAP, or ST-Link, etc. Then, you configure that debugger to allow debugging, download, erase functions.

For my projects, I create launch files for various debuggers so my customers have a choice. I currently have 3 launch files (debug, download, erase) for 3 debuggers for a total of 9 launch files. I configure download and erase under the run menu only. Ideally, once the debugger is chosen in the project, then you could just click the debug icon to debug, or click on a menu to select download or erase.

For now, I'm thinking about creating an external tool batch file that will let the user select a debugger, which will copy the chosen debugger launch files to the 3 commonly named launch files used by the project. For example if J-Link is chosen in the .bat it would copy jlink_debug.launch to debug.launch. And, jlink_download.launch copied to download.launch.

[AntonKrug]

You think within scope of single project. But for example if you have dozen projects with dozen launchers and only thing is changing the name of the project, then you could have one generic launchers which could cater all of them. And of course, like in your case this multiplies even more if you have more than 1 launcher per project.

[ilg-ul]

I'm trying to understand exactly what you mean, but I need more details.

First, external launchers are different from debug launchers, and the initial request was for an enhancement to the debug launchers.

Second, although project-less debug lanchers are possible, I remember there were some limitations, including avoiding the macros defined in the project configuration (like ${cross_prefix} that you mention); thus I generally would not recommend project-less debug launchers.

if I replace the actual project name with ${project_name} in the Project: field

I'm afraid this is not possible, that field is the link between the debug launcher and the project, where do you suggest to get the value of the macro if the project is not known?

[AntonKrug]

Yes it's for debug launchers, but what he is asking sounded to me that he wanted the behavior of the external launchers to be applied on the debug launcher. So the external launcher stay as they are, I just mentioned them because their logic is similar to what was asked originally.

The beauty of this approach would be that the original behavior would stay same, existing per project launchers would stay working. And who wants to take the risc (no pun intended :) ) could use it the new way.

It would figure out what project it is by checking what is the parent project of the currently selected resource in the project explorer. Then the user would have to be careful to have something selected for this approach to work. But it would allow users to do more verb/noun approach "I want to DEBUG this PROJECT" with just one debug launchers. When you do lot of projects and you port lot of stuff, the launchers get messy, hard to maintain, hard to transfer, it's finicky. While with this there is one rule to remember "have the project selected and be careful it will not get deselected or losing focus".

I think it's very possible, just I'm not sure about the feasibility, it offers something very interesting, but it's not that easy.

[smagee-as]

Yes, actually, all of my launchers are debug launchers. On the Common tab, you can select whether they are under Debug or Run. I put download and erase under Run. For download and erase, I have the launcher execute with command line arguments for OpenOCD so it does the operation and exits debug. For J-Link, it executes some commands in "Startup->Run/Restart Commands", one of those being to "quit" debug.

I didn't mention ${cross_prefix}, but I'm using that in my launchers successfully right now. I assume because the project name is hard coded.

Ideally, if I only have 1 project open, then it would recognize that and just debug that project, even without having to select it. But, if multiple projects are open, then like AntonKrug suggested, you would have to select one of the open projects in Project Explorer before clicking debug.

[AntonKrug]

With the ${cross_prefix} now it does that it goes to Project Name to figure out to which project it belongs, then it goes to that project to figure out what are the cross settings.

With the new approach the old approach would still work, but if the Project Name would contain macro, it would resolve the macro first depending on what is the currently selected resource into a project and then continue as the original approach.

The idea is not end up with one launcher to rule them all, but to significantly reduce them, so in the end you might end up with DEBUG_ARM and DEBUG_RISCV but you will not have dozens of RISC_Vs even when they are the same.

It would make the DEBUG/RUN approach much more feasible as well. Where there would be 2 launchers with only difference that the RUN wouldn't break in the main and ignore other breakpoints, which is similar to disabling breakpoints, disabling in the break in main in the launcher and debugging it. When you have to switch back and forth often it's annoying, creating so many launchers will make it very confusing when you will have few projects.

[ilg-ul]

let me see if I got it right: if the project name is not set, you suggest to use the parent project of the selected resource.

I don't know if this is realistic, the Project Explorer might not even be present in the perspective where you want to start the launcher, or it might be present, but not visible, with nothing selected, or with a wrong selection.

as far as I know, Eclipse generally does not favour linking functionality to the selected resource in this indirect way, you generally have to right click on the resource to access the available actions.

personally I'm not very confident that this is a good idea, apart from the weird situations when you push a button and it displays a message telling you to make the Project Explorer visible and select a project, you can easily mess one target by clicking the button while the wrong resource remained selected. not to mention that if targets require separate configurations, like device names, or different speed settings, the risk of messing things is even greater and debugging these cases is even more difficult.

but what puzzles me a bit is the use case, the need to create and maintain huge numbers of debug configurations, due to huge numbers of projects in the same workspace of the same Eclipse instance.

first, debug configurations should be created only once, when the project is created, preferably automatically by the project template, and stored as .launch xml files in the project; that's the reason of using macros in it, to avoid full paths and other non portable definitions; storing them in the project allows sharing them with other developers via the repository, without having to recreate them on each workspace.

second, only tightly related projects should be in the same workspace. for experimental/research environments probably people tend to put more projects in the same workspace, but for production environments ideally one project per workspace should be seriously considered.

even more, for really serious projects, a project not only should have its own workspace, but also its own Eclipse instance, to avoid messing projects when one project needs one version of Eclipse and another one does not (yes, upgrading Eclipse has the risk of making changes in the workspace, making it crash in an older version).

people tend to forget that Eclipse is actually a folder that can be placed anywhere in the filesystem, and there is nothing wrong with having as many Eclipses as necessary. (I probably have several tens, I lost count of them).

I know that some vendors do not agree with this (sorry Anton), and insist on providing multi-GB super tools with everything but the kitchen sink packed inside, tools that it is not reasonably (sometimes not even possible) to install in multple versions/instances, but GNU MCU Eclipse does not recommend this approach and is specially designed to favour multi Eclipses, multi toolchains, and generally modular approaches (for example via xPacks).

so: modularize your environment, use multiple workpaces, possibly multiple Eclipses (which will also allow you to start many in parallel), save debug launch configurations in your projects and probably things will not be as complicated as you present.

[AntonKrug]

If you do not have project view at all then you can still use the original way, this is option extra, not override of existing behavior. But if you would have only 1 project in the workspace like you propose then it should be possible to "guess" what project you have fairly accurately.

Multiple target boards would have own debug launchers but you would be able to switch between them faster than creating them for each project. In your ideal case when your template will create project to target board A and now you have to target board B and C, what will you do? Create new projects from templates for board B and C? And how easy it will be switch between them when your code is maybe developed and debugged on board A, but then tested and deployed on board B (when A might be more debug friendly variant of board B, but different enough that you need separate launcher).

"some vendors" actually have the Eclipse portable and you can have dozens of them installed, move them and run multiple instances of them. For example we wanted allow people to use one specific plugin and it was not portable, so we up-streamed a change to make it portable so others can benefit it from it as well. But that doesn't mean we force you to use it that way.

With this change there is the beauty to use as you using it now, no change and use your flow as you want (including having 1 project per eclipse), while allowing you to have multiple projects in same instance, in the same workspace if you prefer so. If Eclipse was not intending to be used that way, then they wouldn't never make the workspace mechanic in the first and would be more in style of VisualStudioCode. Having completely different instances for each project could make sharing of the projects bit more tricky, if each instance is meant to have different version of plugins and settings. Could xPacks orchestrate the eclipse installation, plugins installation and settings for all plugins you need for that project?