Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 342357

Summary: xdc.useModule, xdc.module and xdc.loadPackage introduce unnecessary package cycles
Product: [Technology] RTSC Reporter: Dave Russo <d-russo>
Component: ToolsAssignee: Dave Russo <d-russo>
Status: CLOSED FIXED QA Contact:
Severity: critical    
Priority: P3 CC: ademars, cring, sascha
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:

Description Dave Russo CLA 2011-04-09 16:28:50 EDT 
xdc.loadPackage records references from the current package (calling xdc.loadPackage()) and the package being loaded.  These references are used to determine the order in which package libraries, contributed by getLibs(), are ordered in generated linker command files.

However, xdc.loadPackage, xdc.module, and xdc.useModule are often used to simply get a reference to a module's meta-domain object in order to assign the delegate to a proxy configuration parameter or set a simple config parameter.  In these cases, a circular dependency between packages is often created.  For example, ti.sysbios.family.msp430 contains a TimestampProvider that directly references xdc.runtime modules, but binding this Timestamp provider to the xdc.runtime.LoggerBuf.TimerstampProvider proxy results in a circular dependency between xdc.runtime and ti.sysbios.family.msp430.

Once a circular dependency is created, the tools have no way to determine an appropriate library ordering that does not result in build failures due to undefined references.

Some mechanism for avoiding these circularities needs to be created
Comment 1 Dave Russo CLA 2011-04-09 16:52:08 EDT 
fixed for xdctools 3.22:

xdc.module(), xdc.useModule(), and xdc.loadPackage() each support a optional second Boolean parameter that allows the caller to specify whether the call should (or should not) add a dependency between the caller's package and the referenced package.  If the caller does not specify this parameter the default behavior is:

    xdc.module()      do not create a dependency
    xdc.useModule()   create a dependency
    xdc.loadPackage() create a dependency

If the second parameter is specified and true then _no_ dependency is created (it is a "weak reference" that could otherwise result in a cyclic dependency).

In addition, "implicit" xdc.useModule calls for proxies (automatically performed during package close) no longer create a dependency between the package package containing the module with the proxy and the delegate module's package.
Comment 2 Dave Russo CLA 2011-04-09 17:05:52 EDT 
fixed in r1329.

Note this fix includes changes to xdc.runtime.Diags and Text to remove a circular dependency that arises from these modules needing to reference the package that contains a build of their sources (via xdc.loadPackage()).  This reference is used to determine which version of the xdc.runtime was used when they were built (which may be different from the current xdc.runtime); if the version does not contain the newly added xdc.runtime.Registry module, Registry is silently not used.  This allows existing "rts" packages to be used with new releases of xdctools.  

Eventually we should removed this check (it's slow and it will result in unreported failures for users of the Registry module).