On Wed, 2009-06-24 at 20:14 +0100, Ian Guffick wrote: > <snip> > > Here is the full list of GPL-compliant solutions for libftd2xx GPL > > compliance, after further review, consideration, and enumeration: > > > > 1) Documentation: build it yourself! > > 2) Build-Kit: automate the build on users' machines > > 3) XXX: to be revealed, if legal > > 4) libftdi-ftd2xx: ABI compatible with libftdi, wraps ftd2xx > > 5) sockets: separate ftd2xx into their own process space > > 6) libusb+libftdi: The Right Thing To Do ;) > > > <snip> > > Just a thought on option 2 - the build kit. > This would be a large download, and quite a lot of work for someone to put > together. > If the GPL violation happens in distributing code that is linked to FTD2XX, > could the build kit have pre-compiled objects for openocd - that are then > linked on the users machine. The pre-compiled objects, as distributed, would > not be linked to FTD2XX. This would reduce the complexitiy of the build kit > down to a much simpler 'link-kit'. It's function would be no different to > the build kit. > I haven't looked into it but maybe this could be as simple as a few object > files, LD and a few MingW libraries along with a batch file.
I think it will take a little bit more effort than this (some autotools magic to ensure users can build different configurations), but this is a great idea for reducing the download sizes. In many ways, it sounds a bit like using ccache; once the cache is populated, you only ever link. Cheers, Zach _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
