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.

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++ 

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>

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

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

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