On Sunday 28 June 2009 11:06:27 Freddie Chopin wrote: > Zach Welch pisze: > > You cannot have both libftdi and FTD2XX support in > > the same FT2232 driver binary, so this patch not even allowing testing > > them both using the same openocd binary (presumably by adding/removing > > the OS drivers between tests). > > Why is that so impossible? init() will try to load one of the libraries, > and in case of failure will try using libftdi. The order is just because > ftd2xx.dll is available as library, whereas libftdi is not. Yesterday > I've thought about that issue a bit and come to conclusion, that I'd > have to modify libftdi code so that it would load libusb0.dll dynamically.
It isn't possible with the current ft2232.c code because it uses conditional compilation to compile either with libftdi or FTD2XX. While offering basically the same functionality there are not only syntactical but also semantical differences. If ft2232.c was to support both libraries in one binary there would be some rework required. I'm not sure if that effort is worth it since ftd2xx might eventually go away in the not too distant future. > > Personally, I think that I have failed to see the value of this patch, > > but maybe I have missed something. In contrast to the strategic > > solution, what problems does this current patch solve for OpenOCD users, > > today? Without a clear answer to this, I am not sure why we want it. > > To compile openocd you need to specify dozens of options for configure, > because some of them are exclusive (like support for libftdi and > ftd2xx). I think that it would be possible to modify the code in a way > that ALL possible interfaces would be enabled. It's easier to compile > with "bootstrap, configure, make" than browsing through docs to find all > required configure options... Of course I cannot do that alone, as I'm > not a skilled and experienced developer. A user who compiles the OpenOCD for his personal use is normally going to use only one or maybe two different JTAG interfaces. The available options can be looked up with ./configure --help. Packagers building OpenOCD for a Linux distribution, Windows, or some other software platform (as opposed to packagers building for a particular JTAG interface) are a different story. I suppose they're interested in being able to build for the widest variety of interfaces. Building is always going to require the library headers to be present. If all interface drivers were to be built unconditionally you'd have to have all headers present on the build system, which isn't good imho. Hence the off-by- default convention. > When there would be a binary release it could have just the executable, > without any libraries attached. Now when you do a binary release with > maximum number of interfaces enabled you need to attach some libraries > to it. For example compiling support for rlink makes libusb0.dll > required, even if the end-user uses Wiggler. He doesn't need the library > for use, but OpenOCD won't start without it. Exactly - but that's not related to the configure options. Being able to produce a OpenOCD binary that _could_ use all possible JTAG interfaces, but doesn't require installation of all prerequisite libraries would be nice. Regards, Dominic
_______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
