avrdude-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avrdude-dev] Build error with SVN trunk


From: Hannes Weisbach
Subject: Re: [avrdude-dev] Build error with SVN trunk
Date: Tue, 21 May 2013 10:35:27 +0200

> 
> Also, I'm not sure whether anyone so far tested all this on Win32
> against libusb-1.0.  All I've done so far was against the old
> libusb-win32 0.1, but a 1.x version is available now (unlike a couple
> of years ago).
I built for my Windows tests a Win32 executable with libusb-1.0 and it worked 
fine. Later I read one needs libusbx-1.0 (libusbx is a libusb fork, 
libusbx.org) for Windows but that seems to be outdated information.
> 
>> To use libusb-1.0 one has to use libftdi-1.x.
> 
> No, one can use libusb-1.0 completely without libftdi. ;-)
> 
> I think you meant it the other way: libftdi 1.x requires libusb 1.x.
Yes ;)
> 
>> lib{usb,ftdi}-1.0 also feature asynchronous I/O and it is my
>> understanding that with this feature the ftdi_syncbb programmer will
>> be able to work without threading, so we loose one dependency
>> (pthreads) with "just" an update.
> 
> That's a point, though the only constellation right now that would
> really benefit from it is MinGW32 builds.  They are currently the only
> platform not offering pthreads.
> 
> I'm not opposed to have the code for lib{usb,ftdi}-1.x in, I'd just
> like to not see the ability to also work with older versions go away
> that quickly (within their limitations, of course).  Sometimes people
> simply use older, not very well equipped machines for these tasks,
> where they have troubles updating everything to the latest and
> greatest bits.  I think it's a nice feature of AVRDUDE of being able
> to use whatever "is just there".
Isn't "compile/run everywhere" some sort of feature creep, too? ;)
Does someone use avrdude on Solaris/sparc64 for good reason?

Being more constructive: How would one go about building such a backwards 
compatible programmer? Let's take avrftdi as example. I see two options: 
#ifdef'ing code (I don't like it) to use headers/calls from this or that 
library or implementing a new programmer (which might share code with the "old" 
avrftdi). So far, so good. The crux is linking. How tell gcc to link a library 
against a single object file and use another library for all other object files?
The only option I see is to use some sort of --with flag to select libusb-1.0 
or 0.x (and libftdi) and then build only programmers which support this 
library. If you want backwards compatiblity, use the -0.x and everything is 
fine. But what if you want to have avrftdi with libftdi-1.0 and JTAGICE or 
AVRISP with libusb-0.1? Is this even an issue because everyone uses only a 
single programmer, anyway?

Best regards,
Hannes




reply via email to

[Prev in Thread] Current Thread [Next in Thread]