On Mon, Oct 19, 2009 at 2:03 PM, Eric Christopher <echristo at apple.com> wrote:> On Oct 18, 2009, at 7:49 PM, Daniel Dunbar wrote: >> If you haven't already tried it, please consider switch to 'make >> check-lit' as an alternative to 'make check'. If it doesn't work for >> you, or you find it doesn't do something DejaGNU did and you like, >> please let me know. My eventual plan is to move to lit entirely and >> drop DejaGNU support, so consider yourself warned. > > I've swapped all of my testing to lit since all I do is native and it's been > great. I'm definitely in favor of Chris's suggestion that we move to that > as the default.Yay!> One quick feature question: one of the nifty things about dejagnu (really > the only nifty thing) is that it supported remote execution of binaries - I > don't use that right now, but other people may. Any idea if you plan on > having lit support that? Honestly I doubt it would be hard in python. > Probably a "if someone has a need" feature? :)Should be possible, although I don't know anything about the dejagnu feature. However, 'lit' has a reasonably complete shell and Tcl parser so it knows what commands are being called, so at least in theory it should be able to rewrite them. - Daniel
> > Should be possible, although I don't know anything about the dejagnu > feature. However, 'lit' has a reasonably complete shell and Tcl parser > so it knows what commands are being called, so at least in theory it > should be able to rewrite them.Interesting. Even less of that would be just duplicating the functionality. At any rate everything looks quite nice. Thanks! -eric
On Mon, Oct 19, 2009 at 9:24 PM, Daniel Dunbar <daniel at zuster.org> wrote:> On Mon, Oct 19, 2009 at 2:03 PM, Eric Christopher <echristo at apple.com> wrote: >> On Oct 18, 2009, at 7:49 PM, Daniel Dunbar wrote: >>> If you haven't already tried it, please consider switch to 'make >>> check-lit' as an alternative to 'make check'. If it doesn't work for >>> you, or you find it doesn't do something DejaGNU did and you like, >>> please let me know. My eventual plan is to move to lit entirely and >>> drop DejaGNU support, so consider yourself warned. >> >> I've swapped all of my testing to lit since all I do is native and it's been >> great. I'm definitely in favor of Chris's suggestion that we move to that >> as the default. > > Yay! > >> One quick feature question: one of the nifty things about dejagnu (really >> the only nifty thing) is that it supported remote execution of binaries - I >> don't use that right now, but other people may. Any idea if you plan on >> having lit support that? Honestly I doubt it would be hard in python. >> Probably a "if someone has a need" feature? :) > > Should be possible, although I don't know anything about the dejagnu > feature. However, 'lit' has a reasonably complete shell and Tcl parser > so it knows what commands are being called, so at least in theory it > should be able to rewrite them.FWIW, this is a feature we're currently using and caused me to make numerous changes to the makefiles a while back. If this is entirely going away, then bringing up a buildbot with a Beagleboard attached is going to be a much bigger task than I hoped. deep
On Oct 19, 2009, at 3:58 PM, Eric Christopher wrote:>> >> Should be possible, although I don't know anything about the dejagnu >> feature. However, 'lit' has a reasonably complete shell and Tcl >> parser >> so it knows what commands are being called, so at least in theory it >> should be able to rewrite them. > > Interesting. Even less of that would be just duplicating the > functionality. At any rate everything looks quite nice. >Why not abstracting the "copy to target," "run on target," "get results from target," etc. commands? For the default (hosted) case, they're pretty much trivial. For remote targets, they can be defined in terms of RSH, SSH, or whatever. As I recall, dejagnu does something along those lines.> Thanks! > > -eric > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev