Add existing make environment to eclipse - eclipse

I have a question about eclipse and make. I have created a make environment which acts as follow:
I have a batch file (Start.bat) which SET´s variables for further usage (e.g. SET TOOL_PATH = blabla).
After calling this I use my make.bat <option>, which calls the make.ext -f Makefile.mak <option> with the given option e.g. make.bat all -sj4. The environment variables which are set in Start.bat are very important for the running of the overall make environment.
This works very fine and now I would like to import this in eclipse but I am not familiar with eclipse. I need from eclipse that when I would like to run a make, first the Start.bat is called and then the make.bat <option> is called.
What I need to do?

You can import your project as 'existing make file project'
In the project settings you should be able to define pre-biuld steps and call the batch there or define a specific target (e.g. start) that calls the start batch and is executed before your 'make'.
I dont know exactly at the moment how to do this the best way, but I think you are fast into it.

Related

How do I run a project in eclipse with different jboss-ejb-client.properties

I have EJBs deployed on several different servers, for different environments. I have many projects that use these EJBs. I usually just run my projects against the DEV server EJBs, but sometimes I need to run against the TEST or PROD environment EJBs. This necessitates having to comment out all of the DEV nodes in my jboss-client-ejb.properties file and uncomment all of the TEST nodes. But then if I forget to change them back, I may mess up some data if I run it later. What I would like to do is create a different runtime configuration for each environment, and have each runtime config use a different version of the jboss-client-ejb.properties. Is there a way to do this? If so how? I have looked at all of properties of a run configuration, and don't see anything helpful.
In eclipse preferences search for string variable substitution. Here create variables that point to multiple config files for each of your environments. Then create multiple run configurations and for each one (like dev or prod) add a program argument that points to your string variable defined in your preferences like this -DmyconfigFile={$MyDevPropertiesFilePath}, or you could hard code the config path and have multiple runtime configurations that use different config files. Key point here is create multiple runtime launch configurations for each environment and add the properties for each environment that point to the config file respective to each environment. This way you can easily select the launch menu and decide to run "dev" "prod" or whatever you name your multiple configurations. Trying to do this with one runtime configuration will cause pain as you say, because it is easy to forget to revert or change the config file you want to to use. Hope that helps. Also if you create a new workspace you can export your runtime configurations using the export wizard which is also helpful for passing on to other developers or putting in source control.
P.S Looking more at your question you wan to pass in the config file path as a program argument, you are correct there are no specific options for setting this file path. Using program arguments with multiple launch configurations.

PyCharm - automatically set environment variables

