Re: [LTP] Autoconf

[Daniel G. <dg...@su...>]

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?

best regards,
Daniel