View mode: basic / threaded / horizontal-split · Log in · Help
January 27, 2007
Re: Creation of a Build tool on top of the D compiler
Reply to kris,

> BCS wrote:
> 
>> what If I have a 200+ module project that take ten minutes to compile
>> (lots of templates say) a build only what's needed strategy is still
>> needed. having bud walk the whole tree and still only build what is
>> needed is still useful. I don't think /that/ functionality should go
>> into the compiler.
>> 
> Yes, I agree. The compiler should still handle the basic requirement
> though. After all, currently loads /and/ parses every single one of
> those 200+ modules regardless (if they're imported in any fashion)
> 

If all imports are private then compiling module N only requiters parsing 
only the modules that N imports. Also lex/parse/syntax isn't all that compiling 
requiers.
January 27, 2007
Re: Creation of a Build tool on top of the D compiler
Reply to Derek,

> On Sat, 27 Jan 2007 00:24:09 +0100, Frank Benoit (keinfarbton) wrote:
> 
>> Now we have dependency information in the verbose output of DMD. But
>> one thing is still missing:
>> 
>> pragma( lib, "mylib.so" );
>> 
>> Can we have that in the output also?
>> "pragma<\t>lib<\t>mylib.so"
> Just a reminder that this sort of thing might be placed into a D
> compiler 

vote--

> but it should /not/ be a part of the D Programming Language
> specification.
> 

vote++
January 27, 2007
Re: Creation of a Build tool on top of the D compiler
BCS wrote:
> Reply to kris,
> 
>> BCS wrote:
>>
>>> what If I have a 200+ module project that take ten minutes to compile
>>> (lots of templates say) a build only what's needed strategy is still
>>> needed. having bud walk the whole tree and still only build what is
>>> needed is still useful. I don't think /that/ functionality should go
>>> into the compiler.
>>>
>> Yes, I agree. The compiler should still handle the basic requirement
>> though. After all, currently loads /and/ parses every single one of
>> those 200+ modules regardless (if they're imported in any fashion)
>>
> 
> If all imports are private then compiling module N only requiters 
> parsing only the modules that N imports. Also lex/parse/syntax isn't all 
> that compiling requiers.
> 
> 

I think perhaps we're talking at cross-purposes? <g>
January 27, 2007
Re: Creation of a Build tool on top of the D compiler
Sean Kelly wrote:
> Andrey Khropov wrote:
>> kris wrote:
>>
>>> Especially when you
>>> can't successfully utilize certain types of D code from a library -- 
>>> such as
>>> templates.
>>
>> I strongly believe that compiler *should* be able to compile templates 
>> to a
>> some intermediate form and put it into libraries. Otherwise you will 
>> be forced
>> to create d 'header' files for your template-enabled libraries or even 
>> use them
>> as source code only.
> 
> C++ tried this with "export" and it's been a bit of a fiasco.  Last I 
> heard, EDG had it implemented (they were the only compiler team to have 
> done so), and the benefit didn't seem all that great.
> 
> 
> Sean

Crazy idea, but what if there were an object format could contain 
something like byte-compiled templates along with real binary code.  I 
guess it would be sort of like precompiled headers that get stuck in the 
final library.

Anyway, it would be cool if I could have all of Boost in one big 
"library" file rather than a billion little files scattered all over the 
place.

Sorting out all the #include issues seems like it would be tough though. 
 The files depend on being spread all over the place.

--bb
January 27, 2007
Re: Creation of a Build tool on top of the D compiler
Bill Baxter wrote:
> Sean Kelly wrote:
>> Andrey Khropov wrote:
>>> kris wrote:
>>>
>>>> Especially when you
>>>> can't successfully utilize certain types of D code from a library -- 
>>>> such as
>>>> templates.
>>>
>>> I strongly believe that compiler *should* be able to compile 
>>> templates to a
>>> some intermediate form and put it into libraries. Otherwise you will 
>>> be forced
>>> to create d 'header' files for your template-enabled libraries or 
>>> even use them
>>> as source code only.
>>
>> C++ tried this with "export" and it's been a bit of a fiasco.  Last I 
>> heard, EDG had it implemented (they were the only compiler team to 
>> have done so), and the benefit didn't seem all that great.
> 
> Crazy idea, but what if there were an object format could contain 
> something like byte-compiled templates along with real binary code.  I 
> guess it would be sort of like precompiled headers that get stuck in the 
> final library.

This is pretty much how C++ "export" works.  The files must still be 
processed at compile-time however, since the generated code may vary 
based on template parameters.

> Anyway, it would be cool if I could have all of Boost in one big 
> "library" file rather than a billion little files scattered all over the 
> place.

Agreed :-)


Sean
January 28, 2007
Re: Creation of a Build tool on top of the D compiler
Reply to Bill,

> Crazy idea, but what if there were an object format could contain
> something like byte-compiled templates along with real binary code.  I
> guess it would be sort of like precompiled headers that get stuck in
> the final library.
> 
> Anyway, it would be cool if I could have all of Boost in one big
> "library" file rather than a billion little files scattered all over
> the place.
> 
> Sorting out all the #include issues seems like it would be tough
> though.
> The files depend on being spread all over the place.
> --bb
> 

IIRC Ada does somthing like that
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home