Variable usage in launch configurations
Status: Beta
Brought to you by:
mballance
Requested in 1.9.5.
In our files.f's SVE will first look in the Project's Linked Resources, then it will look in the system's environemtn variables.
Is it possible to have launch configurations do the same thing?
This allows me to have 2 nearly identical projects loaded simultaneously, and use the same launch configuration for both projects. Areas that could use variables are:
I realize that an easy work around is to uniquely name the launch configs, but this can get tedious and names can get long.
Hmm... I think I'm missing something about what you're envisioning. It
seems you're thinking about somehow associating a launch configuration with
a project, which would then trigger then launch to look at the project's
configured variables. What are your thoughts about how this association
should be specified by the user?
On Tue, Feb 14, 2017 at 2:19 PM, StevenAZ stevenaz@users.sf.net wrote:
Related
Feature Requests: #123
Good points Matt,
A bit more about the scenario. Given 2 pieces of IP that I could be working on, with both projects loaded into the workspace. The "compile & run" environment when working on these projects would presumeably be the same if the company I work at has any sort of flow in place.
Let's say that the commands to compile the rtl & testbench are: "cd sim ; vlog -work work -log logname.log -f files.f"
I'd like to create a launch configuration that cat's logname.log. In this case the log location would reside in ${project_loc}/sim/logname.log for both projects.
Today I create 2 near idetical launch configs, with the IP name pre-pended to the launch config name. This results in a run configuration name that is pretty wordy, with very slight differences between them (different working directories). Scripting the generation of the launch configs is trivial and I've already done this for my projects. I just end up with lots of near duplicate launch configs.
As to how to identify which set of variables to use. About the only thing I can think of is that it uses the variable set from the project that the current file is from.
I don't believe that this is a massively high priority. The current flow isn't broken by any means. It might be best to let it fester for a while, see if we get more requests for the feature, or additoinal feedback that might take this in a different direction.
I was browsing around and came across this. The environment variable section of this is basically what I would want ideally.
http://help.eclipse.org/neon/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Ftasks%2Ftasks-java-local-configuration.htm