On 2012.06.05 03:32, Xiaofan Chen wrote: > As per Pete, autoconf needs to be 2.50 minimum.
As per old libusb rather. I don't mind making it later, if it's no more recent than 2009, but I just don't know what value we should put there, and I don't see much point to try to guess outside of reports, so I'll stick 2.50 for the time being. As far as I'm concerned, as long as nobody complains about 2.50, then it's the "right" limit. > What > about automake? I think probably 1.10 should be the one to go. > I do not see a problem with these two (automake 1.10 and > autoconf 2.50) in reality. > > Automake 1.10.1 is dated 21-Jan-2008. > http://ftp.gnu.org/gnu/automake/ Is there an autotools prereq for automake? But even then, my approach would be to just leave it be until someone reports an issue, because then we'll know precisely the versions we need to filter out. I think that's a better approach than trying to guess (or spend time trying to figure out exactly what we need), and potentially annoy our users by figuring things wrong. > Autoconf 2.50 is dated 21-May-2001 which is > really old. > http://ftp.gnu.org/gnu/autoconf/ > > libtool is often a problem due to the need to > support Windows. > > Eg: for old version of libtool. > ./configure: line 3371: LT_INIT: command not found > ./configure: line 3372: syntax error near unexpected token `Windows' > ./configure: line 3372: `LT_LANG(Windows Resource)' > >> From the past discussion, libtool 2.2.8 release should be the minimum > version (for MinGW-w64 support). > http://sourceforge.net/mailarchive/message.php?msg_id=25711845 > > libtool 2.2.8 is dated 04-Jun-2010 which is about 2 years > old but I think it is not a big problem to ask users to upgrade > to this version of newer. As I stated, I'd prefer a 3 years buffer insofar as we haven't identified an issue that requires something more recent that we can't easily work around. In this case requiring LT 2.2.8 or later seems the way to go for MinGW (and potentially other platforms). But do you know if these <2.2.8 errors are also generated outside of MinGW compilation? > I have no problems to install libtool > 2.4.2 under various version of OpenBSD/NetBSD which comes > with libtool 2.2.6b or older. Well, I would say that that depends if 2.2.6b still works for the compilation of libusbx for native *BSD. If that's the case, then I wouldn't see much of a reason to force/request all *BSD users to upgrade to 2.2.8+. If autoconf simply ignores macros that it doesn't know about, you may get a warning and that will be about it. By the looks of your report above however, I suspect this won't be the case. For what is worth, I also have 2.4.2 installed on my test *BSD platform and I'm not really planning to install an older version of libtool to find that out. All in all, I wouldn't see much point in trying to place arbitrary restrictions that may be an inconvenience for many, if they only benefit a few people. For instance if 2.2.6b was to work on *BSD, albeit with warnings, and therefore its use would only impact *BSD developers who cross-compile for Windows, I don't think I'd want to place a requirement for all *BSD users to upgrade their libtool to 2.2.8+ and collectively make a larger number of people waste time, just so that the handful of people who cross compile for MinGW on *BSD can avoid wasting some of theirs. The right balance should be to go with the most amount of time we can save for our users and forcing people to upgrade toolchains unnecessarily is not exactly what I would call saving them time. Thus, depending on whether 2.2.6b actually works or bails out outside of MinGW (and I guess in the absence of further testing, we should assume it doesn't), I'd just put a "[if you compile for MinGW,] please use LT 2.2.8 or later" on the wiki, and that's pretty much how I would handle this whole minimum supported version thing. It's only once we become aware of specific issue for a specific platform or set of platforms that we need to place a limit. Note however that not setting limits doesn't imply that we're going to start supporting older tools/dependencies. The whole idea about the semi-official 3/6 years old boundary is that, if someone comes to us with an issue with a toolchain that has parts that are > 3 years old (6 for Windows), we can tell them that officially we only support recent tools and libraries, and that they should first try to upgrade to see if the problem still occurs. Then if we find out that the problem is resolved though the upgrade, we get an idea about the minimal version of toolchain components we should request. But in the absence of such a report or in the absence of us having to do any extra work to support older platforms (which, for the record, is why supporting older versions of autotools an supporting older versions of MSVC, such as MSVC6, is a very different story, as we need to maintain and support a custom set of files there), compiling libusbx with any old toolchain is fair game. > What about pthread? I just tried to build libusbx-1.0.11 > release under Ubuntu 8.04 (already obsoleted) and it > gives error. I am not saying that libusbx needs to be fixed > to suit for older distros but just wondering what is the > minimum pthread (or glibc) version required. Again, if it's more than 3 years old, then the minimum version is whatever comes after the one we get a report doesn't work. In this case, that's the version after the pthread version of Ubuntu 8.0.4, and that's what we should report on the wiki. Regards, /Pete ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libusbx-devel
