This is about HEVC encoder and decoder
I have
** encoder and decoder in debug mode
** encoder and decoder in release mode
I know release mode optimize something.
Can we use debug encoder and release decoder?(I have not verified this)
How about release encoder and debug decoder? (I try this, it is OK)
I guess both should be OK, but I still want to know why yes or why not in the theoretical level.
Not entirely sure what you asking but if you e.g. look at the linux makefile, you'll see this:
debug:
$(MAKE) -C lib/TLibVideoIO debug MM32=$(M32)
$(MAKE) -C lib/TLibCommon debug MM32=$(M32)
$(MAKE) -C lib/TLibDecoder debug MM32=$(M32)
$(MAKE) -C lib/TLibEncoder debug MM32=$(M32)
$(MAKE) -C lib/TAppCommon debug MM32=$(M32)
$(MAKE) -C app/TAppDecoder debug MM32=$(M32)
$(MAKE) -C app/TAppEncoder debug MM32=$(M32)
$(MAKE) -C utils/annexBbytecount debug MM32=$(M32)
$(MAKE) -C utils/convert_NtoMbit_YCbCr debug MM32=$(M32)
release:
$(MAKE) -C lib/TLibVideoIO release MM32=$(M32)
$(MAKE) -C lib/TLibCommon release MM32=$(M32)
$(MAKE) -C lib/TLibDecoder release MM32=$(M32)
$(MAKE) -C lib/TLibEncoder release MM32=$(M32)
$(MAKE) -C lib/TAppCommon release MM32=$(M32)
$(MAKE) -C app/TAppDecoder release MM32=$(M32)
$(MAKE) -C app/TAppEncoder release MM32=$(M32)
$(MAKE) -C utils/annexBbytecount release MM32=$(M32)
$(MAKE) -C utils/convert_NtoMbit_YCbCr release MM32=$(M32)
And if you follow the makefiles, you eventually end up in makefile.base which contains the following part:
#
# debug cpp flags
DEBUG_CPPFLAGS = -g -D_DEBUG
#
# release cpp
RELEASE_CPPFLAGS = -O3 -ffloat-store -Wuninitialized
so there you have the differences between debug- and release-mode. The generated and reconstructed bitstreams will be identical regardless of you use the debug-binary or the release-binary.
You are perfectly fine mixing debug and release binaries.
Hope it helps...
The HEVC bitstream generated by debug and release builds of the encoder should be identical. Also the behavior of the decoder should be the same in both build variants. There are no formal test in the development process, but I have never experienced any problems with that in HM.
If you find a case where this is not true, that would be considered to be a bug and should be reported in the bug tracker.
Related
I am kinda rookie in makefile field but trying to write makefile that would go in two modes: normal mode make outputing executable file called say bingo depending on some files and a mode make debug outputing executable file called bingo.debug that shall be compiled with debug option. I'm trying to use target variable with the following result:
PROGRAM = bingo
SUFIX = .debug
CC = gcc
CFLAGS = -Wall -O2
DEBUG = -g -D DEBUG
all: $(PROGRAM)
debug: CFLAGS += $(DEBUG)
debug: PROGRAM += $(SUFIX)
debug: all
file1.o: file1.c file1.h
$(CC) -c $(CFLAGS) -o $# $<
file2.o: file2.c file2.h
$(CC) -c $(CFLAGS) -o $# $<
$(PROGRAM).o: $(PROGRAM).c
$(CC) -c $(CFLAGS) -o $# $<
$(PROGRAM): file1.o file2.o ($PROGRAM).o
$(CC) -o $# $^
.PHONY: all clean
clean:
rm -rf $(PROGRAM) *.o
It looks like make debug correctly compiles the file with debug flags but it does not change the file name (i.e. both modes outputs the same bingo file). Any help much appriciated!
You cannot use target-specific variables in targets. The documentation is very clear that they are available only in recipes.
In general it's problematic to do things this way, because make has no idea which objects were built with debug and which weren't. If you forget to do a complete clean and/or run make the wrong way then you'll get a mix of different object files: some compiled with debug and some not.
Instead, you should put your debug object files in a different directory from your non-debug object files so you don't have to worry about that.
The challenge is to create a makefile which takes a list of modules and does not require me to sort out precendence. For example, the modules are
mod allocations.f08 mod precision definitions.f08 mod unit values.f08
mod blocks.f08 mod shared.f08 mod parameters.f08
mod timers.f08
The main program is characterize.f08. The error message is
Fatal Error: Can't open module file ‘mprecisiondefinitions.mod’ for reading at (1): No such file or directory
The first statement in the main program is use mPrecisionDefinitions, the module defined in mod precision definitions.f08.
The following makefile, based upon Creating a FORTRAN makefile, is:
# compiler
FC := /usr/local/bin/gfortran
# compile flags
FCFLAGS = -g -c -Wall -Wextra -Wconversion -Og -pedantic -fcheck=bounds -fmax-errors=5
# link flags
FLFLAGS =
# source files and objects
SRCS = $(patsubst %.f08, %.o, $(wildcard *.f08))
# program name
PROGRAM = a.out
all: $(PROGRAM)
$(PROGRAM): $(SRCS)
$(FC) $(FLFLAGS) -o $# $^
%.mod: %.f08
$(FC) $(FCFLAGS) -o $# $<
%.o: %.f08
$(FC) $(FCFLAGS) -o $# $<
clean:
rm -f *.o *.mod
For starters, I recommend to replace all spaces in your file names with underscores or something similar.
Spaces are almost universally used as separators, and any program that is started with something like
gfortran -c -o mod precision definitions.o mod precision definitions.f08
would interpret this line as 'create an object file called mod from the source files precision, definitions.o, mod, precision, and definitions.f08. And while there are ways to do it, with increasing automation, you have to jump more and more hoops.
In contrast, this works well:
gfortran -c -o mod_precision_definitions.o mod_precision_definitions.f08
I would use this command to change all the spaces into underscores:
rename 's/ /_/g' *.f08
If that doesn't work, use this command:
for f in *.f08; do mv "$f" ${f// /_}; done
Next, I wouldn't worry about .mod files. They get generated together with the object files when you compile a module. So while technically some routine that uses a module requires the .mod file for that module, you might as well claim in your Makefile that it depends on the object file itself.
So with that said, here's the Makefile I would use (with some assumed inter-module dependencies added):
# Find all source files, create a list of corresponding object files
SRCS=$(wildcard *.f08)
OBJS=$(patsubst %.f08,%.o,$(SRCS))
# Ditto for mods (They will be in both lists)
MODS=$(wildcard mod*.f08)
MOD_OBJS=$(patsubst %.f08,%.o,$(MODS))
# Compiler/Linker settings
FC = gfortran
FLFLAGS = -g
FCFLAGS = -g -c -Wall -Wextra -Wconversion -Og -pedantic -fcheck=bounds -fmax-errors=5
PROGRAM = characterize
PRG_OBJ = $(PROGRAM).o
# make without parameters will make first target found.
default : $(PROGRAM)
# Compiler steps for all objects
$(OBJS) : %.o : %.f08
$(FC) $(FCFLAGS) -o $# $<
# Linker
$(PROGRAM) : $(OBJS)
$(FC) $(FLFLAGS) -o $# $^
# If something doesn't work right, have a 'make debug' to
# show what each variable contains.
debug:
#echo "SRCS = $(SRCS)"
#echo "OBJS = $(OBJS)"
#echo "MODS = $(MODS)"
#echo "MOD_OBJS = $(MOD_OBJS)"
#echo "PROGRAM = $(PROGRAM)"
#echo "PRG_OBJ = $(PRG_OBJ)"
clean:
rm -rf $(OBJS) $(PROGRAM) $(patsubst %.o,%.mod,$(MOD_OBJS))
.PHONY: debug default clean
# Dependencies
# Main program depends on all modules
$(PRG_OBJ) : $(MOD_OBJS)
# Blocks and allocations depends on shared
mod_blocks.o mod_allocations.o : mod_shared.o
I am writing a sample application on Mac OS X using Cocoa.
Things were fine when I was using Xcode to built and debug.
But when I started building by makefile, program is same, every file is same (as shown by diff), output is different.
My first question: Is this makefile to build a cocoa project correct?
Make file is:
CLANG = /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
LINK = /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
ARCH = x86_64
MIN_VERSION = 10.8
DEBUG_PATH = bin/debug
SYSROOT = /Applications/Xcode.app/Contests/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/
IBTOOL = /Applications/Xcode.app/Contents/Developer/usr/bin/ibtool
SDK = /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk
FRAME = /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks
LIB = /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib
FLAGS = -g -O0
debug: $(DEBUG_PATH)/test.app
run:
open $(DEBUG_PATH)/test.app
$(DEBUG_PATH)/test.app: $(DEBUG_PATH)/test
cp $(DEBUG_PATH)/test $(DEBUG_PATH)/test.app/Contents/MacOS/test
cp en.lproj/credits.rtf $(DEBUG_PATH)/test.app/Contents/Resources/en.lproj
cp en.lproj/InfoPlist.strings $(DEBUG_PATH)/test.app/Contents/Resources/en.lproj
cp PkgInfo $(DEBUG_PATH)/test.app/Contents/
rm -f $(DEBUG_PATH)/test
cp test-core-text-Info.plist $(DEBUG_PATH)/test.app/Contents/Info.plist
touch $#
$(DEBUG_PATH)/test: $(DEBUG_PATH)/AppDelegate.o $(DEBUG_PATH)/main.o
mkdir -p $(DEBUG_PATH)/test.app/Contents/MacOS/../Resources/en.lproj
$(CLANG) -arch $(ARCH) -isysroot $(SYSROOT) -L$(DEBUG_PATH)/ -L$(LIB) -mmacosx-version-min=$(MIN_VERSION) AppDelegate.o main.o -framework Cocoa -o $# -F $(FRAME)
$(IBTOOL) --errors --warnings --notices --output-format human-readable-text --compile $(DEBUG_PATH)/test.app/Contents/Resources/en.lproj/MainMenu.nib en.lproj/MainMenu.xib --sdk $(SDK)
clean:
rm -rf $(DEBUG_PATH)/test.app
rm -f $(DEBUG_PATH)/*
$(DEBUG_PATH)/AppDelegate.o: src/AppDelegate.m
$(CLANG) -arch $(ARCH) $(FLAGS) -Wall -c $< -o $#
$(DEBUG_PATH)/main.o: src/main.m
$(CLANG) -arch $(ARCH) $(FLAGS) -Wall -c $< -o $#
Output of Xcode (run app from anywhere)
Output by makefile
It is still conundrum to me that the program is same, Info.plist is same, nib is same, why the output is different.
What is the thing I am missing?
I am asked to write a Makefile which needs to selects between two compilers, and each of these compilers should support 3 build versions (debug, release, test).
There are a lot of variables that change based on input (compiler, compiler options, output directory, include directories etc). My first option was to go through target-specific variables and configure variables according to target. Do you think this is good idea?
I am not extremely familiar with those kind of variables. It seems to me that if I do something like this:
release: variable1=value1 #release is target
release: variable2=value2
release:
# some compilation rule
Only the variable1 will be configured. Am I right about this?
Update
Thank you for your reply. I am trying to deal with compiler selection issue through additional variable which would be configured according to target. But, here is the problem. I have the following lines:
release: CFLAGS = -DCORE_SW_VERSION='"$(CORE_SW_VERSION)"' -Wall
release: CFLAGS += -fgnu89-inline -mno-volatile-cache $(INCLUDE)
release: TARGET=release
After this lines, I do some ifeq sequence in which I decide which compiler to use (according to TARGET variable value).
And CFLAGS is configured properly, but the TARGET variable is empty. This leads me to conclusion that you can configure only one target-specific variable. Am I right? If not, I am not aware what I am doing wrong. Could you please help me?
Target-specific variables are defined only when building that target and any prerequisites of that target. You can't use target-specific variables arbitrarily throughout the makefile (as it sounds like you're trying to do with ifeq). For that, you may want to look at $(MAKECMDGOALS). I don't believe there is any limit on the number of target-specific variables, certainly not a limit of one.
Needing either target-specific variables or $(MAKECMDGOALS) may be a warning that you're trying to do coerce make into doing something it wasn't meant to do.
It's not clear to me whether you want to build three versions (debug/test/release with a single compiler for each one), or six versions. Assuming three, here is a unix-y Makefile to build with different compilers and CFLAGS depending on the target. However, note that this could just as easily be coded with RELEASE_CFLAGS, RELEASE_CC, DEBUG_CFLAGS, etc... variables.
all: release debug test
release: CC=gcc
release: CFLAGS=
debug: CC=gcc
debug: CFLAGS=-g
test: CC=cc
test: CFLAGS=-Wall
.PHONY: release debug test
release: release/exe
debug: debug/exe
test: test/exe
OBJECTS := test.o
release/%.o: %.c
$(CC) $(CLFAGS) -c -o $# $<
debug/%.o: %.c
$(CC) $(CLFAGS) -c -o $# $<
test/%.o: %.c
$(CC) $(CLFAGS) -c -o $# $<
release/exe: $(OBJECTS:%=release/%)
$(CC) $(CFLAGS) -o $# $^
debug/exe: $(OBJECTS:%=debug/%)
$(CC) $(CFLAGS) -o $# $^
test/exe: $(OBJECTS:%=test/%)
$(CC) $(CFLAGS) -o $# $^
When I run make on the following Makefile, when is the symbol table built, if it even is?
LEX = flex
YACC = yacc
CC = gcc
calcu: y.tab.o lex.yy.o
$(CC) -o calcu y.tab.o lex.yy.o -ly -lfl
y.tab.c y.tab.h: parser.y
$(YACC) -d parser.y
y.tab.o: y.tab.c parser.h
$(CC) -c y.tab.c
lex.yy.o: y.tab.h lex.yy.c
$(CC) -c lex.yy.c
lex.yy.c: calclexer.l parser.h
$(LEX) calclexer.l
clean:
rm *.o
rm *.c
rm calcu
make doesn't build symbol tables (obviously the compilers and linkers it invokes will have to do that!). I'll assume you're referring to whatever the resulting calcu binary does wrt its input, instead.
If any such thing as a "symbol table" is ever built by calcu, it will be by code you inserted into parser.y that gets moved over into yacc.tab.c; as to when, it will be during the course of a calcu run over whatever its input is -- incrementally, as each syntax production including "symbol-table building code" matches.