> > 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? >
as far as i know cygwin and native win32 can only do static libftdi. ftdi's ftd2xx is always shared. > > ================================================== > > > > 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. > mingw behaves the same as cygwin. I use cygwin to build native win32 using the -mno-cygwin option. > > ================================================== > > > > 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 > I agree, just a matter of changing the option we already have to work on linux aswell. This option was added originally for cygwin users, linux users were expected to copy the h/libs to the relevant location for their compiler/system. Cheers Spen _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
