[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