Duane Ellis wrote:
> duane> [about --prefix and --exec-prefix ...]
> 
> Dirk> It would help if you tell _how_ to "use the *SAME*
> Dirk> private path - for OpenOCD".  Reading the other mail,
> Dirk> I think you mean using --prefix for OpenOCD with the
> Dirk> same path as used for libftdi build/install?
> 
> duane> and it will work automatically.
> 
> dirk>  You mean with --prefix? No. Because at the moment OpenOCD totally 
> misses -I and -L option given by --prefix:
> 
> I intend to fix that.

Ah, ok. This was my misunderstanding! My understanding was that you 
meant --prefix usage as you describe below should already work.

> Why? I have for years built standalone tool kits.
> 
> (this link goes back 5 years ago: 
> http://sourceware.org/ml/crossgcc/2003-07/msg00046.html)
> (this link goes back 8 years - 
> http://sources.redhat.com/ml/insight/2000-q4/msg00346.html)
> 
> Hence, in  'libftdi'  (or any other package) you do this:
> 
>       ./configure  --prefix=~/openocd/test/install
> 
> And in 'openocd' - you also do this:
> 
>       ./configure  --prefix=~/openocd/test/install
> 
> using the *same* private: '--prefix'
> 
> In the end, you have a "private tool chain" built in that non-standard 
> place.
> And you can also have as many as you need.
> 
> Dirk> And if you "fix" this by passing 
> -with-ftd2xx=~/openocd/test/install/include *additionally*.
> 
> And currently today, I pass "CFLAGS= ... various ..." when I ./configure 
> to accomplish what you describe.
> 
> All of this should be fixed - exactly - by the above and be automatic by 
> way of you specifying "--prefix" and/or '--exec-prefix' Which should 
> also handle "-L" and inserting a "-rpath" that is needed if you link 
> with an SO file in a non-standard location (ie: somewhere that 
> /etc/ld.so does not know about)

Ok. Agreed. Should we start with fixing "--prefix" usage like you 
describe above? As I mainly work with libftdi at the moment, I think 
having --prefix path in -I and -L  would help already a lot :)

Thanks

Dirk

_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to