关于davinci的编译

app的编译主要是configuro的运用

configuro属于预编译阶段，$(PRE_PATH)/xs xdc.tool.configuro -t xxx -p xxx -c $(COMPILER_TOOL_DIR) app.cfg

即可生成app文件夹，文件中有link.cmd compile.opt等连接，编译配置文件，接下来就简单了

输入的文件只需要*.cfg文件，配置的参数：平台，处理器，编译链目录，即可。

app的编译没有用到xdc,xs等编译工具，与路径无关，只要在makefile中设置对xdcpath.mak文件的路径即可

注意：app的编译与*.cfg中的server目录有关，这个要设置正确。

CODEC的编译主要是XDC的运用了

    xdc *.c

XDC暗地里会搜索config.bld   usr.bld  ，在和源文件(.c文件) 一起的必须有package.xdc,package.bld（可以为空）

会生成package.mak 和package文件夹

CODEC的编译与路径有关，利用了package。当移动目录时，所有与之相关的package.xdc的包名要设置。

其中CODEC的文件只能放XDC_PATH包含的目录中（XDC_PATH在文件xdcpath.mak中有定义）

server的编译主要是XDC的运用了

它与一个文件有关：all_codec，编译时会寻找这个文件夹中的all.tcf 。all_codec应该放在../../all_codec这个位子，以makefile为基准。这个文件与bios有关。

此外还要改package中的package.xdc中的包名，要根据路径来设置，这个server文件的位置也要放在XDC_PATH所包含的路径中。

另外*.cfg中的模块路径也要根据codec中的来设置，否则编译不通过。

-------------------------------------------------------------------------------------------------------------------

总结

首先：编译codec 

1.注意codec文件夹放置在XDC_PATH包含的路径下。

2.注意改掉所有在codec文件及其子目录中的package.xdc的包名，根据所在目录来。

接着：编译server

1.注意server文件夹放置在XDC_PATH包含的路径下。

2.注意改掉所有在codec文件及其子目录中的package.xdc的包名，根据所在目录来。

3.修改[server].cfg中用到codec中的模块的路径。

4.all_tcf文件要放到以最低层makefile为基准的../../all_tcf位置

最后：编译app

app与codec、server不同，不是基于xdc编译，主要是configuro 和makefile编译，与包没有关系。

需要注意的是[app].cfg中server的路径设置正确即可。

最近看了一篇比较好的文章

http://blog.csdn.net/wzlang/article/details/8126024

2.codec engine example包中各文件解析
config.bld:
用于定义该example XDC将要编译的targets和环境变量。它设置的是默认的targets和platform，然后通过user.bld进行修改。
注意：该文件一般不需要改动，但要和user.bld保持一致。
该文件在XDC进行编译时控制编译器的选择（ARM或DSP），它只作用于由package.bld XDC 编译出来的二进制文件。XDC 通过该文件找到package的路径，然后找到有更多选项的user.bld文件。
该脚本文件比其他文件最先受到编译。它为目标文件和平台设置了独立的主机系统参数，然后它试图找到设置rootDir的user.bld。
主要内容：DSP target  Linux host target  Arm target 等的设置   load user.bld。

user.bld:
必须修改该文件以设置编译工具的路径
该文件列出了为了哪个目标去编译二进制和程序，每个目标所需要的编译器的位置，和为了哪个平台而编译的程序。你必须详细设置编译工具，并将不需要编译的平台注释掉。
例如：如果你只是对编译evmDm6446上Montavista Arm Linux 下Arm侧的程序，只要将第一个arm下的doBuild设为true，其他设为false。然后详细设置Montavista Arm tools的路径，并注释掉除dm6446之外的平台。


下面列出的是codec中的文件夹，以viddec_copy为例：
package.bld:
当包制造者编译该包的时候，执行package.bld文件。生成的tar文件包含包（包含识别该包的RTSC tools所要求的文件）生成的二进制文件。它还包含一些附加的文件。
在包编译时所需要的源文件和头文件都不包含在发行包中，除非你特别用Pkg.otherFiles加上它们。
例如：Pkg.otherFiles = [
        'src',                /* the whole src subdirectory */
        'include',            /* the whole include subdirectory */
        'readme.txt',
];
这样这些文件会被发行。
如果你想包含库文件，该库文件是编译外面的包所需要的legacy 编译系统，你可以将库文件加在Pkg.otherFiles中。
Pkg.otherFiles = [
'legacy.lib',
'readme.txt',
];
如果你想改变你的cedec中的源文件：var SRCS = ["viddec_copy.c", "other source file", ...];
你也需要改变下面这行来引用你的codec库文件：Pkg.addLibrary("lib/viddec_copy", targ).addObjects(SRCS);
该文件中的target（x86 linux，c64P，arm9）来自config.bld。你可以通过修改user.bld来增加你的target.

