Could someone point me towards or post an example of a "non-trivial" package.bld file?

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).

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.

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:

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.

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";

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.

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:

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.

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:

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.