I am trying to run a sample cinder in my device, but I am facing problem to do so,
First of all I cloned the cinder's repository from github and build it.
mkdir build && cd build
cmake ..
The build was sucessfull.
The documentation states that,
The runtime output directory for different configurations will
automatically end up within different folders (e.g.
lib/macosx/Debug/libcinder.a and lib/macosx/Release/libcinder.a),
However when I try to run the sample using CLion, I get following error.
ninja: error: '/home/icancode/Cinder/lib/linux/x86_64/ogl/Debug/libcinder.a', needed by 'Debug/BasicAppMultiWindowApp/BasicAppMultiWindowApp', missing and no known rule to make it
My CMakeLists.txt is:
cmake_minimum_required(VERSION 3.10)
project(BasicAppMultiWindowApp)
get_filename_component( CINDER_PATH "~/Cinder" ABSOLUTE )
include( "${CINDER_PATH}/proj/cmake/modules/cinderMakeApp.cmake" )
ci_make_app(
APP_NAME "BasicAppMultiWindowApp"
CINDER_PATH ${CINDER_PATH}
SOURCES BasicAppMultiWindowApp.cpp
)
Any solution to this, I have been trying this for hours now. Thanks in Advance.
You should use make -j8 too while building like:
mkdir build && cd build
cmake .. && make -j3
Related
Some years ago on Ubuntu 16.0.4 I've used this library: git clone https://github.com/Beckhoff/ADS and using only the make command I got build, compile and finally on the main directory I found a file called AdsLib-Linux.a and maybe nothing more than this.
Now I'm on Ubuntu 20.04 I need this library once again but this times make dosn't produce the same output and looking forth to the ReadMe instructions I finally used that instead of make:
meson build
ninja -C build
That now create a new directory build but no .a file as before on the root directory. Instead a new file in the build directory libADSLib.a is there. The same thing happens using right the make command.
Maybe the author changed over the years something on the config files or the behavior of the tools have changed, but I cannot get the former file anymore and I need it for other referencing code that now is not executing anymore.
Looking to the MakeFile I found that in the example folder, differently from the one on the parent directory, the MakeFile has something like that:
$(warning ATTENTION make is deprecated and superseeded by meson)
...
${PROGRAM}: LIB_NAME = ../AdsLib-${OS_NAME}.a
...
But all i've tried reading the guides on meson and ninja about setup, configure, build, and so on, did not produce anymore that file.
I've tried also to first build and then copy all files form the example folder to the parent directory and then build again, but again no .a file there.
How's the right way to configure the build process corectly so that this -Linux.a file is created. Or if not possibile anymore, what does it now produce I can use instead of what produced before?
Meson is a build system generator, similar to CMake or somewhat like ./configure, you need to run meson, then run ninja to actually build something.
You need to run both meson and ninja:
meson setup builddir
ninja -C builddir
Once you do that successfully, there will be a libAdsLib.a inside the builddir directory.
Let me correct a bit #dcbaker, according to their README you should setup build as build directory:
# configure meson to build the library into "build" dir
meson build
# let ninja build the library
ninja -C build
Of course, in general, it shouldn't be specific, but their example code is written in a weird way so this path is hard-coded. So, to use the example:
# configure meson to build example into "build" dir
meson example/build example
# let ninja build the example
ninja -C example/build
# and run the example
./example/build/example
About the library: it's now libAdsLib.a and produced in build directory. The name is set here and it's now in linux naming style, the old one - not. So, you have options:
Update your configuration/build files (Makefile?) where you use it
Copy or make symbolic link, e.g.
$ ln -s <>/build/libAdsLib.a <target_path>/AdsLib-Linux.a
Above it's very dependent on your development environment, do you have installation or setup scripts for it? do you permissions to modify/configure parameters for target application? do you need to support both old and new names? - many questions not related to original question about meson.
I hit this error message while trying to build gnote using GNU Autotools.
I had first run:
$ git clean -xf # to clean the tree of untracked files, then
$ autoreconf # to create the script named `configure`, and finally
$ ./configure # to check my system, and create Makefiles from their templates
Neither po/Makefile.in.in nor po/Makefile.in exist in the source tree that I downloaded.
Yet configure needs to make this po/Makefile, as called for in the root Makefile.am in this line:
SUBDIRS = data src po help
Where do I get, or how do I make, po/Makefile.in.in?
Like all Gnome related packages, gnote uses many steps of buildsystem setup beyond just running autoreconf.
The autogen.sh script gnote comes with should run all the required steps to set up the buildsystem.
As usual, run the autogen.sh script with the --help parameter if you want to call configure separately.
po/Makefile.in.in is created by running intltoolize from the intltool package. It needs to be run from the project tree's root directory.
There isn't much documentation on intltoolize that I could find except for the brief man page, but it's source code says that that it's a fork of an older utility called libtoolize, and it's a relatively short script.
(BTW, if you don't already have intltoolize installed, you can figure out which package installs it, with this: sudo apt-file find intltoolize.)
*.in files are templates used by AutoMake to create a Makefile.
.in.in is a soft link to /usr/share/intltool/Makefile.in.in.
I installed the latest Cygwin on my Windows 7 machine: version 2.893 (64-bits). I made sure I included cmake, i.e. I was able to add several packages by running the Cygwin net release setup program again, after doing the first installation. I then tried to use cmake and made sure I invoked it from the bin directory:
user008#L0147816 /bin
$ ./cmake
CMake Error: Could not find CMAKE_ROOT !!!
CMake has most likely not been installed correctly.
Modules directory not found in
//share/cmake-3.6.2
Usage
cmake [options] <path-to-source>
cmake [options] <path-to-existing-build>
Specify a source directory to (re-)generate a build system for it in the
current working directory. Specify an existing build directory to
re-generate its build system.
Run 'cmake --help' for more information.
I don't know where the build directory could be. I'm relatively new to Cygwin. I hope somebody has found a solution for getting cmake installed and working properly under Cygwin.
This looks cmake 101.
Assuming you want to just build a software download from somewhere
eg gl2ps:
# choosing a test area
$ cd /tmp
# downloading source
$ wget http://geuz.org/gl2ps/src/gl2ps-1.4.0.tgz
# expanding source code
$ tar -xf gl2ps-1.4.0.tgz
$ ls gl2ps-1.4.0-source/
CMakeLists.txt COPYING.LGPL gl2ps.h gl2ps.tex gl2psTestSimple.c
COPYING.GL2PS gl2ps.c gl2ps.pdf gl2psTest.c README.txt
# preparing a build area
$ mkdir build
$ cd build
# invoking cmake and pointing to the source directory
$ cmake ../gl2ps-1.4.0-source/
-- The C compiler identification is GNU 7.3.0
[cut ...]
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/build
# running the build
$ make
Scanning dependencies of target shared
[ 11%] Building C object CMakeFiles/shared.dir/gl2ps.o
...
[ 88%] Building C object CMakeFiles/gl2psTestSimple.dir/gl2psTestSimple.o
[100%] Linking C executable gl2psTestSimple.exe
[100%] Built target gl2psTestSimple
Instead for learning how to build with cmake, go to
https://cmake.org/cmake-tutorial/
Here a solution I just found.
Let's name 3 directories:
{cygwin64-path}/bin/: cmake.exe is here.
{cygwin64-path}/usr/share/: cmake module directory (such as cmake-3.20.0) is here.
{cygwin64-path}/share/: cmake.exe trying to find cmake-module-directory here, but it doesn't exist.
It's wired because cygwin install cmake-module-directory in {cygwin64-path}/usr/share/, but cmake.exe looks for the directory in {cygwin64-path}/share/.
So solution is simple. Each one below works.
METHOD 1: Create the directory {cygwin64-path}/share/ and copy all relevant directories and files from {cygwin64-path}/usr/share/ to the new directory.
METHOD 2: Create a Symbolic links {cygwin64-path}/share/ to {cygwin64-path}/usr/share/.
In windows 10 Administrator cmd.exe: mklink /J share usr\share and all works.
Or use WSL or Cygwin64 Terminal: ln -s usr/share share
Update: This question is already SOLVED. I'm re-editing the question to update to the fixed state.
I'm trying to write a recipe that uses dep tool to resolve dependencies of a go related project before building it. I'm using the 'poky' layer of the 'rocko' Yocto project branch. That branch provides recipes to build the go compiler and the dep dependencies tool.
My initial recipe fetches source code from a bitbucket repository:
GO_IMPORT = "bitbucket.org/path/to/my_project"
SRC_URI = "git://${GO_IMPORT}/protocol=http;user=${GIT_USER}:${GIT_PASS};destsuffix=${PN}-${PV}/src/${GO_IMPORT}"
Then I add this:
inherit go
DEPENDS += "go-dep"
And after I add this function:
do_compile_prepend() {
dep init
dep ensure
}
Yocto complains with this error:
run.do_compile.8543: line 118: dep: command not found
After reading some of your answers below, I add suggested patch in your answers at the end of my poky/meta/recipes-devtools/go/go-dep_0.3.0.bb recipe file - thanks a lot!! :-)
BBCLASSEXTEND = "native nativesdk"
After I execute some bitbake commands:
$ bitbake -c cleanall go-dep-native
$ bitbake go-dep-native
Bitbake process ends ok, displaying no errors nor warnings. The native go-dep tool has been built into tmp/work/x86_64-linux/go-dep-native directory and is properly installed into tmp/sysroots-components/x86_64/go-dep-native/usr/bin.
I modify the do_compile_prepend() function as shown below:
do_compile_prepend() {
rm -f ${WORKDIR}/build/src/${GO_IMPORT}/Gopkg.toml
rm -f ${WORKDIR}/build/src/${GO_IMPORT}/Gopkg.lock
cd ${WORKDIR}/build/src/${GO_IMPORT}
dep init
dep ensure
}
I modify DEPENDS in my recipe like this:
DEPENDS = "go-native go-dep-native"
Note the go-dep has been removed (I don't need dep tool on the target device, just to resolve dependencies on the native platform).
After that, I execute this command:
$ bitbake <foo>
The do_compile stage works fine, but some errors appear when doing the do_package stage:
ERROR: <foo>-1.0-r0 do_package: QA Issue: File '/usr/bin/dep' from <foo> was already stripped, this will prevent future debugging! [already-stripped]
ERROR: <foo>-1.0-r0 do_package: Fatal QA errors found, failing task.
ERROR: <foo>-1.0-r0 do_package: Function failed: do_package
These errors are fixed appending this at the end of my recipe:
INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
INHIBIT_PACKAGE_STRIP = "1"
RDEPENDS_${PN}-staticdev += "bash"
RDEPENDS_${PN}-dev += "bash"
I don't know if this is the best way to solve my issue, but at least now it works fine. Any advice to improve this recipe is wellcome. Thank you in advance! :-)
The DEPENDS += "go-dep" means that your target recipe can include headers or link libs provided by go-dep, but you can't run the dep command, if you need run dep command, you need depend on go-dep-native:
DEPENDS += "go-dep-native"
But yocto doesn't provide go-dep-native currently, so you have to add:
BBCLASSEXTEND = "native"
to meta/recipes-devtools/go/go-dep_XXX.bb.
Then you can run dep command in do_compile_prepend()
I just sent the patch[1] to enable the native and nativesdk support for the recipe.
https://patchwork.openembedded.org/patch/147390/
Assuming you're using the same recipe as the one here, you should be able to refer to the ${GO_INSTALL} variable in your do_compile_prepend build step. If not, try running -c devshell with your bitbake command, like:
bitbake <package name> -c devshell
and look for the path of the dep tool.
I'm packaging a software (neko) for Debian. The software uses CMake for building. I already have everything setup and it builds nicely. Now, I want to add some additional tests on top of the upstream tests, so I override dh_auto_test in debian/rules as follows:
override_dh_auto_test:
dh_auto_test
cd <build_dir> && ./bin/nekotools boot test.n && ./bin/test
The problem is that I don't know what is the CMake build directory (<build_dir> as written above) thus cannot figure out the paths to the build outputs. Is there a variable that points to the build directory?
I find out that I can specify the build directory as follows:
%:
dh $# --builddirectory=foo
It is mentioned in the dh manpage.
However, I still would like to know whether there is a variable that stores the build directory even if I'm not using --builddirectory...