package.xdc
该codec说明了Codec Engine最简单的融合。只要求三个文件：
package.xdc：该文件要求声明该包的名字和列出所有可用的接口。
MODULE.xdc:该文件具体说明了该包所提供的codec
MODULE.XS:该文件实现了由ICodec接口要求的函数，这些函数允许codec描述它的非功能性的请求，比如堆大小。
这个包中的其他文件仅仅实现了xDM具体要求的codec。因此将他们整合到codec engine中不需要改变codecs sources。

该文件定义了包的静态变量如它的名字和一些依赖关系。
比如viddec_copy中的package.xdc提到了它所依赖的xDM的VISA API接口：
   requires ti.sdo.ce.video;
然后用下面的声明详细说了这个包所名字是ti.sdo.ce.examples.codecs.viddec_copy  和这个包所包含的单个模块叫VIDDEC_COPY
package ti.sdo.ce.examples.codecs.viddec_copy {
module VIDDEC_COPY;
}


package.xs:
该文件详细说明的包的性质，可以通过平台和配置来改变。如默认的VIDDEC_COPY的package.xs中设置的库名字是这样的：
function getLibs(prog)
{
/* "mangle" program build attrs to directory name */
var name = "lib/viddec_copy.a" + prog.build.target.suffix;
if (prog.build.target.isa == "64P") {
/* return the library name: name.a<arch> */
print(" will link with " + this.$name + ":" + name);
}
else {
name = "";
}
return (name);
}
该函数返回一个package导入的库文件名字。当XDC应用程序用到这个包时，XDC编译系统就调用这个特殊的函数以链接程序配置的包文件系统。导入的库文件不是用housing pakage的编译脚本编译。
上面的函数只有在为DSP server 或只是DSP编译时才返回库文件的名字，如果你编译ARM应用程序不会返回库文件。这就是用这句的所在。
if (prog.build.target.isa == "64P")
如果example codecs包含的库文件是为DSP和ARM一起使用的话，则不需要if语句。dm6446上的例子就是这样的，没有if语句。

VIDDEC_COPY.xdc:

你可以重新命名VIDDEC_COPY.xdc以匹配在package.xdc中用的模块。该文件声明了这个模块是一个可以嵌入codec engine server的codec。因此它详细说明了codec的名字，类型和一些你想定义的额外参数。
该文件详细说明了和codec engine整合所必须的信息。通过继承ti.sdo.ce.video.IVIDDEC,VIDDEC_COPY声明它只是一个video 解码算法。这允许codec engine 自动的为GPP透明的运行DSP提供简单的stubs 和skeletons。
metaonly module VIDDEC_COPY inherits ti.sdo.ce.video.IVIDDEC
除了声明了VIDDEC_COPY算法的类型外，还声明了由xDAIS要求的标志算法实现功能的额外的符号。
/*!
* ======== ialgFxns ========
* name of this algorithm's xDAIS alg fxn table
*/
override readonly config String ialgFxns =
"VIDDECCOPY_TI_VIDDECCOPY";
如果codec需要使用DMA，你应该在该文件中详细说明idma3Fxns vtable symbol的名字。


VIDDEC_COPY.xs:
你可以重新命名VIDDEC_COPY.xdc以匹配在package.xdc中用的模块。该文件应该包含在VIDDEC_COPY.xdc中声明的任何方法的实现。这样分析看来，.xs文件对应.xdc文件就像.c文件对应.h文件一样。
该文件实现了ti.sdo.ce.ICodec接口.这些函数允许配置工具验证用户提供的配置参数。（例如：运行该codec的进程所需要的stack大小）
function getStackSize(prog)
{
if (verbose) {
print("getting stack size for " + this.$name
+ " built for the target " + prog.build.target.$name
+ ", running on platform " + prog.platformName);
}
return (1024);
}

包含：getStackSize ，getDaramScratchSize， getSaramScratchSize