I want to know where in the code buildroot exports the configuration symbols so that they can be read in the .mk for each package:
Example:
In the package exim.mk there is a test on BR2_PACKAGE_OPENSSL value:
ifeq ($(BR2_PACKAGE_OPENSSL),y)
The symbol is defined in the .config, but how exim.mk read it
Buildroot is based on the make build system. make reads in the top-level Makefile, and parses the include directives in that file. One such directive is
-include $(BR2_CONFIG)
The BR2_CONFIG variable expands to .config (either in the Buildroot directory, or in the output directory if O= is given). The .config file contains all the configuration options that you selected using the Kconfig infrastructure.
Next, the top-level Makefile has
include $(sort $(wildcard package/*/*.mk))
This reads in all the .mk files in the package directory, including exim.mk. So when exim.mk is parsed, the BR2_PACKAGE_OPENSSL value set in .config will be evaluated. This can be either
BR2_PACKAGE_OPENSSL=y
if the option was selected, or
# BR2_PACKAGE_OPENSSL is not set
if it was not selected. So the condition will be true in the first case and false in the second case.
Related
This question already has answers here:
Building a kernel module from several source files which one of them has the same name as the module
(6 answers)
Closed 1 year ago.
I'm trying to build a loadable kernel module that includes another source file. I have the following in a Makefile or Kbuild file:
obj-m += mymodule.o
mymodule-y += other_src_file.o
In this scenario, other_src_file.c will be compiled. Strangely, the main source file mymodule.c will not be compiled. Intentional syntax errors are not caught. An object file mymodule.o is still produced, as is the .KO file. Loading this module on the target platform has no effect.
If I instead remove the second line in the Makefile/Kbuild that includes the other source file, my intentional syntax errors are caught. In a minimal example, init_module() will run and dmesg shows what I put into printk. It would not print anything prior to removing the line with other_src_file.o, despite being unchanged.
So what I find is that by including an additional source file (whether it is being used or not), the main module/C file is effectively ignored. An LKM is produced, but it has no effect from what I can see. Using --debug confirms in the latter case that mymodule.c is used (pipe into grep returns literally anything) whereas the former shows that there is not a single reference to mymodule.c (but many to other_src_file.c)
I've also tried setting up the makefile as the following, but there's no behavioral difference.
obj-m += mymodule.o
mymodule-y += other_src_file.o
all:
make -C ../../../ M=($PWD) modules # -C points to the root of my kernel
clean:
clean -c ../../../ M=$(PWD) clean
The output of make looks like the following:
LD some/path/mymodule/built-in.o
CC[M] /some/path/mymodule/other_src_file.o <-- notice it's the only CC; nothing for mymodule.o
LD[M] /some/path/mymodule/mymodule.o
Building modules, stage 2
MODPOST 1 modules
CC /some/path/mymodule/mymodule.mod.o
LD[M] /some/path/mymodule/mymodule.ko
When that other src file is left out, there is a line that shows mymodule.o being compiled.
I'm running in an Ubuntu 20.04 (VM) on x86_64. The kernel is 3.1.10, make is 4.2.1.
I feel like I'm missing something simple (unfamiliar with linux building, fairly familiar with C and compiling otherwise). Would greatly appreciate a pointer here.
The line
obj-m += mymodule.o
tells KBuild system just to build a module named mymodule.
The sources compiled into that module depend from variable mymodule-y:
If the variable is set (like in your code), then source list it taken only from this variable. There is no "automatic" addition of mymodule.c source.
If the variable is not set, then, by default, the module is compiled from the source which has the same name.
Note, that one cannot build a module mymodule from several sources, one of which is mymodule.c, that is has the same name as the module itself.
Either module or the source file should be renamed. That situation is described in that question.
I have a project with source tree:
src/
src/A/
src/A/A.hs
src/B/
src/B/C/
src/B/C/C.hs
...
The two haskell files divide source code into modules:
-- File A/A.hs
module A where
...
and
-- File B/C/C.hs
module B.C where
...
The cabal file contains:
other-modules: A, B.C, ...
hs-source-dirs: src/, src/A/, src/B/, src/B/C/, ...
But while the module A can be easily found, cabal complains about B.C:
cabal: can't find source for B/C in ...
I see no rational explanation why placing a file defining module A under A/A.hs is OK but placing B.C under B/C/C.hs isn't. Is there a workaround other than placing C.hs directly under B (I would like to maintain some separation of sources)?
The reason for the error is that module B.C should be defined in file B/C.hs, not B/C/C.hs (that would be module B.C.C). This error would have appeared if you had only one source dir with one source file, it is not because of the extra parts you have put in.
Also, the dir that appears in the hs-source-dirs directive should only be the root of the dir tree, so it is doubtful that you need all of the parts that you put in, for instance, src/B/C (which would treat src/B/C as another root.... meaning you can define top level modules in that dir. If you are actually doing that, I would consider this a mistake).
What you probably want to do is define multiple top level source dirs, like this
A_src/A.hs
B_src/B/C.hs
hs-source-dirs: A_src, B_src
Even better, I would suggest you use stack, which allows you to separate different modules completely with their own source dirs, called src, and independent .cabal files, allowing for richer dependencies between each module.
Say we have a command call foo in CMakeLists.txt which is in folder /A.
foo is defined in antother CMakeLists.txt which is in folder /B.
How can one reference to /B/CMakeLists.txt from within /A/CMakeLists.txt in order to call foo?
I tried to set search paths to /B/CMakeLists.txt via:
CMAKE_INCLUDE_PATH
CMAKE_MODULE_PATH
CMAKE_SOURCE_DIR
but none of them worked.
CMake still complaines Unknown CMake command "foo".
That can be done with include, here's some simple example:
Content of A/CMakeLists.txt
function(foo)
message(STATUS "heya")
endfunction()
Content of B/CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
include(${CMAKE_CURRENT_SOURCE_DIR}/../A/CMakeLists.txt)
foo()
Now, including another CMakeLists.txt will also run everything in that file, so you may want to avoid doing that if there are targets in B/CMakeLists.txt
If you can modify your code, it would be better to define your functions in a "top level" CMakeLists.txt before calling add_subdirectory.
If this files just contains functions definitions you should not call it CMakeLists.txt, but some_adequate_name.cmake
Than you can include it where you need those functions definitions using include.
How can I add prerequisite rule for all source files (c/cpp)? It would be simple if entire make file was done by me, but I use android build system that hides most of the stuff from me.
The reason I want to do it:
I added a rule to generate my header file which is included by some c/cpp files. It works well as long as dependencies are already generated. However, with a clean project there is no dependency info available before compilation and as a result make won't run my rule for a clean project because it doesn't know that certain cpp file depends on a header file that doesn't exist yet. That's why I need to add some kind of rule to ensure that my prerequisite rule runs before any compilation takes place.
So far, I did this:
include $(CLEAR_VARS)
.PHONY: ForceRule
MyHeader.h: ForceRule
ForceRule: CreateHeader.sh
$(shell CreateHeader.sh MyHeader.h)
# below is standard android way to build shared lib from cpp files:
LOCAL_SRC_FILES: File1.cpp File2.cpp
LOCAL_PATH := $(CURDIR)
include $(BUILD_SHARED_LIBRARY)
It's hard to be sure with black-box makefiles (and I think your approach is wrong), but you could try this:
MyHeader.h: CreateHeader.sh
$(shell CreateHeader.sh MyHeader.h)
%.o: %.cpp MyHeader.h
I have non system headers, which I use to compile a program via SCons. Problem is they sometimes change but SCons does not seem to scan for changes in the headers at all.
Is there a way to tell SCons to scan the headers for changes?
Assuming you're talking about c/c++, SCons should always scan the header files, assuming the include paths have been correctly set to do so.
If the include paths have been specified with the CPPPATH construction variable, then the include files in that path will be scanned for changes. The include paths specified with this variable should not have the -I prepended, as SCons will do that in a portable manner.
This variable can be appended to as follows:
env = Environment()
# These paths WILL BE scanned for header file changes
env.Append(CPPPATH = ['path1', '/another/path', 'path3'])
If the include paths have been specified in the CCFLAGS or CXXFLAGS construction variables, then the include files in that path will not be scanned for changes. The include paths specified in either one of these variables must have the -I prepended. This approach is beneficial when specifying system header include paths that will most likely never change, thus speeding up the build process.
Paths can be appended to the CXXFLAGS variable:
env = Environment()
# These paths will NOT be scanned for header file changes
env.Append(CXXFLAGS = ['-Ipath1', '-I/another/path', '-Ipath3'])
Here is a list of the rest of the SCons construction variables.