How to get stage.install rule to pick up new MSVC-specific type?

[chambm]

A while ago I customized msvc.jam to handle .NET assemblies and building with /clr. Assemblies have to be copied to the same directory as the exe (unlike dll-path where EXE and its dependencies can be separate). Now I've run into an issue where I need to scan the list of assemblies and build a .exe.config file with assembly binding redirects if there are assembly dependencies with mixed versions (e.g. A depends on B v1 and C v2; B depends on C v1). The .config file also needs to be copied alongside the .exe. So if redirects are needed, the .config will exist, if not, it won't. I want to be able to install the .config as a dependency of the EXE but I'm struggling to get the stage.install rule to pay attention to them.

In msvc.jam, I have this:

local rule generate-binding-redirects ( target : sources * : properties * )
{
    local assemblies = [ feature.get-values <assembly> : $(properties) ] ;

    if $(assemblies)
    {
        local exe-path = [ path.join [ on $(target) return $(LOCATE) ] $(target:G=) ] ;
        local exe-config = $(exe-path).config ;
        local cmd = "BindingRedirectGenerator.exe $(exe-config) " ;
        for local assembly in $(assemblies)
        {
            local assembly-path = [ $(assembly).name ] ;
            cmd += [ path.native $(assembly-path) ] ;
        }

        echo $(target:G=) [ SHELL "$(cmd:J= )" : strip-eol ] ;
        DEPENDS $(exe-path) : $(exe-config) ;
    }
}

rule link ( targets + : sources * : properties * )
{
    set-setup-command $(targets) : $(properties) ;
    set-manifest-dependencies $(<[1]) : $(properties) ;
    if <embed-manifest>on in $(properties) && <embed-manifest-via>mt in $(properties)
    {
        if [ feature.get-values <embed-manifest-file> : $(properties) ]
        {
            DEPENDS $(<) : [ on $(<) return $(EMBED_MANIFEST_FILE) ] ;
            msvc.manifest.user $(targets) $(EMBED_MANIFEST_FILE) : $(sources) : $(properties) ;
        }
        else
        {
            msvc.manifest $(targets) : $(sources) : $(properties) ;
        }
    }
    copy-assemblies $(<[1]) : $(properties) ;
    generate-binding-redirects $(<[1]) : : $(properties) ;
}

The generate-binding-redirects part is clunky by using SHELL with a CLI tool I wrote, but it works for me for now because the list of assemblies is fixed in the Jamfiles (if it was a dynamic list, SHELL wouldn't work). So this is correctly generating the .exe.config file alongside the .exe (at the place it's originally linked, not installed).

Elsewhere in msvc.jam, I've registered a config type:

type.register CONFIG : config ;

And in my stage.install rule I've added <install-type>CONFIG. But how do I get the .exe.config conditionally added to the list of sources for the install rule? Do I somehow modify the exe's dependencies in msvc.jam?

[grisumbras]

Can you use this: https://www.bfgroup.xyz/b2/manual/release/index.html#_installing_with_all_dependencies?

[chambm]

You mean <install-dependences>on? I hadn't tried that but I just did and it doesn't seem to do the trick. Does that operate at a higher level than Jam targets (which DEPENDS operates on)?

[chambm]

Is there a more active place to get help with b2? Back in the day some of the regulars hung out in IRC, is that still the case?

[grisumbras]

There's probably no better place, unfortunately.

Have you looked into how PDB files are produced? MSVC linking generator adds them to generate rule's result when conditions are met. This makes overall b2 machinery aware of their existence.

[chambm]

Hot diggity, that did it! Thanks! I had looked at manifests but hadn't thought to look at PDB. I stuck the generate-binding-redirects rule logic into msvc-linking-generator very much like the existing PDB logic. Still creating the .exe.config with a SHELL command, but it'll do for now. The install rule is copying it as desired.

[grisumbras]

BTW, for b2 questions you may also use https://cppalliance.org/slack/, that may result in a more immediate discussion, as it is a chat rather than a forum.