On Sat, Oct 25, 2008 at 1:33 PM, Mike Frysinger <[EMAIL PROTECTED]> wrote: > On Friday 24 October 2008, Lucas Meneghel Rodrigues wrote: >> On Fri, 2008-10-24 at 01:19 -0400, Mike Frysinger wrote: >> > On Thursday 23 October 2008, Garrett Cooper wrote: >> > > Waf is interesting and with the right amount of Python decorators and >> > > Python nose testcase implementation, the build dependency information >> > > can become comparable to make. >> > > >> > > However, here are my questions and points of concern: >> > > 1. It's not mature. >> > > 2. It's duplicating a lot of similar logic from Python nose >> > > unnecessarily, in a not really intuitive way. >> > > 3. It doesn't have a comparable set of logic to GNU make's implicit >> > > rules, which greatly reduce the make logic -- this is a double-edged >> > > sword. >> > > 3. Can it reliably setup parallel build processes? >> > >> > ive never heard of waf. picking "the new hot system" that has no real >> > penetration or community is a bad idea. autoconf is probably the best at >> > the moment. especially because people seem intent on using LTP for >> > non-Linux targets. >> >> Although you put that in a somewhat troll-ish way, that was my original >> concern about using waf. > > it wasnt trollish as much as fact. every time i review a new build system, > all i see are mistakes and design limitations that autotools addressed and > overcame ages ago. > >> However, being new is not necessarily a bad thing, waf does have very >> interesting features. Also, it's perfectly usable for non-Linux targets >> for that matter, since it depends only and only python >= 2.3, which is >> available for a number of platforms. > > the fact it depends on python is a bad thing imo. since we seem to care about > people being able to build on not only non-Linux but really old Linux > systems, then autoconf is really the only solution that makes sense. > -mike
Ok, here's a point that might not have been considered earlier: We have a source base in our group that was inherited from another business unit in Cisco. The source base gets checked into clearcase. The problem is that when the stuff is checked out autoconf cached entries have mtimes sufficiently old that configure doesn't regenerate definitions, which ultimately leads to failure. The hack that we used for this issue is to touch the files with an mtime sufficiently ahead in the future that configure is forced to run, but recently we've more successfully solved this issue by reducing the autotools calls in Makefile.in to /bin/true calls, e.g.: ACLOCAL = /bin/true AMTAR = /bin/true AUTOCONF = /bin/true AUTOHEADER = /bin/true Do you guys really want to force people to deal with this issue every single time when there's an upgrade? Certainly, the only way to properly work around these issues is by talking with the autotools folks, as I find the shortcomings of autotools to be something that needs to be addressed upstream. A parallel question is (that I think applies to the discussion): Where does LTP draw the line in terms of what systems to support and what systems to not support. For instance, LTP (IMO) should not work on kernel version 2.2, but it should work on limited 2.4 systems and should work on all 2.6 systems. Similarly, what kinds of assumptions can be made from those systems? Due to Redhat being behind the times (even on Fedora Core 1) I had to compile make-3.81 and install it in order to work with my makefile changes; FC1 uses make 3.79 and I use directives that are only compatible with 3.81+ -- then again make 3.81 has been out as the stable release for the past 2+ years, so I don't really see why this shouldn't be a real support issue, esp since make 3.79 has POSIX and other compatibility issues to speak of. Thanks, -Garrett ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
