This is the mail archive of the elfutils-devel@sourceware.org mailing list for the elfutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: mpolacek/ebl_dynamic_tag_name


  On 03/15/2011 05:23 PM, Roland McGrath wrote:
>> This looks fine to me. But note that libebl isn't a stable interface. So
>> I wouldn't spend too much time adding specific tests for it, unless
>> higher level functions really depend on it. So in this case, why not
>> (also) actually read the dynamic segment of the testfile you open and
>> check the tag names found in there?
> That's a good point.  It's arguably anti-useful to have tests like this
> that make someone think the ebl interface must not be broken.  The right
> way to test this function is just to run readelf.  You can just choose a
> test file synthesized to contain all the known names and then run readelf
> -d on it to check the output, there is no need to write a unit test like
> this.
>

Aha, OK, thanks for explaining.  I'll remove that branch and hopefully
will come up with just .sh test.

>> Since we are adding more and more tests, it would be good to have a bit
>> more structured framework for it. Maybe using autoconf autotest? But I
>> don't really have a suggestion/preference for what/which framework would
>> be nicest (but please something simple without external dependencies
>> except regular build infrastructure tools). Would you be willing to look
>> into that?

Sure!

> I have long been intending to convert our tests to autotest.  I just
> never got around to it.  I think it would be a good thing to do.
> This is an excellent suggestion for a new volunteer like Marek to
> look into.  I'm glad you reminded me about it.
>
> It would start with some macros to replace what test-subr.sh
> provides, making it simple to write tests.  The hairy thing there is
> to do them so that they serve correctly for both 'make check' and
> 'make installcheck'.  The other nice thing I'd planned to do was
> integrate into the test macros some magic that emits the right magic
> data for lcov to delineate the coverage data between tests.  I have
> some macro magic kicking around somewhere from another old project
> for that.

Fine.  I have no experience with autotest and only a little with whole
autoconf beast, but this looks like something cool to learn, so I'll
dig into it right off when time allows.  We'll see how it turns out.

Thank you.

         Marek



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]