On 5 October 2011 00:10, Ian Lance Taylor <i...@google.com> wrote: > Iain Buclaw <ibuc...@ubuntu.com> writes: > >> The active development of the D frontend would continue to be mirrored >> in an external repository, but will occasionally be merged into GDC >> project. > > Well, Go does set a precedent for this. The main issue here is that > this means that there is (another) directory containing source code that > the gcc maintainers can't update. This is workable if the D frontend > does not #include any gcc header files or call any gcc functions. That > is, if it is truly standalone. (The Go frontend is not yet in this > state, although I am slowly working toward it.) > >
The D frontend does not include any gcc headers or call any gcc functions. >> Some work would need to be done on naked functions at least first so >> that changes required are only to gcc/config. I would be grateful if I >> could get pointed in the right direction for implementing naked as a >> function attribute for i386 so all frontends could benefit. > > Needs a target hook in target.def and a new attribute probably in > c-family/c-common.c. The new attribute would check the target hook to > see whether the backend supports it. > > >>> The D runtime appears to be in a subdirectory of gcc/d. Ordinarily we >>> would prefer that it be in a separate toplevel directory, e.g., >>> libdruntime. >>> >> >> The set-up build script that is provided with the gdc development >> folder makes symlinks from gcc/d/ to a libphobos toplevel directory. > > That is kind of awkward, though--why not just set up libphobos in the > first place? I understand this may require two directories to be > mirrored. > > The gcc/d folder is only structured as it is now because gdc code is shipped as a separate entity from gcc, that you can then apply to any version of gcc that is supported. This would no longer be the case if merged in. I assume best thing to do for me to get started in the *doing* would be to set-up a new branch prep'd up as I intend for it to be if this were to be moved forward. >> First question that pops up after having a quick look is, are there >> any tips around for writing the scripts for the testsuite? I'm not too >> familiar with Dejagnu, and the current testsuite used for GDC D2 >> development is written in make. > > DejaGNU is too horrible for me to talk about. I can't recommend > anything other than blind copying of existing scripts. > :-) Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
