Home » Archived » DSDP - Real-Time Software Components (RTSC) » Non-trivial package.bld examples?
|
| (no subject) [message #683374 is a reply to message #683322] |
Mon, 13 June 2011 15:58   |
 Dave Russo
Messages: 172
Registered: July 2009 |
Senior Member |
|
|
Before trying to answer your questions below, it might help to provide a
bit a background about the xdc.bld objects:
o the Pkg.add* methods are used to specify things that need to be
created/built and added to a release of the current package
o the Pkg properties are set by your build script to control the
build of the package
o the Build.* properties are inputs to the build script that
allow it to know what to add to the package
In general: the Build object is input to your script, Pkg is modified by
your script, and the xdc build system generates a makefile for your
package based on those modifications.
When you add a something to your package, like an executable, you can
specify compiler and linker options to be used when building the files
that make up that executable. Since compiler/linker options required
are different for different compilers, the build system was designed to
enable most projects to be built without having to do this. However,
when dealing with existing code bases that do not follow the RTSC
conventions, it is sometimes necessary to use these options.
Specific answers to your questions are embedded below.
On 6/13/2011 7:16 AM, R Zuber wrote:
> I'm trying to create a top level test program that links to a
> precompiled library (IQmath_c64x+.lib) and to code in another RTSC
> repository outside of where the test program resides. (I only want to
> use this repo for the support testing, not as a dependency of the code
> under test).
>
> Below are how my (relevant) directories are laid out:
>
>
> - MyProjectCode
> +packages
> -ProjectName
> +processes
> -test <=== Test code needs to build here
> - CommonCode
> +TiLibs
> -IQMath
> +Include
> -IQMath.h
> +Lib
> -IQmath_c64x+.lib
> +MyCompanyLibs
> -packages
> +company_name
> -utils
>
>
> I want to have a test program (just like module primer lesson 9) that
> gets built whenever I build the "ProjectName" repository. This test code
> will depend on both IQ Math (straight C library) and MyCompanyLibs (RTSC
> code). For the record "CommonCode" is many levels away from the other
> code in the real directory structure, but its location is accessible via
> an environment variable.
>
>
> I want this to be buildable from the command line without the use of CCS.
> I'm also cheating a bit by setting the /include directory of IQmath in
> my XDC path, which suppresses the "cannot find file error" when I
> #include <IQMath.h> in the code under test. I would like that dependency
> to go away as well.
If you want to reference IQMath.h without any directory prefix, you'll
have to add a -I option to the compiler command line for the source that
use this style of include. This can be done by setting the "incs"
property of either
o the Pkg.attrs object (to apply to all source built in the
package),
o the executable object returned from Pkg.addExecutable (to apply
to all object files to be added to te executable), or
o the only to a specific object file to be added to the executable.
See:
http://rtsc.eclipse.org/cdoc-tip/index.html#xdc/bld/PackageContents.html#attrs,
http://rtsc.eclipse.org/cdoc-tip/index.html#xdc/bld/Executable.html#.Attrs,
http://rtsc.eclipse.org/cdoc-tip/index.html#xdc/bld/Object.html#.Attrs.
In your case, I suspect the following would be best:
Pkg.attrs.incs = "-I <IQ_MATH_PATH/include>";
>
> I'm using XDC Tools version 3_20_08_88. To build my repository, I have
> been running the following command at the root of the "MyProjectCode" repo:
>
>
> xdc --xdcpath=<PATHS_HERE>;<IQ_MATH_PATH/include> all -PR .
>
>
> For reference, my current (non-working / incorrect) package.bld for the
> test program looks like this:
>
>
>
> var Build = xdc.useModule('xdc.bld.BuildEnvironment');
> var Pkg = xdc.useModule('xdc.bld.PackageContents');
> var Executable = xdc.useModule('xdc.bld.Executable');
There is no need to define Executable since it's not used below.
>
> var TEST_NAMES = ["CalcTest"];
>
> Pkg.otherFiles = [java.lang.System.getenv("TIDSP_REPO_ROOT") +
> "/ti_libs/IQmath/lib/IQmath_c64x+.lib"];
>
Pkg.otherFiles is used to include additional files in to any release of
this package; i.e., it will be included in the package's archive when
you build a release release of this package (via "xdc release"). Since
I don't think you mean to do that, the line above should also be removed.
I think you wanted to add this library to the link line of the
executable. This can be done as follows:
/* define IQ lib location */
var IQLIB = java.lang.System.getenv("TIDSP_REPO_ROOT")
+ "/ti_libs/IQmath/lib/IQmath_c64x+.lib";
/* define linker options necessary to use IQ lib */
var attrs = {lopts: '-l "' + IQLIB + '"'};
/* use these linker options when creating the following test */
var exe = Pkg.addExecutable(testName, targ, targ.platform, attrs);
exe.addObjects([testName + ".c"]);
If all executables in your package need to use IQLIB you can simplify
this (like the -I above) by simply setting Pkg.attrs.lopts:
Pkg.attrs.lopts = '-l "' + IQLIB + '"';
> for each (var targ in Build.targets) {
> for each (var testName in TEST_NAMES)
> {
> Pkg.addRepository(java.lang.System.getenv("TIDSP_REPO_ROOT") +
> "/MyCompanyLibs/packages/");
Pkg.addRepository() is used to add a repository into the current
package. Again, I don't think this is what you wanted to do and the
line above should be removed.
> Pkg.addExecutable(testName, targ, targ.platform).addObjects([testName +
> ".c"]);
> }
> }
>
>
> Thanks for your time.
In summary, I think you want something like the following:
var Build = xdc.useModule('xdc.bld.BuildEnvironment');
var Pkg = xdc.useModule('xdc.bld.PackageContents');
var ROOT = java.lang.System.getenv("TIDSP_REPO_ROOT");
var IQLIB = ROOT + "/ti_libs/IQmath/lib/IQmath_c64x+.lib";
var IQINC = ROOT + "/ti_libs/IQmath/include";
Pkg.attrs.incs = '-I "' + IQINC + '"';
Pkg.attrs.lopts = '-l "' + IQLIB + '"';
var TEST_NAMES = ["CalcTest"];
for each (var targ in Build.targets) {
for each (var testName in TEST_NAMES)
{
Pkg.addExecutable(testName,
targ, targ.platform).addObjects([testName + ".c"]);
}
}
|
|
| | |
| (no subject) [message #684435 is a reply to message #683458] |
Wed, 15 June 2011 14:59 |
Dave Russo
Messages: 172
Registered: July 2009 |
Senior Member |
|
|
comments below
On 6/13/2011 12:41 PM, R Zuber wrote:
> Dave,
>
> Thanks for your quick response.
>
> It looks like method you described does indeed add the proper linker
> option. However, it seems to be inserting it into the wrong location in
> the arguments. Looking at package.mak, the (relevant) output is:
>
>
> CalcTest.x64P:
> $(RM) $@
> @$(MSG) lnk64P $@ ...
> $(RM) $(XDCCFGDIR)/$@.map
> $(ti.targets.C64P.rootDir)/bin/lnk6x -w -q -u _c_int00 -fs
> $(XDCCFGDIR)$(dir $@). -l
> "C:/P4/tidsp/ti_libs/IQmath/lib/IQmath_c64x+.lib" -q -o $@
> package/cfg/CalcTest/CalcTest.o64P package/cfg/CalcTest_x64P.o64P
> package/cfg/CalcTest_x64P.xdl -c -m $(XDCCFGDIR)/$@.map -l
> $(ti.targets.C64P.rootDir)/lib/rts64plus.lib
>
>
> Unfortunately, this still does not manage to link to the library,
> because it is declared before the object files are listed. ( see
> gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Link-Options.html ). If I alter
> this manually to put the option at the end of the build string (as
> below) it works fine.
>
>
> CalcTest.x64P:
> $(RM) $@
> @$(MSG) lnk64P $@ ...
> $(RM) $(XDCCFGDIR)/$@.map
> $(ti.targets.C64P.rootDir)/bin/lnk6x -w -q -u _c_int00 -fs
> $(XDCCFGDIR)$(dir $@). -q -o $@ package/cfg/CalcTest/CalcTest.o64P
> package/cfg/CalcTest_x64P.o64P package/cfg/CalcTest_x64P.xdl -c -m
> $(XDCCFGDIR)/$@.map -l $(ti.targets.C64P.rootDir)/lib/rts64plus.lib
> "C:/P4/tidsp/ti_libs/IQmath/lib/IQmath_c64x+.lib"
>
>
>
> Is there any way to control the order these arguments get added?
>
Yes, but the easiest solution is to simply use the -x option, to tell
the linker to rescan the libraries to resolve undefined symbols.
It is also possible to add your libraries to the generated linker
command file. The way to do this is to add a getLibs() function to your
package that returns the path to IQmath_c64x+.lib. This has the
advantage that other packages will be able to use IQMath _without_
having to do _anything_ special.
Every package can define a getLibs() function and this function is
called during generation of the library command file to get a list of
library that should be linked with your application.
You can add a getLibs() to your test package by creating a file named
package.xs that contains something like:
function getLibs(prog) {
return ("C:/P4/tidsp/ti_libs/IQmath/lib/IQmath_c64x+.lib");
}
Obviously you'll want to avoid hard coding the path above but, since the
package.xs file is XDCscript you have a lot of options for this.
See
http://rtsc.eclipse.org/cdoc-tip/index.html#xdc/IPackage.html#get.Libs
for the getLibs() reference or use the search box in RTSCpedia and
search for "getLibs".
See http://rtsc.eclipse.org/docs-tip/The_XDCscript_Language for an
overview of what's possible in XDCscript and the getLibs() function.
> Also, on the alternate repository front, is there any way to temporarily
> add a repository to the XDC path while a test program is being built?
> I'll look through the docs some more too.
>
No. During a build of _everything_ in a package there just one package
path.
However, you can easily control the package path from the command line
when building a package.
> Thanks again for your help.
|
|
|
Goto Forum:
Current Time: Thu Apr 18 11:11:28 GMT 2024
Powered by FUDForum. Page generated in 0.02429 seconds |
] 
Search
Help
Register
Login
Home
