Re: Packaging a difficult project
>
>> 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.
Reply to: