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.
generateTargets( in GeneratorSettings settings, in
take an associative array of targets always you use only one
target named m_project.rootPackage.name
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.