I want to force-recompile a package, like that:
bitbake -f -c compile mypackage
However, I also want all following tasks to be executed (like install, package, etc.), just as if I had called bitbake mypackage from a completely clean state. Can this be done in one step, rather than the following two?
bitbake -f -c compile mypackage
bitbake mypackage
Or as an alternative solution, can I somehow "taint" the compile-task, such that executing bitbake mypackage does everything from compilation onwards?
This is exactly what -C is for:
bitbake -C compile mypackage
This will run mypackage:do_build and force mypackage:do_compile to execute. Strictly speaking, it taints mypackage:do_compile (so that it has to execute) and then executes mypackage:do_build, which is exactly what you wanted.
Related
I'm having an issue with a new bitbake recipe. My recipe depends on files produced by a net-snmp recipe from openembedded, but net-snmp doesn't seem to be building before trying to compile my recipe.
In my .bb file, I have:
DEPENDS = " \
net-snmp \
...
EXTRA_OEMAKE += " \
BINDIR=${STAGING_BINDIR} \
...
do_compile() {
oe_runmake foo
}
Then my makefile includes
CFLAGS=`${BINDIR}/net-snmp-config --cflags` ...
When I run bitbake foo, do_compile throws the error
/bin/sh: [some-path-to-net-snmp-config]: No such file or directory
If I check the staging directory, net-snmp-config is indeed missing.
But if I then run bitbake -C compile net-snmp foo, foo builds successfully, and net-snmp-config is in the staging directory.
What am I doing wrong here?
Edit: I've just noticed that even if foo builds successfully, net-snmp is suspiciously absent from my final rootfs image.
If I add RDEPENDS="net-snmp" to my recipe, I get the error:
satisfy_dependencies_for: Cannot satisfy the following dependencies for packagegroup-core-boot:
| * net-snmp *
I think I found the solution.
Based on this blog entry, I added the line
do_compile[depends] += "net-snmp:do_install"
Now my recipe builds successfully every time.
I was also trying to use RDEPENDS incorrectly. Since net-snmp outputs several packages, I needed to specify the individual packages in RDEPENDS in order to include them in my final build.
I understand what I believe is the essence of the official utilties doc https://coq.inria.fr/refman/practical-tools/utilities.html#building-a-coq-project:
one creates a _CoqProject with arguments to coqc and the file names to compile (hopefully in an order that takes into account dependencies)
then one make an automatic CoqMakefile with coq_makefile -f _CoqProject -o CoqMakefile
Then you use their recommended Makefile to run the automatically generated make file.
But then if we need other dependencies, it doesn't say how to install them (or uninstall) them. What is the standard way to do that?
My guess is that one likely adds a target to your Makefile at the end of it and do some sort of opam install?
e.g.
# KNOWNTARGETS will not be passed along to CoqMakefile
KNOWNTARGETS := CoqMakefile
# KNOWNFILES will not get implicit targets from the final rule, and so
# depending on them won't invoke the submake. TODO: Not sure what this means
# Warning: These files get declared as PHONY, so any targets depending
# on them always get rebuilt -- or better said, any rules which those names will have their cmds be re-ran (which is
# usually rebuilding functions since that is what make files are for)
KNOWNFILES := Makefile _CoqProject
# Runs invoke-coqmakefile rule if you do run make by itself. Sets the default goal to be used if no targets were specified on the command line.
.DEFAULT_GOAL := invoke-coqmakefile
# Depends on two files to run this, itself and our _CoqProject
CoqMakefile: Makefile _CoqProject
$(COQBIN)coq_makefile -f _CoqProject -o CoqMakefile
# Note make knows what is the make file in this case thanks to -f CoqMakefile
invoke-coqmakefile: CoqMakefile install_external_dependencies
$(MAKE) --no-print-directory -f CoqMakefile $(filter-out $(KNOWNTARGETS),$(MAKECMDGOALS))
#
.PHONY: invoke-coqmakefile $(KNOWNFILES)
####################################################################
## Your targets here ##
####################################################################
# This should be the last rule, to handle any targets not declared above
%: invoke-coqmakefile
#true
# I know this is not a good coq dependency example but just to make it concrete wrote some opam command
install_external_dependencies:
opam install coq-serapi
I think I wrote the install_external_dependencies in the right place but I'm not sure. Is that correct? Anyone has a real example?
For all the code see: https://github.com/brando90/ultimate-utils/tree/master/tutorials_for_myself/my_makefile_playground/beginner_coq_project_with_makefiles/debug_proj
related: question on official tutorial for building coq projects https://coq.discourse.group/t/official-place-to-learn-how-to-setup-coq-make-files-for-beginner/1682
Btw,
I don't understand the last like in the makefile yet.
# This should be the last rule, to handle any targets not declared above
%: invoke-coqmakefile
#true
i.e.
%true in the make file template coq gave us.
% in the name of the rule.
What does that line do?
Update
I'm seeking an end-to-end small demo of how to install all dependencies with whatever the recommended approach when using _CoqProject and coq_makefile as shown in the utilities doc https://coq.inria.fr/refman/practical-tools/utilities.html. The ideal answer would contain a single script to install and compile everything in one go -- say in a install_project_name.sh. Including opam switches etc.
Related:
How does one install a new version of Coq when it cannot find the repositories in a new Mac M1 machine?
Installing packages for Coq using OPAM
https://coq.discourse.group/t/official-place-to-learn-how-to-setup-coq-make-files-for-beginner/1682
The simplest setup is to install external dependencies manually with opam.
opam install packages-needed-by-my-project
Then they will be immediately available to build your own project.
The next level of organization is to package up your project. Refer to the following Coq community resources:
Coq community templates
Recommended Project Structure
The main thing immediately relevant to your question is to have a *.opam file at the root of your project which lists its dependencies (possibly with version requirements). Then you can install them using opam install . --deps-only.
The Makefile part of your question is about a bit of overengineering for passing options seamlessly to CoqMakefile. I'm not sure how it works off-hand, but it's not important anyway, especially because Dune is superseding make as the recommended build system for Coq project.
bitbake cleanall
Removes all output files, shared state cache, and downloaded source files for a target
It is not clear or documented if it cleans all build time dependencies as well
If you want to clean everything do,
bitbake world -c cleanall --continue
The --continue will ignore any dependency errors while cleaning. Continue as much as possible after an error.
No, cleanall does not clean dependencies. eg
bitbake -c cleanall core-image-minimal
only removes the output of that named recipe.
What i usually do to clean "everything" is running cleanall on the receipe "world":
bitbake -c cleanall world
If that fails because of unresolvable packages like that:
ERROR: Nothing PROVIDES 'sg3-utils' (but /home/blubb/meta-freescale/recipes-devtools/utp-com/utp-com_git.bb DEPENDS on or otherwise requires it).
I just add the packages temporary to the ASSUME_PROVIDED variable like this :
bitbake -c cleanall world --ignore-deps=python-nativedtc-native --ignore-deps=sg3-utils
If nothing provides this packages it is unlikely that they where ever build.
Please read the mega-manual section do_cleanall .
do_cleanall removes:
all output files
shared state (sstate) cache
and downloaded source files for a target (i.e. the contents of DL_DIR).
You can run this task using BitBake as follows:
$ bitbake -c cleanall <recipe-name>
If recipe name is not passed to cleanall task it does not work.
Removes all output files, shared state (sstate) cache, and downloaded source files for a target (i.e. the contents of DL_DIR). Essentially, the do_cleanall task is identical to the do_cleansstate task with the added removal of downloaded source files.
You can run this task using BitBake as follows:
$ bitbake -c cleanall recipe
Typically, you would not normally use the cleanall task. Do so only if you want to start fresh with the do_fetch task.
Other folks have already answered that bitbake does not automatically clean dependencies, but you can create an Inter-task dependency (https://www.yoctoproject.org/docs/3.1/bitbake-user-manual/bitbake-user-manual.html#inter-task-dependencies) to clean your dependencies if needed by adding a command to the recipe:
do_task[depends] = "recipe:task"
We've extended bitbake to build native recipes and automatically run unit tests during a build. In that case we need to clean the native recipe when cleaning the target so you could add:
do_clean[depends] = "${PN}-native:do_clean"
do_cleanall[depends] = "${PN}-native:do_cleanall"
do_cleansstate[depends] = "${PN}-native:do_cleansstate"
That solution falls a bit short because the native recipes will attempt to clean ${PN}-native-native, so you'll need a conditional to not apply if it's already native:
do_clean[depends] += "${#'' if bb.data.inherits_class('native', d) else '${PN}-native:do_clean'}"
do_cleanall[depends] += "${#'' if bb.data.inherits_class('native', d) else '${PN}-native:do_cleanall'}"
do_cleansstate[depends] += "${#'' if bb.data.inherits_class('native', d) else '${PN}-native:do_cleansstate'}"
I'm having trouble cross compiling Qt5 for beaglebone using openembedded with bitbake. I think in step do_configure not everything is passed from my *.bbappend and no platform plugins are installed (I need 'linuxfb').
My question will be: how to make bitbake print list of arguments it passes to ./configure?
There's a few ways to get that info, I would suggest looking in the recipe work directory:
temp/log.do_configure contains the configure task log which should list exact ./configure-command
build/ contains the projects own build system artefacts
bitbake -e <recipe> | grep <VARIABLE> is very useful if you want to know what variable values end up as (check e.g. PACKAGECONFIG and PACKAGECONFIG_CONFARGS values if you're modifying packageconfig).
I have a Coq project with its libraries organised into subdirectories, something like:
…/MyProj/Auxiliary/Aux.v
…/MyProj/Main/Main.v (imports Auxiliary/Aux.v)
When I compile the files, I expect to do so from working directory MyProj (via a makefile). But I also want to work on the files using Proof General/Coqtop, in which case the working directory is by default the directory in which the file lives.
But this means that the LoadPath is different between the two contexts, and so the logical path needed for the library import is different. How do I set up the coqc invocation, the LoadPath, and the import declarations so that they work in both contexts?
Each approach I have tried, something goes wrong. For instance, if I compile Aux.v by invoking
coqc -R "." "MyProj" Auxiliary/Aux.v
and import it in Main.v as
Require Import MyProj.Auxiliary.Aux.
then this works when I compile Main.v with
coqc -R "." "MyProj" Main/Main.v
but fails in Coqtop, with Error: Cannot find library MyProj.Auxiliary.Aux in loadpath. On the other hand, if before the Require Import I add
Add LoadPath ".." as MyProj.
then this works in Coqtop, but fails under coqc -R "." "MyProj" Main/Main.v, with
Error: The file […]/MyProj/Auxiliary/Aux.vo contains library
MyProj.Auxiliary.Aux and not library MyProj.MyProj.Auxiliary.Aux
I’m looking for a solution that’s robust for a library that’s shared with collaborators (and hopefully eventually with users), so in particular it can’t use absolute file paths. The best I have found for now is to add emacs local variables to set the LoadPath up when Proof General invokes Coqtop:
((coq-mode . ((coq-prog-args . ("-R" ".." "MyProj" "-emacs")))))
but this (a) seems a little hacky, and (b) only works for Proof General, not in Coqide or plain Coqtop. Is there a better solution?
Allow me to side-step your question by suggesting an alternative process, hinted at by Tiago.
Assuming that your project's tree looks like this:
MyProj/Auxiliary/Aux.v
MyProj/Main/Main.v
In MyProj, write a _CoqProject file listing all your Coq files
-R . ProjectName
Auxiliary/Aux.v
Main/Main.v
When you open one of these Coq files, emacs will look for the _CoqProject and do-the-right-thing (tm).
As shown by Tiago, coq_makefile will also give you a Makefile for free.
I know you explicitly asked for something that works across different platforms, but there's already a Proof-General-specific solution that is less hacky than the one you have. Proof General has a special variable called coq-load-path that you can set with local variables, much like you did for coq-prog-args. The advantage is that you don't have to worry about any other arguments that need to be passed to coqtop (such as -emacs in your example). Thus, your .dir-locals.el file could have a line like this:
((coq-mode . ((coq-load-path . ((".." "MyProj"))))))
Unfortunately, I am not aware of anything that works across platforms, although I'm pretty sure that something specific for CoqIDE must exist. If this is the case, maybe you could set up a script to keep these configuration files updated across different platforms?
If you use coq_makefile you can install the library in your system.
Without OPAM
To initialize your project:
coq_makefile -f _CoqProject -o Makefile
Share your library with other projects:
make install
With OPAM
Assuming you have OPAM installed, you can use coq-shell to help you take care of dependencies.
To setup your project:
coq_shell_url="https://raw.githubusercontent.com/gares/opam-coq-shell/master/src/opam-coq"
curl -s "${coq_shell_url}" | bash /dev/stdin init 8.4 # Install Coq and its dependencies
eval `opam config env --switch=coq-shell-8.4` # Setup the environment
coq_makefile -f _CoqProject -o Makefile # Generates the makefile
opam pin add coq:YOURLIBRARY . # Add your library to OPAM
When you update your library you should do:
opam upgrade coq:YOURLIBRARY
Here is an example of a project that uses the OPAM method:
https://bitbucket.org/cogumbreiro/aniceto-coq/src