So I have a directory in my project directory called bin, but I also need a variable to hold the directory for where I install binaries, what should I call the latter variable?
BINDIR = ./bin
INSTALL_BINDIR = /usr/bin
Related
I have a directory tree like this with some "shared targets" in the file rules.Makefile:
├── Makefile
├── rules.Makefile
└── my_subdir
└── Makefile
I would like to invoke these "shared targets" in both the Makefile(s) in the parent directory and the child directory.
Also the "custom targets" in the Makefile in the child directory should be callable from the Makefile in the parent directory.
For some reason I am able to call the targets in rules.Makefile only from the sibling Makefile (the one in the parent directory). When using relative paths in the Makefile in the child directory trying to access the rules.Makefile in the parent directory I get some errors.
The content of the Makefile in the parent directory:
RULES_MAKEFILE_PATH=$(PWD)/rules.Makefile
include $(RULES_MAKEFILE_PATH)
foo-parent:
#echo $(RULES_MAKEFILE_PATH)
The content of the Makefile in the child directory (please note that double dot ..):
RULES_MAKEFILE_PATH=$(PWD)/../rules.Makefile
include "$(RULES_MAKEFILE_PATH)"
foo-child:
#echo $(RULES_MAKEFILE_PATH)
When calling from the parent directory make foo-parent then I see the expected path.
When calling from the child directyr make foo-child then I see this error:
$ make foo-child
Makefile:9: "/<PARENT_PATH>/my_subdir/../rules.Makefile": No such file or directory
make: *** No rule to make target '"/<PARENT_PATH>/my_subdir/../rules.Makefile"'. Stop.
How can I make the relative paths work in the "child directory"?
Also how can I call the targets defined in the Makefile in child directory (e.g. foo-child) from the Makefile in the parent directory?
Well first, $(PWD) is not a special variable to make. It's just a normal variable, that's imported from your shell. So it will always have the same value everywhere in your makefile and in all included makefiles, it won't change just because you're including a makefile from a different directory.
Second, even for $(CURDIR) (which is a special variable and is set by make to be the current directory when make starts), it is never reset when you include a makefile from another directory.
And, all paths in include lines are evaluated based on the directory make was in when it started, not on a path relative to the currently-parsed makefile. So if Makefile includes foo/Makefile, then foo/Makefile has an include bar.mk, make will look for bar.mk not foo/bar.mk.
The point about $(PWD) above is true. However, if that is not a concern, you could still use the shell function to execute commands to get paths of another Makefile to include: $(shell pwd)
I did something similar for a project that benefited from having the same Makefile used in many places, using git rev-parse --show-toplevel.
MAKEFILE := $(shell git rev-parse --show-toplevel)/makefiles/example.def
include $(MAKEFILE)
A Makefile contains
include ../../common/common.mk
at the end of the file. I want to see the full path during the invocation. How can I do that?
$(info full path to common.mk: $(abspath ../../common/common.mk))
include ../../common/common.mk
Usually, make does not change working directory during execution. Most likely, you can check for ../../common/common.mk from command line just before running **make*. But if you use make -C some/directory then the working directory will be whatever you specify after -C (relative to your current directory).
I have created a Yocto recipe for my program.
What are the default folders that are building image from recipe ?
At the time of building image, I want to move my files to another folder like "/opt/xyz".
Should I simply do "mv" or is there any other options?
I guess you want to copy your compiled program to a folder such as ${bindir}:
Quote from Yocto ref-manual 1.1:
When specifying paths as part of the CONFFILES variable, it is good practice to use appropriate path variables. For example, ${sysconfdir} rather than /etc or ${bindir} rather than /usr/bin. You can find a list of these variables at the top of the meta/conf/bitbake.conf file in the Source Directory.
You can copy files from your working directory to any directory in the target filesystem. See the hello-world example for instance (note that the example is taken from the 1.1 reference manual, but I haven't found it yet in the newer version):
DESCRIPTION = "Simple helloworld application"
SECTION = "examples"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
PR = "r0"
SRC_URI = "file://helloworld.c"
S = "${WORKDIR}"
do_compile() {
${CC} helloworld.c -o helloworld
}
do_install() {
install -d ${D}${bindir}
install -m 0755 helloworld ${D}${bindir}
}
FILES_${PN} = "${bindir}"
In this example, the helloworld binary would be copied to /usr/bin on your image (could be /opt too, see Source Directory for the variable definition).
Adjust FILES_${PN} var for ${sysconfdir} ${bindir} ${datadir} ${libdir} directories.
do_install(){
install -d ${D}{base_prefix}/opt/xyz/
install -m ${WORKDIR}/yourbinary ${D}${base_prefix}/opt/xyz/
}
FILES_${PN} = "${base_prefix}/opt/*"
above
1st line creates the dir in imagedir in that opt/xvz/
2nd line copy your binary to opt/xyz/dir
3rd line use to copy of your opt/xyz/binary to yocto rootfs.
I have a project that uses CMake to generate build scripts, and each platform puts the executable that are generated in a different place. We have a non-programmer on our team who does not have build tools and I want to be able to bundle up all the files, scripts and executables necessary to run the project so that he can run the project.
To do that, I've added a custom target that takes all the necessary files and zips them up. It also generates a very simple script (which is included in the zip file) that he can just click on that should run a script then launch the executable, like so:
add_custom_target(runcommand
COMMAND echo '\#!/bin/bash -eu' > run.command &&
echo 'cd `dirname $$0`' >> run.command &&
echo './scripts/prerun_script.sh && ${MY_EXECUTABLE}' >> run.command &&
chmod +x run.command)
The problem with this is that MY_EXECUTABLE is a hardcoded path to the executable on my system. I would like it to be a relative path so that I can just take this resultant zip file, unzip it anywhere and run it from there. What I would like is to get the path to MY_EXECUTABLE relative to the root directory of my project so that this script can be run from anywhere.
You can use:
file(RELATIVE_PATH variable directory file)
Concretely, assume that MY_ROOT contains the root directory (there might be a suitable predefined CMake variable for this), this will set rel to the relative path of MY_EXECUTABLE:
file(RELATIVE_PATH rel ${MY_ROOT} ${MY_EXECUTABLE})
In case where you want to get path relative to project root, you may use PROJECT_SOURCE_DIR CMake variable:
file(RELATIVE_PATH rel ${PROJECT_SOURCE_DIR} ${MY_EXECUTABLE})
Remember, that MY_EXECUTABLE must contain full path to file.
get the relative path to the current source directory
file(RELATIVE_PATH relative ${CMAKE_SOURCE_DIR} ${CMAKE_CURRENT_SOURCE_DIR})
Test:
message(STATUS "source base: \"${CMAKE_SOURCE_DIR}\"")
message(STATUS "current: \"${CMAKE_CURRENT_SOURCE_DIR}\"")
message(STATUS "relative: \"${relative}\"")
Result:
--source base: "C:/Project/Software/Test/source"
--current: "C:/Project/Software/Test/source/unittest/libs/fsm
--relative: "unittest/libs/fsm"
Something like this would work:
THISDIR=`pwd`
MY_EXECUTABLE=$THISDIR/test/someexec
REL_EXECUTABLE=${MY_EXECUTABLE##$THISDIR/}
echo $REL_EXECUTABLE
Basically, this chops off the base path from $MY_EXECUTABLE. In this example, I just set up MY_EXECUTABLE as a test to give it a full path. The one-line equivalent for what you want is:
${MY_EXECUTABLE##`pwd`/}
I guess this assumes pwd is the root of your project. Otherwise, see the Cmake variable doc.
(As an aside, this makes me nostalgic for the ksh days.)
My current project has a couple files in its include/tatoparser directory that I would like to distribute along with my library.
qdii#nomada ~/MyProject $ ls include/tatoparser/
dataset.h interface_lib.h linkset.h sentence.h tagset.h
I created a Makefile.am that references those files:
qdii#nomada ~/MyProject $ cat include/Makefile.am
include_HEADERS = tatoparser/interface_lib.h tatoparser/sentence.h tatoparser/dataset.h tatoparser/tagset.h tatoparser/linkset.h
But when I run make install the referenced files get copied into /usr/include (or whatever $(includedir) was set to), and I want them copied in /usr/include/tatoparser.
How can I do that?
Use the nobase prefix to stop Automake from stripping the subdirectory path from the files:
nobase_include_HEADERS = tatoparser/interface_lib.h tatoparser/...