Am 07.10.2014 01:35, schrieb bioinfornatics:
On Monday, 6 October 2014 at 18:15:08 UTC, Sönke Ludwig wrote:
Am 06.10.2014 13:36, schrieb bioinfornatics:
Thanks for your works,

One question, what about makefile support ?


It's still in need for a volunteer. The implementation itself should
be pretty straightforward (by inheriting from the ProjectGenerator
class), but I currently have too much higher priority stuff on my
table to get that done (plus generally severely limited time due to an
accumulation of work and non-work related things).

I take a look but without a hacker doc that is not easy. So I
have some question ( do nott blame me )

Yeah, sorry about that, the API documentation (and parts of the API itself) definitely need some work. So far the focus has been mostly on getting the functionality done and parts of the code are not ready to be considered clean library code.

why class who inherit from ProjectGenerator:
- should to get PackageManager as parameter in ctor (1) while
Project(2) struct has a PackageManager. Project struct is send
too in the ctor.



I think this is mostly historically grown and Project could instead have a "packageManager" getter property.

why method:
generateTargets( in GeneratorSettings settings, in
TargetInfo[string] targets)

take an associative array of targets always you use only one
target named

The "targets" AA is also used in buildTargetRec(), which in turn goes recursively through the dependency graph and queries all of the targets.

why you assign project (3) this is  not done when super is called


That's just garbage left over from a refactoring. I'll remove the m_project field in BuildGenerator.

Reply via email to