On Saturday 25 October 2008, Garrett Cooper wrote: > 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
i'm more than aware of said issue seeing as how i deal with many projects that use autotools with scms, or with distributions that check in entire projects (configure and all). it really isnt an issue at all: find . -type f -print0 | xargs -0 touch -r configure again, keep in mind here that we are talking about autoconf *only*. the kind of regeneration issues you're worried wouldnt exist. they only exist in your projects because you're also using automake which includes timestamp checking and auto-triggering of all the fun autotools. > 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. i really dont see it as a shortcoming at all. that'd be like saying the time checks that are integrated into GNU make is completly broken because it's able to figure out what .o files need to be regenerated whenever a source file is updated. > 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. no statement has been made in this area as LTP wasnt really formalized in any way. it's just slowly grown. linux-2.2 support is pointless. such targets are unrealistic nowadays beyond a hobby hacker niche, and even that is limited. anything that goes in for linux-2.4 would be a "general" solution. in other words, check to see if interface foo() exists and if not, dont build/run the affected tests. make-3.79 is broken, end of story. ive seen too many failures in many other projects related to it. make-3.80 has been out for over 6 years now. i havent really seen anything critical related to 3.80 that we'd want to force 3.81. -mike
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------- 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
