dirk> [snip: libftdi isn't discussed here? ]
My intent is that we have a complete solution, for both systems,
libftdi, and libftdi2xxx.
duane> And is it a STATIC or SHARED library?
dirk> I would focus on shared library. People who want static know what
they do?
This comes down to the "did the user properly install it" - and the
"-rpath" is evil issue.
Using the static library - those two issues are moot.
I will say - I have fought that battle before. This is what leads me to
the "static solution".
The example I give is this:
1) the user has exploded the source tree.
2) the user points at the exploded source tree with ./configure
3) Package is built and installed.
4) Can the source directories be removed now (cleaned up)
One would *THINK* yes - truth is NO.
Because the "rpath" would still point there.
And if a "packager" creates an "RPM" (or DEB or whatever) binary distro
... it will be wrong.
There are points scored on the "static side" of that equation.
Or perhaps I am missing something ...
==================================================
duane> [option 1/2/3]
dirk> As I understand it, from practical point of view there is no
difference between option #1 and option #2.
Ah but there is - w.r.t. the shared library problem.
==================================================
duane> [suggesting: 1 "libdir" and 2 "incdir"]
dirk> I don't like (1) and (2) and would vote for (3) and (4) below:
I am suggesting all 4 methods be available, I think this helps with
corner cases.
==================================================
duane > TEST -
dirk> I would be happy to test libftdi and libftd2xx under Linux.
Thanks.
-Duane.
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
