From: CAI Q. <ca...@cc...> - 2008-10-27 04:59:39
|
Hi, --- Daniel Gollub <dg...@su...> wrote: > On Thursday 23 October 2008 21:57:59 Garrett Cooper wrote: > > The big question I have (for any makesystem) is: > > 1. Can we easily work with header location changes? Remember, we could > > set a series of high-level CFLAGS to denote what features need to be > > enabled and have a global header which is included that properly > > detects which headers need to included, as well as define whatever > > macros need to be defined to provide our test API's or API's being > > tested with the means to compile and link. > > For me this sounds "configure"-like (no, i don't have only autotools in mind) > script which generates a "config.h" from a config-header template. Which > represents all available headers/function of the current (build) > environment - right? > > So the build environment should bring _easy_ functionality to: > > Check Function Exists > Check Include File > Check Library Exists > Check Struct Has Member > Check Symbol Exists > Check Type Size > Check Variable Exists > > Maybe optional for more advanced checking: > Check C Source Compiles > Check C Source Runs > > Check C++ SourceCompiles > Check C++ SourceRuns > > And define if function/include/library/struct member/symbol/variable exist? > And/or define the type size/include path .... > > Based on those defines further conditional macros get defined in the tests.. > > Anything missing? > > > 2. Can it prune the build to meet the set features so that I -- as a > > test engineer -- can move from one version of LTP to another WITHOUT > > the infrastructure telling me that I have to upgrade any components on > > my target system OR having the build fail on me? > > Do you have an example on that? > > ... > > What about "testing" infrastructure provided by the build system itself? > > Like continuous build testing based on/triggered by CVS/SCM commits? > > And reporting build regression (errors/warnings...) to some dashboard > application? > > There are some build environment/systems providing something like this... > > (And maybe even start LTP functional testruns on a stable reference kernel, > for quick regression testing of the tests itself. > And sending build and testresults to a central and public dashboard? > Focus of this kind of testing is not testing the kernel - more finding very > quick/automatically regression of LTP changes in CVS) > Not quite sure how big the interest in something like this? > That is good to have if it is something simple. Otherwise, it is may adding complex and difficult to maintain. In fact, we have already done this using the company's internal testing system, so every LTP version we ported will have test run logs saved somewhere, and we'll know if there is a regression or not when we run the newer version. It is a fairly complex system though, which is something misssing in LTP. If you are interesting, you could look at, https://fedorahosted.org/beaker/ I would rather prefer that every change sends to this mailing list for peer-review to reduce regression or bad commit. If it is possible, every patch should to get at least some degree of review in order to commit to CVS. Then, it is up to the maintainer and users to find regression, revert patches or fix issues found. Cai Qian > best regards, > Daniel > > ------------------------------------------------------------------------- > 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 > Ltp...@li... > https://lists.sourceforge.net/lists/listinfo/ltp-list > |