On 05/13/2015 08:01 AM, Sönke Ludwig wrote:

This part is left to the specific ProjectGenerator implementation. See the "build" generator for an example:

https://github.com/D-Programming-Language/dub/blob/acec413687aefcfb76362b22cf439612b9a1743a/source/dub/generators/build.d#L64

In this case it constructs the final target binary path. Other generators, such as the VisualD one may leave this choice up to the IDE/build tool and just forward the linkDependencies accordingly.

I couldn't see how you implemented the --data switch from a quick look, so that the following may not apply. But just to make sure - for any kind of build related information you should write a ProjectGenerator derived class, so that the logic to assemble the build settings is the same as for all other generators. Inside of the overridden generateTargets method it's then possible to extract all necessary information.

In fact, I had recently started to improve dub describe and partially implemented such a special purpose generator class: https://github.com/D-Programming-Language/dub/commits/refactor1
I got distracted by other things, but it probably makes sense to finish that and then base your additions on top of that (at least as far as I understand).

Ok, I see, thanks.

However, as a side note, it does appear that the
dub.project.addBuildSettings function may be redundant with the
project generators. It seems to cover much the same purpose and
functionality that the new TargetDescriptionGenerator will, except with
somewhat less complete/versatile information. Plus, it's only being used
by dub.Dub.testProject and nothing else. So perhaps
dub.project.addBuildSettings should be eliminated and
dub.Dub.testProject adjusted to use TargetDescriptionGenerator?