I am trying to include the libjsoncpp package into my Yocto build, which is not currently included in Yocto's package list. I downloaded the source files from http://sourceforge.net/projects/jsoncpp/files/jsoncpp/. The package does not come with an INSTALL script but instead uses scons.py. How can I write the install script for this as a recipe?
Thanks
I downloaded the jsoncpp-src-0.6.0-rc2.tar from that link and didnt see any scons.py, even though the README says it should be there. I did however look through the SConstruct included therein, which is the main SCons build script.
To be able to use it, you will need to (obviously :) ) install Python and SCons, as indicated in the README:
(I would recommend the latest version of SCons, which is 2.3.0, hopefully its compatible)
Building/Testing: =================
JsonCpp uses Scons (http://www.scons.org) as a build system. Scons
requires python to be installed (http://www.python.org).
You download scons-local distribution from the following url:
http://sourceforge.net/projects/scons/files/scons-local/1.2.0/
Unzip it in the directory where you found this README file. scons.py
Should be at the same level as README.
python scons.py platform=PLTFRM [TARGET]
You should then be able to invoke scons from your scripts as follows:
$ scons -f <path to json>/SConstruct platform=linux-gcc
Substitute linux-gcc with your platform. Read through the SConstruct and search for platform to see all the possibilities.
Related
I have CMake project built and installed.
Now I want to generate debian package (*.deb) from this. In the Internet there are many instructions how to create debian package with adding something to CMake's files, but the project, which I've built does not belongs to me, so I shouldn't modify its source.
I've found command cpack, which is can also generate deb packages. Unfortunately when I try to use the command:
cpack -G DEB -C cmake/build/directory -P myPackage.deb -R 1.0.
I see:
CPack Error: Please specify build tree of the project that uses CMake using CPACK_INSTALL_CMAKE_PROJECTS, specify CPACK_INSTALL_COMMANDS, CPACK_INSTALL_SCRIPT, or CPACK_INSTALLED_DIRECTORIES.
Unfortunately the options can't be specified in commands in help:
cpack --help
So is it possible to generate debian package with command cpack without any changes to CMake files?
When the CMakeLists.txt includes the CPack module, it produces CPackConfig.cmake in the top build directory. This config file is the default for CPack, but you can override it w/ --config option.
The file consists of a bunch of set() commands to set various CPACK_* variables. To produce a package (the DEB in your question) you ought to write the config file "manually" and set vital variables for CPack, as well as some for DEB generator (i.e. CPACK_DEBIAN_*).
Generally, this config (the variables in it) describes what project(s) and it's components to include to package(s), define some meta-data & so on... In theory, you can pass all that defines via -D options to cpack(1). In practice, IMHO, it'll be easier to write the CPackConfig.cmake %)
Having that config file this command should to what you want:
$ cpack -G DEB
(or just cpack alone if your config describes only Debian package to build).
I have a non-Haskell executable (bash script) that I would like cabal to install in ~/.cabal/bin along with my Haskell library. How can I achieve this simply with cabal?
Edit: as I mentioned in a comment below: installing specifically to ~/.cabal/bin isn't crucial, I just need the script to be available in my library.
You can use cabal's data-files field to have some extra files installed, and then use the getDataFileName function created by cabal to retrieve the file. Details are available in the documentation and this blog post.
I am developing two libraries A and B with B depending on A, both managed in their own Git repositories. The libraries are built with CMake and installed in standard UNIX directories. During installation a .pc file is also installed that is used by pkg-config. Library B uses pkg-config to find library A, therefore it is necessary that either library A is installed system-wide with make install or the PKG_CONFIG_PATH is set to the appropriate directory.
Now, I use Jenkins to build library A on a remote machine. Unfortunately, library B cannot be built because the dependency is not met (pkg-config cannot find library A). Setting the paths in a pre-build step is not working because the commands are run in its own shell.
The questions are
Can I somehow make install library A? Or,
can I somehow point CMake to /var/lib/jenkins/jobs/libA/install_dir/lib?
Is there a better way to build projects with inter-dependent libraries?
To answer your questions in order:
To make install library A - You can configure the Jenkins job that builds library A to archive the library as a build artefact. Then the job to build library B can download the artefact from Jenkins at the start of the run – e.g. http:///job/libA/lastSuccessfulBuild/artifact/
Once the library B job has collected library A it can then be installed and used.
Configuring Cmake – I don't know enough about cmake so I'm afraid I can't answer that.
Is there a better way – Possibly using Rake, we use it to control a build chain with lot's of dependencies. Although I'm not sure how well it would work if library A has to be built on a remote machine. Things might be simpler to manage if both libraries are build on the same machine.
Using artifacts, as suggested by user1013341, is one of the steps that was needed to this problem. But to get it working with pkg-config we have to do a little bit more:
I setup library A's CMakeLists.txt to produce a tarball with make package_source.
After a successful build of library A, Jenkins create this tarball and stores it as an artifact.
library B uses the Copy Artifact Plugin to get the tarball and untars it. Inside of the tarball there is still built project and the .pc file pointing to the install location of library A.
In the next build step, I use the EnvInject Plugin to set the PKG_CONFIG_PATH and the LD_LIBRARY_PATH to the untarred library A.
Last but not least, the normal CMake build process can be started and the correct paths are picked up according to the environment variables.
I want to install multiple versions of a package (say libX) from src. The package (libX) uses Autotools to build, so follows the ./configure , make, make install convention. The one installed by default goes to /usr/local/bin and /usr/local/lib and I want to install another version of this in /home/user/libX .
The other problem is that libX is a dependency for another package (say libY) which also uses autotools. How to I make libY point to the version installed in /home/user/libX ? There could be also a possibility that its a system package like ffmpeg and I want to use the latest svn version for my src code and hence build it from src. What do i do in that case ? What is the best practice in this case so that I do not break the system libraries?
I'm using Ubuntu 10.04 and Opensuse 10.3.
You can usually pass the --prefix option to configure to tell it to install the library in a different place. So for a personal version, you can usually run it as:
./configure --prefix=$HOME/usr/libX
and it will install in $HOME/usr/libX/bin, $HOME/usr/libX/lib, $HOME/usr/libX/etc and so on.
If you are building libY from source, the configure script usually uses the pkg-config tool to find out where a package is stored. libX should have included a .pc file in the directory $HOME/usr/libX/lib/pkgconfig which tells configure where to look for headers and library files. You will need to tell the pkg-config tool to look in your directory first.
This is done by setting the PKG_CONFIG_PATH to include your directory first.
When configuring libY, try
PKG_CONFIG_PATH=$HOME/usr/libX/lib/pkgconfig:/usr/local/lib/pkgconfig ./configure
man pkg-config should give details.
I need a non-stripped version of libpthread.so for debugging. How can I compile it from source code? Host is Linux 2.6.
If you're on an RPM based system, use rpm -qf .../libpthread.so to find out which package installed the file (if that doesn't produce a result, the .so file is probably a link; then run the command on the file the link points to).
If you have the package name, search for the "source package". How this works depends on the distribution you use. For openSUSE, you must add the Source Repository using Yast. After that, you can install the source package which will give you some entries under /usr/src/packages. To build the package, go to /usr/src/packages/SPECS and run rpmbuild with the pthread.spec file as parameter.
When the build suceeds, edit the .spec file and change it so it doesn't strip the symbols.
Alternatively, look if there is a *-debug package (replace "*" with the name of the package) and install that. It should contain the version of the library with the symbols.