Background:
I recently joined a software development company as an intern and am getting used to a new build system. The software is for an embedded system, and lets just say that all building and compiling is done on a buildbox. The building makes use of code generation using xml files, and then makes use of make files, spec files, and version files as well.
We develop on our own comps, (linux - mandriva distro) and build using the following methods:
ssh buildserver
use mount to mount drive on personal computer to the buildserver
set the environment using . ./set_env (may not be exactly that)
cd app_dir/obj (where makefile is)
make spec_clean
make spec_all
make clean
make
The Question:
I am a newbie to Code::Blocks and linux and was wondering how to set up a project file so that it can simply run a script file to execute these commands, instead of actually invoking the build process on my actual computer. Sort of like a pre-build script. I want to pair the execution of this script simply to Ctrl-F9 (build) and capture any output from the above commands in the build log window.
In other words, there is no build configuration or target that the project needs to worry about. I don't even need a compiler installed on my computer! I wish to set this up so that I can have the full features of an IDE.
Appreciate any suggestions!
put your script in a shell script file. E.g.,
#!/bin/sh
mount ... /mnt/path/buildserver
. ./set_env
cd app_dir/obj
make spec_clean
make spec_all
make clean
make
Say you name it as /path/to/my_build_script, then chmod 755 /path/to/my_build_script and invoke the following from your ssh client machine:
script -c ssh buildserver "path/to/my_build_script"
When finish, then check for the file typescript under current directory.
HTH
Related
Is there a way to rebuild boot.scr script without cleaning entire project?
I removed old boot.scr script and don't know how to genegrate new one (only make clean helps)
Variable BR2_PACKAGE_HOST_UBOOT_TOOLS_BOOT_SCRIPT_SOURCE is set.
make uboot-dirclean uboot-tools-dirclean didn't help.
I found that the mkimage script that creates boot.scr is called from the uboot-tools install rule, but even if I clear uboot-tools boot.scr no longer generates
The accepted answer is correct, but there is easier way. The boot.scr is compiled by host-uboot-tools, not uboot-tools, thus you just need to execute this:
make host-uboot-tools-rebuild
If you dirclean host-uboot-tools it will rebuild your script. The reason is that mkimage (which generates the script) is called in the HOST_UBOOT_TOOLS_INSTALL_CMDS function in the uboot-tools.mk file.
As your personal script is in your external buildroot directory and you will probably want to iterate writing and testing it quickly you will want to make it every time. There is a way to do this each time you run make. No cleaning of anything is required. The post image script is the key.
For example, create your post-image.sh script and specify it in your defconfig file.
BR2_ROOTFS_POST_IMAGE_SCRIPT="$(BR2_EXTERNAL)/board/RK3308/post-image.sh"
In that post-iamge.sh script, run the command to generate your boot script, here is an example :
# Generate the uboot script
$ubootName/tools/mkimage -C none -A arm -T script -d $BR2_EXTERNAL_RK3308_PATH/board/RK3308/boot.cmd $BINARIES_DIR/boot.scr
Each time you run make, the boot.scr will be regenerated.
If you want to see all of this in context, here is an external buildroot repo for the rk3308 chipset.
This is the post-image.sh file.
This is the definition of that file in the defonconfig file.
U-Boot provides the tool mkimage. In Debian based distributions it is in package u-boot-tools. Given that you have a file boot.txt with your script commands you can create boot.scr with
mkimage -T script -n 'My fancy title' -d boot.txt boot.scr
Steps:
Installed coverity
Configured compiler
cov-configure --javascript
cov-configure --cs
I am stuck at the build step of cov-build. Yarn is used to run and configure the service. But I am not sure what coverity wants here.
I tried a couple of npm run commands, every time end up getting this:
[WARNING] No files were emitted. This may be due to a problem with your configuration
or because no files were actually compiled by your build command.
Please make sure you have configured the compilers actually used in the compilation.
I also tried different compilers, but no luck.
What should be done in this case?
You need to do a file system capture for Javascript files. You can accomplish this by running cov-build with the --no-command flag.
cov-build --dir CoverityIntermedediateDir --no-command --fs-capture-list list.txt
Lets break down these commands:
--dir: intermediate directory to store the emitted results (used for cov-analyze later).
--no-command: Do not run a build command and to look for certain file types
--fs-capture-list: Use the file that is provided to specify which files to look at and possibly emit to the intermediate directory.
A recommended way to generate the list.txt file is to grab it from your source control. If using git run:
git ls-files > list.txt
I want to also point out that if you don't have a convenient way to get a file listing in order to use the --fs-capture-list command you can use --fs-capture-search command and pair that with a filter to exclude the node_modules directory.
The coverity forums have some useful questions and answers:
Node.js File system capture
Really, the best place to look is at the documentation. There are several examples of what you want to do in their guides.
I have a Yocto build for i.mx6 and I want to modify its Kernel. I figured that if I copy Kernel source outside the Yocto project and make my modifications without dealing with patches, I can speed things up significantly. But the thing is, the Kernel source I have to use is already patched and I want to fetch and continue working from there. I will work on the already-patched source files and re-arranging them is a painful process.
For starting point, my patches work fine, and I can get a working image using bitbake fsl-image-multimedia-full command. The Kernel source I want to use is created after this process.
I have tried copying the source under ..../tmp/work-shared/imx6qsabresd/kernel-source. Although make zImage and make modules finished without any trouble, manual building was not successful with an error in a dtsi file (Unable to parse...). Of course, I have checked the file and there was no syntax error.
Also, I checked the kernel source files I copied and it seems that the patches are successfully implemented.
Am I doing something wrong with the patches? With my manual build routine, I can build unpatched kernel source with no errors. I am sure that there are experienced Yocto users here that have their own workarounds to make this process shorter. So, any help is appreciated. Thanks in advance.
You can also edit files in tmp/work-shared/<machine>/kernel-source then compile modified kernel with bitbake -C compile virtual/kernel
My favorite method of doing kernel development in a Yocto project is to create an SDK and build the kernel outside of the Yocto system. This allows more rapid builds because make will only build new changes, whereas a kernel build within Yocto always starts from scratch.
Here are some of my notes on compiling the Linux kernel outside of the Yocto system. The exact paths for this will depend on your exact configuration and software versions. In your case, IMAGE_NAME=fsl-image-multimedia-full
Run bitbake -c populate_sdk ${IMAGE_NAME}. You will get a
self-extracting and self-installing shell script.
Run the shell script (for me it was
tmp/deploy/sdk/${NAME}-glibc-i686-${IMAGE_NAME}-cortexa9hf-neon-toolchain-1.0.0.sh),
and agree to the default SDK location (for me it was
usr/local/oecore-i686).
Source the scripts generated by the install script. I use the
following helper script to load the SDK so I don't have to keep
track of the paths involved. You need to source this in each time
you want to use the SDK.
enable_sdk.sh:
#!/bin/bash
if [[ "$0" = "$BASH_SOURCE" ]]
then
echo "Error: you must source this script."
exit 1
fi
source /usr/local/oecore-i686/environment-setup-corei7-32-${NAME}-linux
source /usr/local/oecore-i686/environment-setup-cortexa9hf-neon-${NAME}-linux-gnueabi
Copy the defconfig file from your Yocto directory to your kernel
directory (checked out somewhere outside of the Yocto tree) as
.config.
Run make oldconfig in your kernel directory so that the Linux
kernel build system picks up the existing .config.
Note: you may have to answer questions about config options that
are not set in the .config file.
Note: running make menuconfig will fail when the SDK is enabled,
because the SDK does not have the ncurses libraries set up
correctly. For this command, run it in a new terminal that has not
enabled the SDK so that it uses the local ncurses-dev packages you
have installed.
Run make -jN to build the kernel.
To run the new kernel, copy the zImage and ${NAME}.dtb files to
your NFS/TFTP share or boot device. I use another script to speed
up the process.
update_kernel.sh:
#!/bin/bash
set -x
sudo cp /path-to-linux-source/arch/arm/boot/dts/${NAME}.dtb /srv/nfs/${DEVICE}/boot/
sudo cp /path-to-linux-source/arch/arm/boot/zImage /srv/nfs/${DEVICE}/boot/
set +x
You can also point Yocto to your local Linux repo in your .bb
file. This is useful for making sure your kernel changes still
build correctly within Yocto.
SRC_URI = "git:///path-to-linux-source/.git/;branch=${KBRANCH};protocol=file"
UPDATE: Over a year later, I realize that I completely missed the question about broken patches. Without more information, I can't be sure what went wrong copying the kernel source from Yocto to an external build. I'd suggest opening a Bitbake devshell for the kernel and doing a diff with the external directory after manually applying patches to see what went wrong, or just copy the source from inside the devshell to your external directory.
https://www.yoctoproject.org/docs/1.4.2/dev-manual/dev-manual.html#platdev-appdev-devshell
When debugging certain commands or even when just editing packages, devshell can be a useful tool. When you invoke devshell, source files are extracted into your working directory and patches are applied.
Since it can't parse it, there seems to be a problem with patch. How do you patch the device tree? Are you patching it in the .bb file?
If so, check your patch for possible syntax errors, it's very easy to overlook the syntax errors in device tree. You can remove the patch and do it manually from bitbake -c devshell <kernel-name>
If not, please try to do it there and check again. Please share results if any of these helps you.
So some background, I'm installing Node on a host server, but it's a grid server not a server that's solely for my website.
The grid server doesn't have a root user/ administrative powers. So to install node I found this workaround: http://iantearle.com/blog/media-temple-grid-and-nodejs . It's a Linux Grid server, I've never used Linux so if someone could explain to me what the commands mean, especially: ./configure --prefix=~/opt/
Lastly I followed the steps but when I try to run the node command in the server it says node:command not found - which is why I'm trying to understand the steps. Thanks
To explain the process:
Configure
The configure script is responsible for getting ready to build the software on your specific system. It makes sure all of the dependencies for the rest of the build and install process are available, and finds out whatever it needs to know to use those dependencies.
Unix programs are often written in C, so we’ll usually need a C compiler to build them. In these cases the configure script will establish that your system does indeed have a C compiler, and find out what it’s called and where to find it.
Make
Once configure has done its job, we can invoke make to build the software. This runs a series of tasks defined in a Makefile to build the finished program from its source code.
The tarball you download usually doesn’t include a finished Makefile. Instead it comes with a template called Makefile.in and the configure script produces a customised Makefile specific to your system.
3.Make Install
Now that the software is built and ready to run, the files can be copied to their final destinations. The make install command will copy the built program, and its libraries and documentation, to the correct locations.
--prefix=~/opt/ -> will set the build directory to /home/yourhome/opt directory.
Now if you didnt get errors while doing those 3 steps explained above make sure you did the following:
nano ~/.bash_profile
export PATH=~/opt/bin:${PATH}
nano is a text editor and you are opening .bash_profile file with it.
you need to add export PATH=~/opt/bin:${PATH} in that file and save it using ctrl+x
Then restart your terminal.
Specified github repository for nodejs is outdated. use the following link instead.
git clone https://github.com/nodejs/node.git
P.S node:command not found usually happens when the program is not installed correctly or it's executable isnt in your terminal's PATH variable.
I am using Autotools for my current project. I'm using Ubuntu and Linux mint. With Autotools I can tell it to check a users's system to check for any required libraries my project needs in order to function properly. Now I would like to check if a user's system has enabled core dumps and if not, then execute the command ulimit -c unlimited to enable core dumps. How and where do I specify this?
Also, once the user has executed the make command to compile the source code, they execute sudo make install in order to move the binaries at /usr/local/bin/MYPROJECT. I want to add the location of my project's binaries into the path environmental variable, so that the user can execute any of the binaries in my project from a terminal without the need of typing the full path. How and where do I specify this in Autotools?
I'm thinking this is something I would add in the configure.ac file, but I haven't found any examples on how I can do this. Any help would be appreciated.
It sounds as if you basically misunderstand what installation of a software
package on Linux is about.
The job of autotools is to build a portable installation package of your
software. When I install your package, it does not become your decision
whether programs that crash will generate core dumps on my computer
when I run them. It does not become your decision what PATH I use to
invoke programs by unqualified name. These are my decisions or defaults
that I have accepted from my OS distribution.
If you execute ulimit -c unlimited, the command will in any case
only apply to the shell in which it is invoked. It doesn't
reconfigure the host system (!).
If you would like users to be able to invoke your program by unqualified
name, the normal procedure is make your package install it by default in the place,
/usr/local/bin, that unix-like OSes traditionally add to a
user's default PATH for finding locally installed programs. That is
where autotools will configure it to be installed, by default. Change it
only if you don't want your program to be in the user's default PATH.
And in any case, a user can decide where your software is installed by
passing --prefix=/path/of/my/choice to the ./configure command. Unless
you have some unavoidable reason not to, make your package installation
use the defaults that everybody expects and leave it up to the installing user
to change them.
Bottom line: You are asking how to do installation actions with autotools that
are not meant to be done with autotools, because they are not meant to be
done by package installations.