This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
When compiling a SYS/BIOS project, XDC is called (launched) to compile the SYS/BIOS configuration file. This is technically an external process, I know, but is there any way to access the project's build/environment variables? (${PROJECT_BUILD_DIR}, ${build_artifact}, etc.) It seems odd that CCSv4/CCSv5.1 does not inject them into the spawned task's environment like all other development IDE's do, so I am hoping that I am just getting stumped by some dumb error or oversight on my part.
I've tried walking the system's environment via java.lang.System.getenv() and the like, and I have also looked into importing the xdc.bld.BuildEnvironment module, but in the latter, the XDCtools help file does not really define a way to access the actual environment variables.
As a background, I need a way to statically configure SYS/BIOS (i.e., via the project's RTSC configuration file) based on whether it's a release build or a debug build. Not that I would want to maintain two separate files (definitely not!), but even that is not an option as CCS removes the option to "Exclude from Build" in the context menu for .cfg files.
Now, I have rewritten a function to parse the "user.dir" environment variable (i.e., environment["user.dir"]) to determine my build type based on the current build directory, and this works, but I would still like a cleaner approach by simply accessing the project's build variables. (For instance, there are other conditional flags I want to use other than simply release vs. debug.)
Is this possible, and if so, how?
Alex,
The project variables are not environment variables but are really just string substitution macros. CCS will swap in the values for the macros when generating the makefile for the build.
I talked to our main build guy and he had a suggestion that may work for you. You could in your project have it set an environment variable to the value of a macro like in the capture below.
John
No, I already tried that. Your build guy could verify this, but my guess is those "user" variables are only passed to the shell when compiling source (.c/.cpp) files. That said, just now I tried adding it to the XDCtools properties (via "XDCtools/Advanced Options/Java properties (-D)"), and it works.
I added "MY_TEST_VARIABLE=${PROJECT_BUILD_DIR}" (without the quotes), and then in my SYS/BIOS cfg file I added the following lines:
print( "*******************************************" );
print( "MY_TEST_VARIABLE = '" + environment["MY_TEST_VARIABLE"] + "'" );
print( "MY_TEST_VARIABLE = '" + java.lang.System.getenv("MY_TEST_VARIABLE") + "'" );
print( "*******************************************" );
When compiling, the output was as follows:
*******************************************
MY_TEST_VARIABLE = 'J:/projects/TestProjects/dsp/CfgTest/.dbg'
MY_TEST_VARIABLE = 'null'
*******************************************
Sweet!
Ultimately, though, my true goal is to be able to access the project's C/C++ defines since any conditional compilation needs to be system-wide, and maintaining two separate conditional flags (one in the C/C++ properties and one in the XDCTools properties) is risky. (Think "nullifying a heap handle in the .cfg file" but forgetting to compile out accesses to it in the code.")
Should I just assume this is currently not possible, or is there some trick I haven't thought of?
Alex,
No tricks for accessing teh C/C++ -D settings.
Note that you can have .cfg files excluded per configuration. In CCSv4 the context menu to exclude the file from the config is there, in CCSv5 it is more buried, you need right click and select properties and then click on CCS Build and you will see the option. Maybe you could have separate top level files that included others, probably easier doing what you are doing now though.
On the environment that really should be getting set for any shell CCS spawns. Maybe that is a bug on our side. I will have to get back with him on that.
Regards,
John
My apologies. Your original solution does work as advertised. The options are laid out a little differently in CCSv5, and I was adding it as a "Build" variable, not an "Environment" variable. Sorry. When set correctly, it is now visible via a java.lang.System.getenv() call.
I just wish there were a way to access environment variables in C via a #ifdef/#endif pragma. :-(