Community
Participate
Working Groups
Build Identifier: 3.6.1 I'd like to create log files relative to the project to which the launch config belongs. When I put "${project_loc}/run.log" in the field "File" (Launch Config -> Common -> "Standard Input and Output", I get this error: [Invalid file specified for console output: ${project_loc}/run.log] It seems that the variable expansion code doesn't allow everything that I can select in the UI. Reproducible: Always
The resource variables resolve to the selected resource in the Workbench. Resolving relative to the project in which the launch configuration is in is not currently supported. Please re-open if i misunderstood.
Thanks Pawel. A couple of questions: a) Why is the variable offered when it doesn't work? Are there other variables in the dialog that you can't and/or shouldn't use? b) Why isn't there a variable that resolves as "project to which the launch config belongs"? c) What's stopping you from using ${project_loc} to implement b)? I don't expect the current selection to influence the launch config. If such a behavior isn't documented, I'd argue it to be intuitive to resolve the conflict like this.
(In reply to comment #2) > Thanks Pawel. A couple of questions: > > a) Why is the variable offered when it doesn't work? Are there other variables > in the dialog that you can't and/or shouldn't use? The project_loc variable works in the way it was intended: for the resource selected in the active window context: give the file system location of the resource's project. > b) Why isn't there a variable that resolves as "project to which the launch > config belongs"? No one requested or volunteered to implement it. > c) What's stopping you from using ${project_loc} to implement b)? I don't > expect the current selection to influence the launch config. If such a behavior > isn't documented, I'd argue it to be intuitive to resolve the conflict like > this. For your use case, the project_loc variable is not relevant. What you need is something like "lc_project_loc". If you could contribute such a variable and we can commit it to the platform. Or you can implement such a variable in your own plugin and use it in your product without our help.
(In reply to comment #3) > (In reply to comment #2) > > Thanks Pawel. A couple of questions: > > > > a) Why is the variable offered when it doesn't work? Are there other variables > > in the dialog that you can't and/or shouldn't use? > > The project_loc variable works in the way it was intended: for the resource > selected in the active window context: give the file system location of the > resource's project. The docs say: "The absolute path on the system's hard drive to the currently selected resource's project *or* to the project being built if the external tool is run as part of a build. " So if there is no selection (and when I don't specify a resource as parameter to the variable), it should resolve the the project being built. That means the variable behaves differently when a I have an external tool launch config and an internal launch config (run+debug). Therefore, it would make much more sense to use it in a similar way in a launch config instead of creating another variable which shows up in a different place in the variable list - that will only lead to confusion. People will use "project_loc" because the name makes sense. No one understands what "lc_" is supposed to mean.
(In reply to comment #4) > Therefore, it would make much more sense to use it in a similar way in a launch > config instead of creating another variable which shows up in a different place > in the variable list - that will only lead to confusion. People will use > "project_loc" because the name makes sense. No one understands what "lc_" is > supposed to mean. There may be users out there with launches that depend on the existing behavior of this variable, so we can't change it even if it's not ideal. My variable name was just a suggestion... not necessarily a perfect one.
> > Therefore, it would make much more sense to use it in a similar way in a launch > > config instead of creating another variable which shows up in a different place > > in the variable list - that will only lead to confusion. People will use > > "project_loc" because the name makes sense. No one understands what "lc_" is > > supposed to mean. > > There may be users out there with launches that depend on the existing behavior > of this variable, so we can't change it I'm confused. How can there be existing users if the variable doesn't work in this case? Sounds like you're omitting some vital information which is completely obvious to you.
(In reply to comment #6) > I'm confused. How can there be existing users if the variable doesn't work in > this case? > > Sounds like you're omitting some vital information which is completely obvious > to you. Oops, sorry I missed your last comment. It's funny I feel the same way about your comments :-) I'm actually not all that familiar with this feature: I didn't implement it and I don't use it so I'm merely trying to coordinate community's effort to maintain it. You're more likely much more of an expert on it than I. Variable has an existing behavior in that it resolves to the project of the currently active resource. The active resource is the resource associated with the current window active context. This behavior works in builds, I verified that. As you pointed out in comment #4, the exception to this is in the context of the build. So, how do you propose we extend this existing behavior to support your use case but in a way that people who depend on it currently are not affected?
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the stalebug whiteboard tag.
