Patch to allow you to see what settings exist "on" a target variable.

Added by John Brandwood about 3 years ago

Problem:

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.

Solution:

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 Magnifier - Patch to add :Q variable modifier. (1.74 KB)


Replies (2)

RE: Patch to allow you to see what settings exist "on" a target variable. - Added by Joshua Jensen about 3 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 3 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.

(1-2/2)