I'm in a Jekyll project with the following makefile:
project = jekyll-template-repository
e: execute
execute:
bundle
build
r: run
run:
jekyll serve -l -o -b /$(project)
b: build
build: clean
jekyll build
c: clean
clean:
jekyll clean
And when I run make execute, it throw me the error make: build: Command not found
I suppose it is trying to execute it as a common bash command, however I would like to call the build rule I wrote forward in the file. Is there some special syntax required to point to other make rules when they aren't right after another rule :?
You can't "call" rules in a makefile. Rules aren't functions. You can depend on a target, in which case that target will be made up to date before this target can be considered up to date.
Each recipe of a rule is, indeed, a shell script. It's not ever a list of other targets.
You can write:
execute: build
then it will first execute the build target's recipe (assuming it's not up to date), then after that it will execute the recipe for the execute target.
Related
I have always written build (compilation) and install as completely different (to make(1), even unrelated) stages. I could even write them in two separate Makefiles since they are completely isolated.
But a year ago or so, I wrote a Makefile where I specified the dependencies between install and compilation, and noticed some good things.
See the following minimal example:
.PHONY: all
all: build
.PHONY: build
build: foo
.PHONY: install
install: /usr/local/bin/foo
foo: foo.c
cc -o $# $<
/usr/local/bin/foo: foo
install -m 755 -T $< $#
Should /usr/local/bin/foo depend on foo or not?
Reasons to state the dependency:
Only install if necessary (if foo was recompiled).
Of course, that saves considerable install time.
The Makefile can compile something if we forgot to compile it (but see below).
Reasons to not state the dependency:
Make sure that you never compile accidentally as root.
Make sure you install the correct files,
even if they were edited more recently than the compiled files.
This would be similar to the concept of a reinstall.
But for that rare scenario, one could run 'make uninstall && make install'.
The GNU Make Manual, section Standard Targets, lists several standard targets and what make users should expect from them. About the install target:
Compile the program and copy the executables, libraries, and so on to the file names where they should reside for actual use. If there is a simple test to verify that a program is properly installed, this target should run that test.
As for running make as root, I think most do sudo make install without second thoughts. If you're not sure what the makefile will do you can review the output of make -n install for any shenanigans (after running make all to review just the install part).
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 am trying to skip installation of few packages which are define in Makefile while running make package command . I cannot change makefile so want to just skip those steps in any other way.
I am installing those packages locally and copy them to the path by using dockerfile.
When I tried to run make package it gave me an error:
cannot create directory '/usr/local/bin/codechecker/tools/plist_to_html/plist_to_html/static/vendor/codemirror': File exists
I also tried to use make package -k but it also failed with error because of earlier errors:
#17 17.61 make: Target 'package' not remade because of errors.
Is there a way to avoid these error and skip the steps from makefile? would appreciate any help.
I have makefile all: clean $(binary_output_path)/$(target_executable) which cleans output directory first and the build executable. The problem is when I want to use -j10: sometimes it start building and cleaning at the same time, so build fails, obviously.
How can I overcome this and have targets executed in order but on multiple cores?
You should add the dependency:
$(binary_output_path)/$(target_executable): | clean
However, this is not a good idea to use clean like that at all. Just have
all: $(binary_output_path)/$(target_executable)
$(binary_output_path)/$(target_executable): prerequisites
write your recipe here that builds this target
You should focus on writing makefiles in such a way that cleaning is not needed. If you must clean first before building your executable, find out why that is so, and write your commands that build the executable, in such a way that they work regardless of whether you have "cleaned" or not.
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.