Re: [exim] Test suite on OSX

Top Page
Delete this message
Reply to this message
Author: Ian Eiloart
Date:  
To: exim-users
Subject: Re: [exim] Test suite on OSX


--On 12 January 2007 09:45:39 +0000 Philip Hazel <ph10@???>
wrote:

> On Thu, 11 Jan 2007, Ian Eiloart wrote:
>
>> I'm trying to get the Exim test suite running on OSX 10.4 (gcc-Darwin).
>> I'm presuming that once I'm done, it will be suitable for testing new
>> configuration even though it's designed for testing builds. Am I barking
>> up the wrong tree here?
>
> Yes. It has its own set of built-in configurations that it tests and
> checks. If you want to test *your* configuration, just use the normal
> Exim binary.


Yes, I know that's the intent, and I wanted to build a suite of tests for
my configuration. I've tried building scripts to do this in the past, but I
thought I might be able to use the testsuite architecture to make this
easier.

I know I'd have to remove the supplied configurations, and write a lot of
rules, but from the docs, it looks like you've solved some problems (like
variable outputs) that I had difficulty with. Taking a closer look, I see
that there are some things I'd have to define conditionally, perhaps with
an include file or a command line switch.

I thought I'd be able to use my own test suite for three purposes:

1. To ensure that my MX and MSA configurations have consistent routing
logic.
2. To make sure that changes to my configuration don't have unexpected
consequences.
3. To test new builds of Exim against my configuration, to ensure that
upgrading won't change anything.
4. To ensure the the hosts on my cluster are behaving consistently.
5. To help me build config changes against tests that I've defined.


>> Anyway, it fails to compile, with errors like this:
>>
>> > gcc -g -O2 -o bin/fakens src/fakens.c
>> > src/fakens.c:118: error: 'T_A' undeclared here (not in a function)
>> > src/fakens.c:119: error: 'T_NS' undeclared here (not in a function)
>> > src/fakens.c:120: error: 'T_CNAME' undeclared here (not in a function)
>
> Find your system's version of nameser.h (in Linux it's in
> /usr/include/arpa/nameser.h) and see whether it defines any of those
> names (the ns_t_xxx ones and/or the T_xxx ones).


It does. That's what surprised me: the ns_t_xxx ones are defined (otherwise
it would not compile after my edits). What I don't understand is why the
compiler tried to use the T_xxx ones at all!

OSX uses /usr/include/arpa/nameser.h (also linked to
/usr/include/bind/arpa/nameser.h) , and I also have a MacPorts version at
/opt/local/include/bind/arpa/nameser.h. Both versions define ns_t_a, which
is what fakens.c looks for, so I'm baffled that it tried. Unless, of
course, nameser.h wasn't read, and actually ns_t_a isn't actually required.

--
Ian Eiloart
IT Services, University of Sussex