Bugzilla – Full Text Bug Listing
| Summary: | Can't use a Module API name as a project name if xdc/cfg/globals.h is included | ||
|---|---|---|---|
| Product: | [Technology] RTSC | Reporter: | Alan DeMars <ademars> |
| Component: | Tools | Assignee: | Dave Russo <d-russo> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | cring, dfriedland, karl, rowlands, sg |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | target:3.30 | ||
|
Description
Alan DeMars
I suppose the generated headers could always include this header _if_ the symbol 'xdc_cfg__header__' is defined. Provided this header supports multiple inclusions, this will ensure that the header is included _before_ any corrupting symbol definitions in module headers. Provide better error message in this case. Workaround is to include the header file before the module includes. There is a compatible way we could fix this. The include file name is never expanded as a macro if we use the following construction:
$(CC) -Dxdc_cfg__xheader__='"pkgdir/package/cfg/mycfgfile.h"'
The quoting there is specifically double-quotes inside single-quotes. Using this syntax, the preprocessor tokenizes the filename as a string before it gets any chance to expand it. Any other combinations, including anything with angle brackets, will be expanded.
This will end up using a #include with double quotes instead of angle brackets. But for this to find the wrong file because of it, the xdc/cfg directory or the user's source would have to contain exactly the named file. Contrast this to the existing failure mode, which is an "or" of many conditions -- a #define matching any identifier in the pathname will cause the failure.
The change would be implemented in configuro and xdc.bld. There's no change needed to global.h, nor any compatibility impact, since we can just revert to generating the old "xdc_cfg__xheader__" symbol instead of the new "xdc_cfg__header__" one. Customers can still use the newer symbol if they like when building outside RTSC build.
The same problem exists for the target in xdc/std.h, and the same solution too.
*** Bug 406590 has been marked as a duplicate of this bug. *** In order to switch to using "'s rather than <>'s we must be able to pass "'s on both the command line and from within a command file passed to the compiler (to support configuro usage). So, we must either find a syntax that is portable to all compilers and all hosts (Windows, Linux, MacOS) or we must generate toolchain/host '"' escape sequences and leave it to the user to figure out how to get "'s into the compiler (blech!).
A non-portable solution seems to be more problematic than the current portable approach (for both implementers _and_ users). So ...
Three use cases need to be considered:
o package.bld: we generate commands in a makefile that are invoked by make
portable solution
o configuro: we generate a command file containing options that are then
passed (on the command line) to the appropriate compiler
o command line the user must pass options by hand to the compiler when
building a C file that include xdc/cfg/global.h
For package.bld we rely on the fact that xdc ensures that a POSIX shell executes all commands, so we can assume POSIX quote handling to reliably get the string to the compiler on all hosts.
For configuro, the situation is a bit more fragile; every toolchain is free to interpret command files differently so it's quite possible that there is no consistent syntax for embedding quotes in a -D option. However, it appears that the following syntax is portable (to MSVC, gcc, TI C, and IAR icc430):
-Dxdc_cfg__xheader="\"...\""
This same syntax works for both POSIX and Windows cmd.exe command line shells.
fixed in xdc-A21 (XDCtools 3.30)
fixed _just_ the issue with xdc/cfg/global.h by switching to the use of xdc_cfg__xheader__ and using the "\"...\"" syntax (which seems portable, but see previous comment)
Filing separate bug for the same kind of problem in xdc/std.h (which is less susceptible to the conflict.): see
Bug 427756 - potential conflict between user defined macros and target-specific std.h include
Verify Pass 1) using 3.30.0.16 tools, I created a CCS project named 'Task_sleep' 2) I verified that adding the #include <xdc/cfg/global.h> line after the inclusion of Task.h does not cause a problem when the app.c file is compiled. 3) As a sanity test, I built the same project using 3.25 tools and confirmed that the originally reported error occurs: "C:/ti/ccs5.5/xdctools_3_25_02_70/packages/xdc/cfg/global.h", line 39: fatal error #1965: cannot open source file C:/Users/a0868325/workspace_v5_5/ti_sysbios_knl_Task_sleep__E/Debug/configPkg/package/cfg/app_pem3.h" clean out old verified bugs |