I'm using virtualenv, virtualenvwrapper and PyCharm.
I have a postactivate script that runs an "export" command to apply the environment variables needed for each project, so when I run "workon X", the variables are ready for me.
However, when working with PyCharm I can't seem to get it to use those variables by running the postactivate file (in the "before launch" setting). I have to manually enter each environment variable in the Run/Debug configuration window.
Is there any way to automatically set environment variables within PyCharm? Or do I have to do this manually for every new project and variable change?
I was looking for a way to do this today and stumbled across another variation of the same question (linked below) and left my solution there although it seems to be useful for this question as well. They're handling loading the environment variables in the code itself.
Given that this is mainly a problem while in development, I prefer this approach:
Open a terminal
Assuming virtualenvwrapper is being used, activate the virtualenv of the project which will cause the hooks to run and set the environment variables (assuming you're setting them in, say, the postactivate hook)
Launch PyCharm from this command line.
Pycharm will then have access to the environment variables. Likely because of something having to do with the PyCharm process being a child of the shell.
https://stackoverflow.com/a/30374246/4924748
I have same problem.
Trying to maintain environment variables through UI is a tedious job.
It seems pycharm only load env variables through bash_profile once when it startup.
After that, any export or trying to run a before job to change bash_profile is useless
wondering when will pycharm team improve this
In my case, my workaround for remote interpreter works better than local,
since I can modify /etc/environment and reboot the vm
for local interpreter, the best solution I can do are these:
1. Create a template Run/Debug config template and clone it
If your env variables are stable, this is a simple solution for creating diff config with same env variables without re-typing them.
create the template config, enter the env variables you need.
clone them
see picture
2. Change your script
Maybe add some code by using os.environ[] = value at your main script
but I don't want to do this, it change my product code and might be accidentally committed
Hope someone could give better answer, I've been spent too much time on this issue...
Another hack solution, but a straightforward one that, for my purposes, suffices. Note that while this is particular to Ubuntu (and presumably Mint) linux, there might be something of use for Mac as well.
What I do is add a line to the launch script (pycharm.sh) that sources the needed environment variables (in my case I was running into problems w/ cx_Oracle in Pycharm that weren't otherwise affecting scripts run at command line). If you keep environment variables in a file called, for example, .env_local that's in your home directory, you can add the following line to pycharm.sh:
. $HOME/.env_local
Two important things to note here with respect to why I specifically use '.' (rather than 'source') and why I use '$HOME' rather than '~', which in bash are effectively interchangeable. 1) I noticed that pycharm.sh uses the #!/bin/sh, and I realized that in Ubuntu, sh now points to dash (rather than bash). 2) dash, as it turns out, doesn't have the source "builtin", nor will ~ resolve to your home dir.
I also realize that every time I upgrade PyCharm, I'll have to modify the pycharm.sh file, so this isn't ideal. Still beats having to manage the run configurations! Hope it helps.
OK, I found better workaround!
1.install fabric in your virtualenv
go to terminal and
1. workon your virtualenv name
2. pip install fabric
2. add fabric.py
add a python file and named it "fabric.py" under your project root, past the code below,and change the path variables to your own
from fabric.api import *
import os
path_to_your_export_script = '/Users/freddyTan/workspace/test.sh'
# here is where you put your virtualenvwrapper environment export script
# could be .bash_profile or .bashrc depend on how you setup your vertualenvwrapper
path_to_your_bash_file = '/Users/freddyTan/.bash_profile'
def run_python(py_path, virtualenv_path):
# get virtualenv folder, parent of bin
virtualenv_path = os.path.dirname(virtualenv_path)
# get virtualenv name
virtualenv_name = os.path.basename(virtualenv_path)
with hide('running'), settings(warn_only=True):
with prefix('source %s' % path_to_your_export_script):
with prefix('source %s' % path_to_your_bash_file):
with prefix('workon %s' % virtualenv_name):
local('python %s' % py_path)
3. add a external tool
go to
preference-> External tools -> click add button
and fill in following info
Name: whatever
Group: whatever
Program: "path to your virtualenv, should be under '$HOME/.virtualenvs' by default"/bin/fab
Parameter: run_python:py_path=$FilePath$,virtualenv_path=$PyInterpreterDirectory$
Working directory: $ProjectFileDir$
screenshot
wolla, run it
go to your main.py, right click, find the external name (ex. "whatever"), and click it
you could also add shortcut for this external tool
screenshot
drawbacks
this only work on python 2.x, because fabric don't support python 3

Set Environment Variable At Eclipse workspace level for all launchers?

Can I set a workspace wide setting to add an environment variable to all future launchers created in the workspace?
Use Case
Our unit tests require an environment variable to guide the test to certain resources.
the variable varies with each version of our product
Options
- modify each junit launcher with the environment variable
- create start up script that sets variable and launches eclipse
- set globally
Ideally, I'd like to provide a way for users to set it once per workspace.
Does eclipse have a place to set an environment variable for all launchers?
Thanks
Peter
Only option which I can think of is similar to yours where you can create multiple shell scripts(linux) or batch files(windows) and set it up there. for ex -
I am giving examples for windows environment and same can be done for Linux as well -
for windows-
eclipse.exe -DvariableName1=value1 -DvariableName2=value2
As you want to pass different variables to different workspaces, you can also pass location of your workspace as part of arguments.
eclipse.exe -data <your_workspace_location> -DvariableName1=value1 -DvariableName2=value2
You can create multiple shortcuts of eclipse.exe in windows and place them on Desktop (for quick access) if needed. Each shortcut may point to a similar variant of above command with different workspace and different variables.
Hope this helps. Happy coding :)
I have a different approach for doing this on windows. This solution allows you to store a large number of environment variables to one place and apply them globally inside eclipse.
I have gitBash installed already, and associated in windows to execute .bash files
I set up a /c/Temp/.env file with lots of environment variables in the format
export VARIABLE=my value
I create an eclipse_startup.bash script that looks like this (and pin it to my start menu).
echo setting up env
. /c/Temp/.env
echo starting eclipse
/c/Users/me/eclipse-oxygen/eclipse/eclipse.exe
It has the disadvantage that I end up with a bash window open with eclipse, and I have to restart after changing the environment. On the plus side, my complex application has lengthy environment files already, so I can simply load them in and start.

