> >> I believe that edoc doesn't use the code generator, only the front >> end, so it doesn't need care from port maintainers. >
The GCC modification attempts to change as little in the GCC framework as possible and just performs analysis on the data structures generated by GCC as it compiles code. As such GCC still generates binaries. In fact one of the data output formats (Which I assume will be the most commonly used output format) for EDoc++ is to embed the EDoc++ specific data into the binary files generated by GCC in an .edoc section in the binary file (Which is later accessed using libbfd). This makes locating data for post processing a much easier task. As such the EDoc++ patched GCC still generates binaries and so it does not just include the front end. However I have made it plain that to use the resulting binaries is done so at the users risk as I can not guarantee the integrity of the resulting binary files, simply because I lack the man hours to do this. However with that said I have been using them myself and not encountered any problems. Also I am unable to maintain various system specific patches for GCC such as Debian, Fedora, NetBSD etc. Though I am not sure if these systems currently require platform specific patches from the existing GCC sources. > Which was not my objection. I understand and accept that edoc might not be > a very good compiler to use on all architectures, and don't think that > should be a reason to keep it out of the archive; my concern is that, > depending on which binary packages it needs to build, edoc could take up as > much as 1GB of space on our full mirrors, for something that should > effectively be a patch against gcc. > EDoc++ binaries are currently around 20M. It does not require any special binutils etc, but will just use what is already available for the system. I am currently building a single non-policy conformant .deb package. Brendon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
