I have done make menuconfig for a board defconfig and modified few configurations. When I select save, a new .config was created in the Kernel top directory.
I want to create new defconfig for this .config file created.
Can I copy the .config as a new defconfig and copy to arch/arm/configs/?
$ cp .config arch/arm/configs/board_new_defconfig
I think you have to do just one command and use the created file as you want to.
% make savedefconfig
% cp defconfig arch/arm/configs/my_cool_defconfig
(Pay attention to the filename template that is used for defconfig)
To get all possible targets just run
% make help
As noted by Adam Miller followed by Jeremy, users of Buildroot distribution can use wrappers for that purpose, i.e. (per Buildroot manual, section 8.1):
linux-savedefconfig for linux
barebox-savedefconfig for barebox bootloader
uboot-savedefconfig for U-Boot bootloader
make savedefconfig minimizes the generated defconfig skipping redundant configs that are implied by others.
For your platform, in a new defconfig file, yes. In fact this is the safest way to create a new defconfig. If you manually remove config entries from an existing config file to create a new one, you are likely to get dependency issues and during build, it might restart the kernel config and give you prompts for selecting individual config options.
Related
I have a mono-repository ("monorepo") that contains the C++ source code for my application, as well as a tree of OE/Yocto files and directories that form the bitbake recipes required to build my final image.
I wish to build and install my application into the image, but as far as I can tell, the Yocto philosophy is that source code is "fetched" (e.g. via git), from an external place, before it is built. But in my case the source code resides in the same repository. It doesn't seem to make sense to me that the entire repository is downloaded again, by bitbake, just to fetch the source for this application, so I'm looking for a better way.
I'm familiar with the idea of putting all the source in the files/ subdirectory, alongside the recipe itself. The issue I have with that is that I don't want to keep the source in the Yocto layer's recipe tree. It can be built with the SDK, for example, or even with other completely unrelated toolchains, so it should not be buried within a Yocto layer. It has its own life, outside Yocto.
I'm also familiar with the EXTERNALSRC directive, that can be used to "point" to the source code with a relative path from the build directory. For example:
EXTERNALSRC = "${TOPDIR}/../../src/myproject"
However, this is frequently not recommended as a "production" mechanism due to path issues, and it also disables devtool:
ERROR: externalsrc is currently enabled for the myproject recipe. This prevents the normal do_patch task from working. You will need to disable this first.
So I'm looking for a recommendation on how to handle compiling an application that resides in the same repository as the recipe, without putting it in files/.
EDIT: I tried something along these lines:
SRC_URI = "file://${TOPDIR}/../../src/myproject/main.c \
file://${TOPDIR}/../../src/myproject/Makefile \
"
This did not compile, but with devtool modify myproject I was able to see that it has in fact copied the source into the build directory. The problem is that it's replicated the entire directory structure from the root all the way up to the original source directory, so my source is now sitting in a location like this:
/home/david/monorepo/yocto/build/workspace/sources/myproject/home/david/monorepo/src/myproject
do_compile will need to determine and set that working directory before it will compile.
This means that the path will change depending on the user and the location of where they've checked out the monorepo. This almost works, but doesn't seem usable as-is. Is there a way to modify where bitbake's "file" fetcher puts the source when given an absolute path?
EDIT 2:
I may have found a way that works with bitbake and devtool:
FILESEXTRAPATHS_prepend := "${TOPDIR}/../../src/myproject:"
SRC_URI = "file://main.c \
file://Makefile \
"
This seems to set up the devtool directory in a much saner way (no replication of the directory tree, just symlinks to the files in oe-local-files/* directory), and the bitbake recipe also builds and installs correctly.
Is this the right way to do it?
EDIT 3: Perhaps not, as FILESEXTRAPATHS is only intended to be modified by .bbappend recipes, not base .bb recipes - any comment on that?
Best practices dictate that you accomplish this by using FILESEXTRAPATHS from within a .bbappend file [source].
EDIT 4: PierreOlivier suggests using a relative symlink in the files/ directory to the application's source directory, so that SRC_URI can find the source as if it was actually present in files/. From what I can tell with my own experiments, this does seem to work, and devtool works with this also.
Are there any implications of this approach that I should be aware of?
I like to have the project file untouched unless I make an active decision to add something, so I create the project file using make.
The first instance of the project file is created by quartus_map and I can later add pin declarations etc using quartus_sh.
But I have not found a good way to add an IP block, qip-file, to the project in time since quartus_map need all files to be available.
How can I solve this?
I'm currently using:
quartus_map project_name --analysis_and_elaboration --family=... -f sourcefiles.args
It will not help to add it in the list of source files...
I want to build a file with GNU make on a machine which I have write permission only to the tmp directory.
When I try to build I get a permission error because MAKE is trying to put the object file in the build directory which I have no write permissions for.
is it possible to provide make a specific directory where to put the object files ?
Thanks,
Itay
is it possible to provide make a specific directory where to put the object files ?
If the makefile does not allow specifying a build directory you can copy (or symlink if possible) the sources into the destination directory and build there.
Autoconf-based projects normally allow this kind of usage.
It depends on where your make rules are coming from.
Usually, rules are written to be location independent: they are written such that whether the make command will work regardless of where the source files are. This is true for the built-in rules, but also for the rules in most Makefiles, if you got any.
In that case, all you need to do is copy or move everything into /tmp and run make there.
However, if you generated your Makefiles with a tool (e.g. a ./configure script, as used by GNU autoconf), the generation process may have introduced absolute paths, so you may need to redo the generation step(s) after copying everything to /tmp.
The following script is used to build a specific kernel module.
make modules M=net/sctp
After a second thinking, I've figured out that some of the options were not opened, which is
CONFIG_SCTP_DBG_OBJCNT=y
However, the file that the option control was still not compiled after a "make module" command. Do I need to make the whole kernel to let the option take effects?
All configuration options will be converted into macros and will be written to the file include/generated/autoconf.h once you did make command to build the kernel.
After this when you change any of the configuration option you again need to run the make command which generates required files to include this new configuration options. But if you just use the command "make M=/net/sctp modules" after you change your configuration it will not affect in the make. Instead of building whole kernel what you can do is, just run the "make modules" command which generates the required files and builds your module with the options that you selected. This is the best way which also resolves if there are any dependencies on your newly configured option.
But in your case, if you know that objcnt.c doesn't depend on any other things you can change the make file of the sctp to include your file.
vim net/sctp/Makefile
sctp-y += objcnt.o
Then you can run the "make M=net/sctp modules"
According to https://www.kernel.org/doc/Documentation/kbuild/modules.txt:
To build external modules, you must have a prebuilt kernel available
that contains the configuration and header files used in the build.
[..] use the make target modules_prepare. This will
make sure the kernel contains the information required. The target
exists solely as a simple way to prepare a kernel source tree for
building external modules.
vim .config
make modules_prepare
Answer any kconfig prompts as changes to .config may enable new options that were not manually configured previously.
make M=net/sctp
I am autotoolizing a library project, and this project has some example programs. I want the example programs to be distributed in the dist, but not installed.
Currently the demo programs are organized like thus:
src/*.cpp (library source)
include/*.h (library headers)
demos/demo.cpp (example program)
demos/RunDemo (script to run demo)
It is important that RunDemo be runnable after building the software, without requiring the "install" step.
So far I have been able to build the "demo" exectuable using a noinst_PROGRAMS target. However, after make in a VPATH build, the following is available:
build/src/.libs/libxxx.so (etc..)
build/demos/demo
As you can see, the RunDemo script needed to execute "demo" is not copied to the $(builddir). I have tried a few things, e.g., adding RunDemo to dist_noinst_SCRIPTS, as well as adding my own copy targets and trying to hook all.. no matter what I try, I always get the output,
$ make RunDemo
make: Nothing to be done for `../../../projects/demo/RunDemo'.
I seem to be unable to create a target in the builddir that says "if this file is not in the builddir, copy it from the srcdir."
Is this possible with automake?
You can make files accessible in the build tree after the ./configure step using the AC_CONFIG_LINKS macro (provided with autoconf) in your configure.ac script. It will create a symbolic link if possible, otherwise it will copy the file.
In your case it would look like
AC_CONFIG_LINKS([demos/RunDemo:demos/RunDemo])
From the autoconf manual:
Macro: AC_CONFIG_LINKS (dest:source..., [cmds], [init-cmds])
Make AC_OUTPUT link each of the existing files source to the
corresponding link name dest. Makes a symbolic link if possible,
otherwise a hard link if possible, otherwise a copy. The dest and
source names should be relative to the top level source or build
directory
Using dist_noinst_SCRIPTS is still necessary for the file to be distributed.