On Wed, 27 Jun 2012, Iain Buclaw wrote: > It's copied as including c-common.c / .h causes problems with a fair > number of references pulled in that need to be stubbed out - also, > some GCC function attributes that we use do not make any sense to have > in D code (eg: gnu_inline, artificial, cleanup). It could certainly > be possible though ... Will need to review this in more detail.
Quite possibly you need to split up c-common so that the parts that can also be shared with D are in separate files. > The D frontend is completely independent of the GCC backend, and any > alterations are purely for portability (eg, the use of real_t rather > than long double for the representation of floats). There is no If for portability, I'd hope they wouldn't need to be conditional - rather, the common repository used for all the compilers using the dfrontend code should be able to have them, unconditionally, and another such compiler might have a typedef of real_t to long double if that's what that other compiler wishes to use. Hopefully you can work with the people maintaining other such compilers so that there can genuinely be a shared, portable source base for the shared code, in a public repository used by all those maintainers, without conditionals based on which compiler it's used in, and with that shared source base only using an absolute minimum of headers from whatever compiler it's used in (so only minimal GCC headers when used in GCC, etc.). > Likewise, have removed it as is in fact no longer required. The > "optimize" #undef remains for the time being as it conflicts with the > name of a member in the D frontend sources. If the D frontend > followed the C++ Coding Conventions as outlined in > gcc.gnu.org/wiki/CppConventions then this wouldn't be an issue. > Though I don't think it has an obligation to being essentially > disconnected from calling any GCC code. But it ought to be possible to stop the shared D front end from including the relevant GCC headers at all, if it has a clean interface to the rest of GCC.... > Have removed all alloca handling from GDC and replaced with simply > including libiberty.h. system.h includes libiberty.h, so direct inclusion of libiberty.h shouldn't be needed (unless you are trying to avoid using system.h in code shared with other D compilers). > https://github.com/D-Programming-GDC/GDC/commits/master > > > I do have a question though, what is available for the transition of > development from git to svn? Other than a lot of ready and getting > used to the various switches and commands on my part. Once there is a front end ready to commit and approved in technical and GNU policy terms, you'd just do "svn add" on the files to add them to trunk. It's up to you how you handle keeping the dfrontend/ changes in sync with an external shared repository (with all changes going to the external repository first); Ian Taylor may have some automation for that issue for Go. -- Joseph S. Myers jos...@codesourcery.com