| |
 | Posted by Sean Kelly
in reply to Yonggang Luo |  Permalink Reply |
|
Sean Kelly 
Posted in reply to Yonggang Luo
| Yonggang Luo wrote:
> This is care about druntime.
> The trunk version is 40 First, in file root/trunk/import/core/bitmanip.di, The 8th line of this file is "module bitmanip;" I don't know if it's must be change to module "core.bitmanip"
It should. Thank you for catching this.
> And I think the files exception.d memory.d runtime.d thread.d also to be place in the floder root/trunk/import/core/ will be better. (Just a advice)
The current setup is for modules that are compiled into the runtime library to live in src, while import holds header modules both for building the runtime and for distribution. The build process for druntime publishes .di files for the modules you list above into import/core, however, auto-generated header modules aren't terribly readable. What I'd done in Tango was to use a code beautifier on these files during the export process, but then the beautifier I was using broke and I had to disable it. So... I have considered both manually creating legible headers as well as simply copying the source files during the build process, but I'm still undecided about how best to handle this.
> And I am curios the three files in the folder root/trunk/import/std Is this possible to migrate these three files to folder root/trunk/import/core/ ? It's should be more meaningful, means these three file is not a general library, It's just used by the compiler, OR The compiler intrinsic functions, so it belong to 'core', (Just a advice, maybe it's impossible);
The compiler has the locations of intrinsics hardcoded, so the std modules currently exist by necessity. I hope that in a few more releases, DMD might change to look for these in core instead, but it's something that hasn't been discussed yet. For the moment my priority is simply to get the runtime functional, finalize the locations of stuff, naming, build options, etc. So while I consider the "std" thing to be a hack, it's one that's pretty much invisible to users and so isn't a top priority.
> It's possible be a good idea is we migrate the file object.di to the folder root/trunk/import/core/ so we have the
>
> module core.object module core.bitmanip module core.exception module core.memory module core.runtime module core.thread
This is an interesting idea, but I'm not sure it buys us anything. Wherever it lives, the object module will be implicitly imported into all D modules. So the location of this module is really only relevant from a filesystem standpoint... plus potential namespace collisions, I suppose. Another issue is that currently, the compiler runtime implements this module, and this code is distinct and separate from the 'core' code. So moving object into core might confuse things from a responsibility standpoint somewhat.
> module core.intrinsic for replacement of std.intrinsic
core.bitmanip fills this need right now. It's been brought up before that 'bitmanip' may not be the best name for this module (I think Don may even have submitted a ticket about this), but I haven't come up with anything better yet.
> and we have module core.stdc.* module core.sys.windows.* module core.sys.linux.* module core.sys.posix.*
Yup.
> and for c we have a special module module core.stdc.stdarg; for replacement for std.stdarg and std.c.stdarg.
>
> And I don't know why we need two stdarg file? one is std.stdarg, and the other one is std.c.stdarg? It's so strange. but the content of these two file is the same.
They're the same right now, but they may not remain the same in the future. We need two because each provides vararg support for a different calling convention. So you should use std.stdarg (though perhaps this should be in core) for D functions and std.c.stdarg for C functions.
> So it's should be file is we merge these two file.
See above. Personally, I'm now inclined to have:
core.vararg
core.stdc.stdarg
The C stuff in druntime isn't currently being built into a library, but that may change.
Sean
|
