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.) > 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. > 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. Ian
