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: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 overriddengenerateTargets
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?