I am a newbie and I am trying to learn from sourcecodes. Now I have problem understanding (for learn!) autotools: here I have some variables. In this following variable declaration-assignment
mousepad_CFLAGS = \
$(GLIB_CFLAGS) \
$(GTK_CFLAGS) \
$(GTHREAD_CFLAGS) \
$(GTKSOURCEVIEW_CFLAGS) \
$(PLATFORM_CFLAGS) \
-DMOUSEPAD_GSETTINGS_SCHEMA_DIR=\""$(datadir)/glib-2.0/schemas"\"
The variables GLIB_CFLAGS GTK_CFLAGS GTHREAD_CFLAGS GTKSOURCEVIEW_CFLAGS PLATFORM_CFLAGS were not declared. From where their origins?
Also at the bottom there is another undeclared variable reference:
#GSETTINGS_RULES#
Those variables are defined by the configure script when it is run (depending on what configure found and where) and then those variable definitions are inserted into the Makefile generated from Makefile.in.
Related
I am playing around with yocto for a personal project. I have a layer called meta-nightcore which has several files writen in different languages: bash, Python, C, C++ and several recipes.
Is it possible to exclude the meta-nightcore when calling bitbake <image_name> when a user defined variable NIGHTCORE_ENABLED? This variable is set via shell command before calling source oe-init-build-env.
If you have different ideas, can you also share?
Thanks anh Best Regards,
Duy Tran
Yes, you can pass your environment variable into the build environment and then use it to conditionally add the extra layer(s).
You'll need to modify your bblayers.conf to store a default value for NIGHTCORE_ENABLED and to add the extra layer(s) to BBLAYERS if it is set to 1:
NIGHTCORE_ENABLED ?= "0" # overridden by env if specified in BB_ENV_EXTRAWHITE
NIGHTCORE_LAYERS ?= "/path/to/poky/meta-nightcore"
BBLAYERS ?= " \
/path/to/poky/meta \
/path/to/poky/meta-poky \
/path/to/poky/meta-yocto-bsp \
${#bb.utils.contains('NIGHTCORE_ENABLED', '1', '${NIGHTCORE_LAYERS}', '', d)} \
"
Then, you need to tell Bitbake to allow your environment variable to be captured into the Bitbake datastore by adding it to BB_ENV_EXTRAWHITE:
export NIGHTCORE_ENABLED=1
export BB_ENV_EXTRAWHITE="${BB_ENV_EXTRAWHITE} NIGHTCORE_ENABLED"
You can then run bitbake <image_name>.
Because bblayers.conf is usually generated when source oe-init-build-env is run for the first time, you may wish to use TEMPLATECONF to create a bblayers.conf.sample file that already includes this extra logic.
There's some related answers here too:
Is it possible to pass in command line variables to a bitbake build?
I am completely new to using autotools so it might be a dumb question but I'll try anyway. I have two pieces of Makefile.am. Except one is working fine and the other is not.
This works fine.
sbin_PROGRAMS = kernel
kernel_SOURCES = \
src/arch/$(host_cpu)/arch_sysdefs.h \
src/arch/$(host_cpu)/boot.asm \
src/arch/$(host_cpu)/cpu.asm \
src/arch/$(host_cpu)/isr.asm \
src/kmain.cpp
But this doesn't. .asm files are completely ignored by generated Makefile.
if HOST_CPU_X86
ASM_EXT = .asm
else
ASM_EXT = .S
endif
sbin_PROGRAMS = kernel
kernel_SOURCES = \
src/arch/$(host_cpu)/arch_sysdefs.h \
src/arch/$(host_cpu)/boot$(ASM_EXT) \
src/arch/$(host_cpu)/cpu$(ASM_EXT) \
src/arch/$(host_cpu)/isr$(ASM_EXT) \
src/kmain.cpp
What I am trying to do is that I want to use different suffixes for assembly files for some CPUs my project is going to support.
I've also added necessary rule to transform .asm to object files.
.asm.o:
yasm -f $(YASM_OUT_FMT) $< -o $#
EDIT: Temporarily overriding .cpp.o rule with echo $(kernel_SOURCES) reveals that $(ASM_EXT) in kernel_SOURCES is substituted correctly. For example src/arch/$(host_cpu)/boot$(ASM_EXT) becomes src/arch/x86_64/boot.asm for x86-64 CPU and src/arch/arm/boot.S for ARM, etc. Also, setting ASM_EXT variable from autoconf.ac doesn't make any difference.
Here is the related rules for the variable:
LIBAD = libadard.a
install: $(CRSLIB)/$(LIBAD)
$(CRSLIB)/$(LIBAD): $(LIBAD)
$(LIBAD): $(OBJECTS1)
OBJECTS1 = $(LIBAD)(libadardV.o)\
$(LIBAD)(a_delbb.o) $(LIBAD)(a_getbkm.o)\
...
$(LIBAD)(a_getbkm.o): a_getbkm.p \
$(KINCDIR)/dbug.h \
$(PRIMINC)/systypes.h \
$(PRIMINC)/externs.h \
$(PRIMINC)/reserrs.h \
$(KINCDIR)/ltypes.h \
$(KINCDIR)/except.h \
$(PRIMINC)/u_pr_bkmsg.h \
$(CRSINC)/sqlerrs.h \
$(PDBINC)/systypes.th \
$(PRIMINC)/u_pr_bkmsg.th \
$(INFORMINC)/sqlca.h
if i run "make install", here's what i got:
make: *** No rule to make target `/sqlca.h', needed by `libadard.a(a_getbkm.o)'. Stop.
For testing purpose, i added this rule in the makefile just to check the value of this variable $(INFORMINC):
PHONY: all
all: ; #echo $(INFORMINC)
And the output is correct:
mtang#rv02 release>make all
/informix-rv02_1/incl/esql
i also checked under the directory "/informix-rv02_1/incl/esql", the file sqlca.h is there. So what went wrong?
UPDATE:
variable $(INFORMINC) is not defined in this makefile. It is defined in a Makerules file sitting at the root level, and that Makerules is included by this Makefile:
include ../../Makerules
UPDATE 2:
Problem solved. Thanks #Roland Illig for the clue. In Makerules, INFORMINC is defined as:
INFORMIXDIR := $(MY_INFORMIXDIR)
INFORMIX := $(INFORMIXDIR)
INFORMINC := $(INFORMIX)/incl/esql
I just copied that last line where INFORMINC is defined and paste it in the makefile. And it worked. I am not sure if i totally understand the reason behind this, but that certainly gives me some experience to deal with similar problems in the future.
In BSD Make (and I think in many other implementations, too), the dependency lines are evaluated eagerly, at the time of parsing. So when you define the INFORMINC variable at a later point, it will not influence the dependency rule.
The shell command in the all target is evaluated lazily, just before executing it. Therefore you see its value.
See also https://mail-index.netbsd.org/tech-pkg/2016/05/26/msg016900.html, where I explained this topic a litle more verbosely.
scons output (split for readability), relevant commit:
scons: Building targets ...
g++ -o build/XMP/XMPCore/source/ExpatAdapter.o -c -O2 -iquote- -DUNIX_ENV=1 \
-D_FILE_OFFSET_BITS=64 -Ifixes/XMP-Toolkit -IXMP-Toolkit-SDK-CC201306/build \
-IXMP-Toolkit-SDK-CC201306/source/common -IXMP-Toolkit-SDK-CC201306/XMPCore/source \
-IXMP-Toolkit-SDK-CC201306/source/XMPFiles \
-IXMP-Toolkit-SDK-CC201306/source/XMPFiles/FileHandlers \
-IXMP-Toolkit-SDK-CC201306/source/XMPFiles/FormatSupport \
-IXMP-Toolkit-SDK-CC201306/third-party/MD5 \
-IXMP-Toolkit-SDK-CC201306/public/include \
XMP-Toolkit-SDK-CC201306/XMPCore/source/ExpatAdapter.cpp
XMP-Toolkit-SDK-CC201306/XMPCore/source/ExpatAdapter.cpp:9:77: fatal error:
public/include/XMP_Environment.h: No such file or directory
#include "public/include/XMP_Environment.h" // ! Must be the first #include!
^
It seems XMP started using relative includes in files rather than relying on compiler options. How do I handle this new include style in SCons?
(Background: When trying to compile dcp2icc (using a Makefile based on the original ReadMe.txt) I got a bunch of errors like 'strlen' is not a member of 'std', which seems to be because of an include clean-up in GCC. Rather than patch a bunch of third party libraries I decided to try a newer version of XMP.)
You should try to solve this include fail pretty much the same as you would on the command-line: by adding the missing include path, which in your case seems to be "-IXMP-Toolkit-SDK-CC201306". So, add your origXMP to the CPPPATH as well...
So, I've got that makefile project that has a huge list of object files that need to be compiled.
I already ran into problems on Win32 because the input string is too large. I figured out that instead of passing the files 1-by-1 to the linker, I could read the object files to be linked from a file by passing #filename to the linker.
In my makefile: Is there a method how the dependencies could be read out of a file? Something like that:
main.lib: #dependency_file_name
where dependency_file_name holds the list of needed .obj files needed to create the lib.
Please keep in mind, that putting the contents of the file into a variable also doesn't work since I've got that problem with a too long input string also when using the list of dependencies as a variable.
In addition: the method shall be portable (Linux, Win32)
Edit: currently, the structure of my makefiles is as follows:
# slurp in some global settings
include /path/to/global/settings
all: prepare_target mylib cleanup_target
prepare_target:
# do preparing work (setup temp files etc)
cleanup_target:
# do cleanup work (delete temp files etc)
mylib: \
file1.obj \
file2.obj \
... \
file215.obj
# this file holds the dependencies for each .obj file
include file_with_obj_file_dependencies
There are really 215 C files to be compiled into this lib. As I said: when feeding this list to the linker, I need to do it via a file because the string is too large for the command line.
I'm free to change whatever is needed in the makefile: it's generated from a VisualStudio vcxproj and I own the generation templates.
file_with_obj_dependencies looks as this:
file1.obj: \
file1.c \
file1.h \
file2.obj: \
file2.c \
file2.h \
... \
file215.obj \
file215.c \
file215.h \
On Windows I tend to use cygwin. It's the closest environment I've found to unix. This makes your Makefiles portable. I haven't come across any limiting command-line length limits. Here is an example with over ¾ of a million command-line arguments:
a := 1 2 3 4 5 6 7 8 9 a b c d e f
.PHONY: test
test:
#echo $(foreach A,$a,$(foreach B,$a,$(foreach C,$a,$(foreach D,$a,$(foreach E,$a,$A$B$C$D$E))))) | wc -wc
(the wc is so that you don't have to wait for the 5,000,000 or so characters to scroll by.)
So, for the limited win32 tools, use bash to write the intermediate command-line-parameters file, then pass that to link.exe (say) prefixed with an #.
Something like:
mylib.lib:
echo $^ >$#-tmp
link -o $# #$#-tmp
(Are you sure you need the intermediate file? 215 source files doesn't seem too onerous.)