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.
The question I have is this: What should the option be pointing at?
Details and commentary follow.
-Duane.
==================================================
For all systems
There is the question of where is the "H" file?
There is the question of where is the LIB
And is it a STATIC or SHARED library?
==================================================
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"
What do you do?
What is expected?
The problem lies with 'ftdi' they did not state what is "proper"
so everyone does it differently.
==================================================
For MingWin - I don't know. I do not use MingWin.
Spen? Do you hav a comment?
Do others?
Input would be appreciated.
==================================================
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.
Option #3 - Same as Option #2.
But instead of linking with the ".so" file - we link with the
static lib.
==================================================
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
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
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)
(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.
(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 ? )
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.
==================================================
**END**
-Duane.
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
