Unit tests of internal functions
jhutz at cmu.edu
Tue Jan 5 13:50:37 EST 2010
--On Monday, January 04, 2010 02:50:42 PM -0600 Nicolas Williams
<Nicolas.Williams at sun.com> wrote:
> On Tue, Dec 29, 2009 at 11:18:44AM -0500, Greg Hudson wrote:
>> On Mon, 2009-12-28 at 15:11 -0500, ghudson at MIT.EDU wrote:
>> > 1. Just export those symbols [...]
>> > 2. Make those symbols available through the accessor [...]
>> > 3. [...] build a second version of each shared library [...]
>> > 4. [...] build static versions of each library [...]
>> More on this, based on the feedback and my own investigation:
>> Currently I favor (1). Sam suggested trying to do things the current
>> way before falling back to (1) or (2); I don't particularly like that
>> idea because the build system becomes fragile in the face of unrelated
>> future work-- when someone changes the C file containing the function
>> being unit tested, that can change the set of objects the test program
>> needs to link against.
> I favor (1). However, you could do a hybrid of (1) and (3). Namely,
> alter the symbol export list according to whether you're making the
> check target. One would "make check && make clobber && make install".
Ahhh!!!! My eyes are bleeding!!!
With _very_ few exceptions, make targets should be idempotent.
"make all check install" and "make all install" had better not install
different versions of the library.
More information about the krbdev