Patch to allow you to see what settings exist "on" a target variable.
With the multiple toolchain support in jamplus-nextgen and jamplus3, compiler settings are no longer global variables that can be easily viewed and debugged.
For instance, settings such a C.CC are now set on the current toolchain $(C.COMPILER_SUITE_SYMBOL) ...
C.CC on $(C.COMPILER_SUITE_SYMBOL) = $(MSVCBIN)cl ;
While jamplus allows you to retrieve a single setting from a target ...
on $(C.COMPILER_SUITE_SYMBOL) current_compiler = $(C.CC) ;
or more recently ...
current_compiler = $(C.CC:Z=$(C.COMPILER_SUITE_SYMBOL)) ;
I haven't been able to find a way to see out what all the settings on any target actually are.
I've written a patch for jam to add a new "query" modifier ":Q" that retrieves a list of the names of all the settings that exist on a target.
For example ...
allsettingslist = $($(C.COMPILER_SUITE_SYMBOL):Q) ;
which might expand to ...
allsettingslist = $(!c.c/win32/debug.info!:Q) ;
You can then use a "for" loop to dump each of the individual settings now that you know what all their names are.
I can't think of why you'd want to do this in the normal course of events, but it can be really useful when debugging compiler/project jamfiles.
The patch has been written/tested on both the nextgen and jamplus3 branches.
addquery.patch - Patch to add :Q variable modifier. (1.74 KB)
RE: Patch to allow you to see what settings exist "on" a target variable. - Added by Joshua Jensen about 4 years ago
I'm not against better debugging facilities, but wouldn't this be better as a built-in called, say,
QuerySettings instead of a variable modifier?
RE: Patch to allow you to see what settings exist "on" a target variable. - Added by John Brandwood about 4 years ago
Hmm ... to be honest, I was looking for the simplest way to get the functionality that I desperately needed to see what-on-earth was going wrong in my .jam files.
For me, that was looking at what you'd done in adding the ":Z" modifier.
The purpose here, and it's functionality, are both intimately tied into looking at a single variable. I'm not sure that making it a built-in and so being able to pass in a list of variables, actually makes any logical sense.
However, I don't really feel strongly enough that I would fight if you ask me to rewrite it as a built-in ... but that may take me some time as I'll have to figure out how to add a built-in.
BTW ... I looked at the "jamming" mailing list, and this basic functionality has been requested a few times by people debugging their .jam files.
BTW2 ... Still not sure why you called your modifier ":Z" instead of ":O" (for "ON") since nearly all the other modifiers are mnemonic.
BTW3 ... It would be lovely if ":Z" was added to the documentation since it's being used quite a bit in the modules.