gor.f.gyolchanyan at gmail.com
Wed Oct 26 06:59:34 PDT 2011
This is so cool!!! Package modules have two important roles now:
* Defining the proper imports for the package.
* Defining building rules for the package.
I don't have any particular thoughts about import path and build info
definitions, but I'm certain, that the build rules of parent package
should be overridden by child package (hierarchical build info).
This would reduce building efforts of any D code to zero, as all
necessary info is in the code and all necessary tools are a single
Talk about work productivity! :-)
On Wed, Oct 26, 2011 at 5:39 PM, Martin Nowak <dawg at dawgfoto.de> wrote:
> On Wed, 26 Oct 2011 12:26:56 +0200, Gor Gyolchanyan
> <gor.f.gyolchanyan at gmail.com> wrote:
>> I had a few thoughts about integrating build awareness into DMD.
>> It would be really cool to add a flag to DMD to make it compile and
>> link in all import-referenced modules.
>> Also, it would be awesome to store basic build information in modules
>> themselves in the form of special comments (much like documentation
>> comments), where one could specify external build dependencies, output
>> type, etc.
>> There would be no need for makefiles and extra build systems. You'd
>> just feed an arbitrary module to the compiler and the compiler would
>> build the target, to which that module belongs (bu parsing build
>> comments and package hierarchies).
>> Wouldn't this be a good thing to have?
> Some work in this direction has been done.
> This proposal works by communicating url paths sources to an external
> tool which is a flexible and good proposal.
> It allows things as 'http://path/to/repo' for simple source file from
> web fetching as well as 'pkg://experimental' for more sophisticated package
> manager interaction.
> I've written a prototype implementation some weeks ago.
> This still needs a way to communicated modules to build or link.
> For now I've simply added a pragma(build, <package>) which builds
> every import from this package (globally, it's a prototype).
> Al together it can be used like this.
> There are some issues though that would benefit from good ideas.
> Especially a better solution for import path and build declarations
> would be great.
> DIP14 was not so well received.
More information about the Digitalmars-d