Duane Ellis wrote: > A while ago - w.r.t. rev 1.0 - we where talking about the --with-ftd2xx > option. > > The general idea was to add a "path" option of some sort.
Yes. I'm not sure but it seems to me that below you concentrate on "libftd2xx on the various OSs"? In the rev 1.0 thread I started the discussion with "libftd2xx vs. libftdi at Linux" in mind. So same problem, but slightly different focus ;) Did I miss it or didn't you mention libftdi below? > The question I have is this: What should the option be pointing at? Will try to give my $0.02 below. > Details and commentary follow. > > -Duane. > > ================================================== > > For all systems > There is the question of where is the "H" file? Yes. > There is the question of where is the LIB Yes. > And is it a STATIC or SHARED library? I would focus on shared library. People who want static know what they do? > ================================================== > > For cygwin - what would one expect? > > There is *NO* standardized "how to install it" set of instructions > telling the *victim* what to do. maybe there is - but I cannot > find it and do not know where to look. > So we must set our own expectations and tell the user what to do. > > What I do is this: > I unzip the ZIP file - next to openocd. > > Hence, I have (under cygwin) > /home/duane/work/openocd.VERSION/.... > /home/duane/work/ftd2xx.d > > I would like an option that says: > "this is the directory where I unzipped the ZIP file" Yes. This sounds good. The directory where ZIP file is unzipped contains LIB and H, so this should be fine to be added to -I and -L. > What do you do? > What is expected? > > The problem lies with 'ftdi' they did not state what is "proper" > so everyone does it differently. I think people unzip and pass the path to OpenOCD is the easiest way and we should take it. > ================================================== > > For MingWin - I don't know. I do not use MingWin. > > Spen? Do you hav a comment? > Do others? > Input would be appreciated. Don't know, too. > ================================================== > > For Linux - it is entirely 50% not 100% a different matter, FTDI set a > standard, they have a readme file. But - that "readme.dat" file is > incomplete. > > Functionally, it tells the *victim* how to install the ".so" file and > setup the > standardized version numbered sym-link in two places. > > (1) /usr/lib > and (2) /usr/local/lib > > The readme file does not speak about "ftdi2xx.h" - so one is left to wonder > where it is put. I suspect - it is in a *RANDOM* place - or not even > installed anywhere. > > What should we do? > > Option #1 - is - we assume the user has followed the instructions and > "installed the . > so file" and nothing else. > > This leaves the need to have a --config-option to point where the > ".h" file > can be found. > > Option #2 - is we assume did not install it - > > Should we expect the "--config-option" to point at the directory > where they > exploaded the tar ball. As I understand it, from practical point of view there is no difference between option #1 and option #2. The directory where the tar ball is extracted to contains .so and .h file. So option #2 should always work adding the path to tar directory to -I and -L. If they copied (moved?) .so to installed directory (option #1) (e.g. /usr/lib or /usr/local/lib) this would be in library search path and the additional -L path at link time wouldn't hurt. > Option #3 - Same as Option #2. > But instead of linking with the ".so" file - we link with the > static lib. As mentioned above, I wouldn't care about static library. > ================================================== > > From a design point of view I am faced with a dilemma. > > There is no defined way one would expect it the package to be installed :-( > So - what ever we do - we will force something on the user. > > Basically we tell the user Do X/Y/Z - and it will work, do something > else and it will not. > or we end up with configure option-hell. > > ================================================== > > I suggest we do the following: > > Remove: --with-ftd2xx Yes, or rename it ;) > Based on "--enable-ftd2xx_libftdi" - we look for the H and LIB files > we look in _the_standard_places_ ie: > /usr/lib, /usr/local/lib, and /usr/include,and /usr/local/include Yes. This is the default already? > And then demand/complain if the following items where not set. > These options will be used to resolve the problems - if needed. > > (1) Add: --with-ftd2xx-libdir=<PATH> > It becomes yet another "-I" paths. > > (2) Add: --with-ftd2xx-incdir=<PATH> > It becomes yet another "-L" and "-rpath" options > (because it might be a 'shared library' in a non-standard place) Did you mix libdir and incdir in (1) and (2) ? I don't like (1) and (2) and would vote for (3) and (4) below: > (3) Add: --with-ftd2xx-zipdir=<PATH> > Assumes you did not install it - just unzipped it > Under cygwin, you downloaded the ZIP file > And this is the directory where you unzipped it. > > (4) Add: --with-libftd2xx-tardir=<PATH> > Assumes you did not install it, just unzipped it. > Same as (3) but for Linux/Unix > We would default to the *static* version. Why static? Why different names for the same functionality? Why not just --with-libftd2xx-dir for the directory where .tar or .zip are extracted to and where .so and .h files are located? Add path given by --with-libftd2xx-dir=<PATH> to -L and -I and everything should be fine for libftd2xx? But, as mentioned above, it seems to me that libftdi isn't discussed here? I don't know the details as good as you, but what's about: Replace/rename --with-ftd2xx to e.g. --with-ft2232-dir then do * If --enable-ft2232_ftd2xx is enabled using --with-ft2232-dir=<PATH> results in -I<PATH> -L<PATH> where PATH is a path to tar/zip directory * If --enable-ft2232_libftdi is enabled using --with-ft2232-dir=<PATH> results in -I<PATH>/include -L<PATH>/lib where PATH is a path to the libftdi (--prefix) main install directory. In both cases, if people already moved .so/.h to some standard directories which are in include/link search path, this wouldn't hurt. Would this work? > (5) MingWin - And I am not sure about MingW32 situation. > I believe one of the above might handle the situation. > Can somebody offer a comment ( ? Spen ? ) Don't know. > Problems: > Dealing with "i386" vrs "x86_64" subdirectories > I'm looking for an autoconf reference if there is a standard way or > not. > If somebody knows this already - a reference would be helpful. > > ================================================== > > TEST - > > I cannot test all combinations - help will be appreciated. I would be happy to test libftdi and libftd2xx under Linux. Best regards Dirk _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
