Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » DSDP - Real-Time Software Components (RTSC) » Non-trivial package.bld examples?
Non-trivial package.bld examples? [message #683322] Mon, 13 June 2011 14:16 Go to next message
R Zuber is currently offline R Zuber
Messages: 5
Registered: April 2011
Junior Member
Hello,

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

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.

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');

var TEST_NAMES = ["CalcTest"];

Pkg.otherFiles = [java.lang.System.getenv("TIDSP_REPO_ROOT") + "/ti_libs/IQmath/lib/IQmath_c64x+.lib"];

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.addExecutable(testName, targ, targ.platform).addObjects([testName + ".c"]);
    }
}


Thanks for your time.
(no subject) [message #683374 is a reply to message #683322] Mon, 13 June 2011 15:58 Go to previous messageGo to next message
Dave Russo is currently offline 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"]);
}
}
Re: Non-trivial package.bld examples? [message #683458 is a reply to message #683374] Mon, 13 June 2011 19:41 Go to previous messageGo to next message
R Zuber is currently offline R Zuber
Messages: 5
Registered: April 2011
Junior Member
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?

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.

Thanks again for your help.
Re: Non-trivial package.bld examples? [message #684433 is a reply to message #683458] Wed, 15 June 2011 15:06 Go to previous message
R Zuber is currently offline R Zuber
Messages: 5
Registered: April 2011
Junior Member
I figured out that the first problem can be solved through more linker options "--reread_libs -x";

So in my case the string now looks like this:

Pkg.attrs.lopts = '-l "' + IQLIB + '" --reread_libs -x';
(no subject) [message #684435 is a reply to message #683458] Wed, 15 June 2011 14:59 Go to previous message
Dave Russo is currently offline 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.
Previous Topic:#ifdef for .cfg files?
Next Topic:Packed structures using XDC
Goto Forum:
  


Current Time: Thu Oct 30 16:09:44 GMT 2014

Powered by FUDForum. Page generated in 0.04164 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software