If I use the GUI to create a simics project, I can click an all the addons (OSS-Sources, QSP-x86, and so on) and the project's targets dir will contain these subdirs:
cosim qsp-x86 simics-builder-training simics-user-training vacuum workshop-01
If I run
$HOME/simics/simics-6.0.89/bin/project-setup simics-test2
the targets directory only contains
cosim vacuum
What flags do I need to pass to project-setup in order to install all addons?
Also, where can I get such information other than on stack overflow?
I tried reading project-setup -h and tried some of the flags there (e.g. --package-list $HOME/simics/simics-qsp-x86-6.0.44), but nothing worked.
Use the addon-manager in your project to create its own package-list.
cd simics-test2
./bin/addon-manager -C -s ~/simics/simics-qsp-x86-6.0.44
Having a .packagelist file in the installation of Simics Base would make all packages in that list global for that version of Simics Base. Which is not always what you want.
Having project-local .packagelist files gives you the neat option to select exactly which add-on packages you want with a particular version of Simics Base.
ISPM handle all of this for you quite seamlessly. But as Jakob mentioned, it does not add any "global" .packagelist file to the work flow.
Related
I have customized buildroot with the new board ( derived from raspberry pi zero ). So my changes are (in-tree):
.config
board/passkeeper/genimage-passkeeper.cfg
board/passkeeper/post-build.sh
board/passkeeper/post-image.sh
board/passkeeper/rootfs_overlay/etc/init.d/S41passkeeper
board/passkeeper/rootfs_overlay/etc/mdev.conf
board/passkeeper/rootfs_overlay/etc/udhcpd.conf
configs/passkeeper_defconfig
output/build/linux-custom/.config
Now, reading the documentation - I am a bit confused on how to put all these things into the separate folder via BR2_EXTERNAL. Also I'm not sure how do I move the linux configuration from output/build/linux-custom/.config
make linux-update-defconfig BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE=/tmp/passkeeper/linux/linux-config
results in
Unable to perform linux-update-defconfig when using a defconfig rule
Can somebody please provide step-by-step guide on that?
[You are asking two questions. I will answer only the question about saving the linux .config file; the other question is too generic.]
You need to set the appropriate options in menuconfig, not just override on the command line, otherwise they are inconsistent.
The process complete for creating a linux defconfig based on a pre-existing in-tree defconfig is the following. You have already done steps 1, 2 and 3.
In the Buildroot configuration, select BR2_LINUX_KERNEL_USE_DEFCONFIG or BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG.
Run make linux-menuconfig and adapt the linux configuration to your needs.
Build and test, iterate over 2 until you have the configuration you want.
In the Buildroot configuration, switch to BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG and set BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE to the place where you want to save it (typically board/passkeeper/linux.config or $(BR2_EXTERNAL_PASSKEEPER)/board/passkeeper/linux.config if you are using an external).
Run make linux-update-defconfig. It is essential you do this before doing anything else, otherwise Buildroot will complain that the file doesn't exist.
I am having an issue where a recipe i'm using no longer has the variable libdir defined. It appears to only have libdir_native.
This recipe i'm using is poco-1.7.5 for Morty from openembedded so I assume the recipe should work properly.
As a result of the missing libdir variable none of the installed files are being packaged which is screwing up my build.
In the short term i've been able to fix the problem by creating an append file which makes libdir = "${libdir_native} but this doesn't seem like it should be necessary.
The only thing I can think of is that the Bitbake.conf file is not being source properly by Bitbake (or the wrong .conf is being used).
Any suggestions would be appreciated.
Based on the comments this seems to be the problem: Poco upstream installs libraries into /usr/lib/ but the yocto packaging expects them to be in ${libdir} which may be different from /usr/lib/.
The most common reason (for cmake recipes) for this is that the upstream project does not support CMAKE_INSTALL_LIBDIR. Check if the upstream build system has some alternative means for specifying libdir -- this is surprisingly common with cmake projects. If not, you could add support for CMAKE_INSTALL_LIBDIR in the upstream build system (and add a patch to your recipe).
An alternative hack would be to add a do_install_append() that checks if ${libdir} is not /usr/lib/, and moves everything from ${D}/usr/lib/ to ${D}${libdir} in that case.
I need to use the hook feature of planner in postgresql 9.3 to perform a task. I am building postgresql from source.
To start with, I wanted to know how to create a hook and attach that shared libray to postgresql. Hence i tried the examples given in "wiki.postgresql.org/images/e/e3/Hooks_in_postgresql.pdf" and
"https://github.com/gleu/Hooks-in-PostgreSQL/tree/master/examples/my_client_auth".
I have copied the "my_client_auth.c" file and Makefile into contrib/client_auth folder. make and make install is working fine.
This is the output of make install.
/bin/mkdir -p '/home/rajmohan/projects/lib/postgresql'
/usr/bin/install -c -m 755 my_client_auth.so '/home/rajmohan/projects/lib/postgresql/'
after that i have added shared_preload_libraries = 'my_client_auth' to postgresql.conf.
When i rebuild and run the project and check client_auth_hook in postgresql code
client_auth_hook value is always zero. It seems my_client_auth.so file is not linked properly to my postgresql project.
Am i missing any step? how to access methods in my_client_auth.so from postgresql. Kindly help
Then i added the line ClientAuthentication_hook_type client_auth_hook = NULL; at the top of a file say planner.c
Why are you doing that?
If you want to use a hook from an extension, you must define a _PG_init function that sets the hook within the extension when it gets loaded at shared_preload_libraries time.
There is no need to modify the PostgreSQL source code its self. Only your extension. Take a look at the existing examples, like contrib/auth_delay in the PostgreSQL source tree, for how to do this correctly.
Your extension doesn't get "linked ... to the postgresql project" at compile/link time, either. It's a loadable module that PostgreSQL links to at runtime when you ask it to with create extension or by listing it in shared_preload_libraries. At that time it runs whatever code is in _PG_init, which is your opportunity to install hook functions etc.
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
We're setting up an OpenSolaris server on Amazon's EC2 service. However, vi/vim doesn't work properly, and pkg doesn't have nano/pico.
Is there any other text-editor maybe?
Sounds like you may just need to set an appropriate termtype to get vi working. Look into the "TERM" environment variable options, perhaps one of those will help you.
You may try copying the nano binaries (or compiling the source), to your user account and running it from there. It worked for me in a similar situation.
Have you looked at http://www.sunfreeware.com/?
SUN is working on the SUNWgnu-nano package to include this in the next release. In the meantime, you can compile the nano sources yourself. It worked for me. To compile, follow these steps:
Make sure you install SUNWgcc package so that gcc is installed.
Download the source package from the debian distribution.
http://packages.debian.org/source/stable/nano
Unzip the package with 'gunzip xxxx.tar.gz' where xxxx.tar.gz is the source package you downloaded.
Untar the package with 'tar -xf xxxx' where xxxx is the unzipped source package.
Go to the source folder. Do a './configure' to create the make file for your system.
Type 'make' to create the binary
The 'nano' binary should be located in the src subfolder. Copy this to '/usr/bin'. And create a soft link for 'pico' to it i.e. 'ln -s /usr/bin/nano pico'
Test it out!
1) Open the Package Manager (System > Administration > Package Manager)
2) Open the Repository settings (Settings > Manage Repositories)
3) Add the Blastwave repository (Name: blastwave, URL: http://blastwave.network.com:10000 )
4) Select the repository in the upper right corner
5) Search for the package 'IPSnano'
6) Select the pacakge
7) Press 'Install/Update'
8) Modify your path to include /opt/csw/bin
(For example $ vi ~/.profile and then add the line above to your path)
9) Logout and in again to reflect the changes
Check whether the correct version of nano is used:
$ which nano
It looks like both Nano and Pico are available as auto-generated packages in the "pending" repository here: http://pkg.opensolaris.org/pending/en/index.shtml. I think they are waiting for someone to follow the verification steps and vouch that they work. Then they can be moved to the contrib repository. You can read more here: http://opensolaris.org/os/community/sw-porters/.