PyDev Unit Test Set Run Directory

I have a PyDev unit test module that lives at the path:
$(PYDEV_PROJECT_ROOT)/tests/my_unit_test.py
I am attempting to use Eclipse PyDev's unit testing facilities. My unit test must read a configuration file like so:
(foo,bar,baz) = myModule.readOptimizationConfig("tests/optimization_config_file.cfg")
However, this will not work because PyDev goes into the 'tests' directory before running, and so specifying 'tests/' in the path given to readOptimizationConfig makes it attempt to load
$(PYDEV_PROJECT_ROOT)/tests/tests/optimization_config_file.cfg
However, I also need to run these tests using nosetests from the command lin.
This is because, in order to run ALL the tests for my project, rather than the option for running them in a particular file that is provided by default, the easiest solution was to just use the 'nosetests' command, rather than messing with Eclipse launch configurations. However, nosetests needs to be be run from the $(PYDEV_PROJECT_ROOT) root directory, so it needs the 'tests/' specified in the path.
Is there a way to force eclipse to run the unit tests from the project root directory, so that the paths that I pass to readOptimizationConfig will work for both methods?
It is possible to do this in PyDev, but you have to do it per every launch configuration so it's a bit boring.
Anyway, you first try to run as your script containing the unit-test (as you normally would - e.g. the dropdown menu next to the green "Run" arrow button then Run as... - Python unit-test). This launch will fail because of your missing cfg file. Now go to Run configurations (Run dropdown - Run configurations), open the Arguments tab and in the bottom under Working directory enter the path you want (or browse for it using the Workspace... button). For example if you want to run from project root and your project is called awesome-project, you would write:
${workspace_loc:awesome-project}
Now you should have a valid launch configuration that you can use from both the Run and Debug menus. I sometimes rename these configurations to something noticeable right away e.g. "awesome-project TEST".

run pydev project from file-system (with imports from different packages)

I want to run my working pydev project python code by double clicking the main module (outside of eclipse): xxx.py
The problem is that due to my imports being in different packages:
from src.apackage.amodule import obj
when xxx.py is double clicked it complains it doesn't know where the imports are (even though when I run xxx.py in pydev it magically knows what I'm importing).
A simple workaround is to remove all of the packages and move all of the modules into one directory (that obviously works but is very inconvenient)
How can I run my code in the file system without doing that work around?
This page answers my question excellently:
http://blog.habnab.it/blog/2013/07/21/python-packages-and-you/
Bottom line is always execute your code from the top, highest level, root directory (e.g. using a minimal main.py file that executes the main script of your program). Then, use absolute imports always and you never have a missing module issue since you start the program from the top directory and all imports are based off that 'home' path.
The problem you encountered is the natural behavior of most languages. A programm only knows about its working path (the path it is started in), the paths which are registered in the environment variables and at least relative paths.
The "magic" of the executable you created is therefore: It collects all scripts/modules needed, and copies/combines them next to/in the executable. The Executable then runs within the directory where all other scripts also reside and voila ...
If you are not happy with your workaround of creating an executable every time you want to run your project without PyDev there are two alternatives.
First but not the one I would suggest is registering the working path into in the environment variables.
Second and the one I think is much better: Create a link to the python executable and alter the calling string of the textfield "Target:". Append the path to your script you would like to run. Then alter the textfield "Start in:" and enter the project directory. After you did this you should be able to start your project with a simple double click.
(If you rely on external libraries which are neither on the path nor in you project you could search for appending paths temporarily to the pythonpath via the sys module.)
I hope I could help a bit.