January 27, 2007 Re: Creation of a Build tool on top of the D compiler | ||||
---|---|---|---|---|
| ||||
Posted in reply to kris | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Derek Parnell | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to BCS | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bill Baxter | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bill Baxter | 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
|
Copyright © 1999-2021 by the D Language Foundation