GNU bug report logs - #11863
Building test plugins

Previous Next

To reply to this bug, email your comments to 11863 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: bug-automake <bug-automake <at> gnu.org>
Subject: Building test plugins
Date: Wed, 4 Jul 2012 21:43:24 +0100

I have a library that I want to build just for tests. Hence, I add it
to check_LTLIBRARIES. It's a plugin, so I want the .so (or .dll or
whatever) to be built, but it isn't!

If I instead add the library to pkglib_LTLIBRARIES, then the shared
object is built, but the test library is installed, which is not what
I want.

Reading the automake & libtool manuals, I can't see anything about
what exactly triggers building of the shared object; can someone tell
me what I should do in this instance to get a shared object for tests
only?

-- 
http://rrt.sc3d.org

Message #8 received at 11863 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: 11863 <at> debbugs.gnu.org
Subject: Re: bug#11863: Building test plugins
Date: Thu, 05 Jul 2012 00:35:13 +0200

tags 11863 + moreinfo
thanks

On 07/04/2012 10:43 PM, Reuben Thomas wrote:
> I have a library that I want to build just for tests. Hence, I add it
> to check_LTLIBRARIES. It's a plugin, so I want the .so (or .dll or
> whatever) to be built, but it isn't!
>
It isn't built when you run "make check"?  That is a bug.
It isn't built when you run "make all"?  That is a expected.

As the documentation says:

   The special prefix 'check_' indicates that the objects in question
   should not be built until the "make check" command is run.  Those
   objects are not installed either.

> If I instead add the library to pkglib_LTLIBRARIES, then the shared
> object is built, but the test library is installed, which is not what
> I want.
> 
> Reading the automake & libtool manuals, I can't see anything about
> what exactly triggers building of the shared object; can someone tell
> me what I should do in this instance to get a shared object for tests
> only?
> 

HTH,
  Stefano

Message #13 received at 11863 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 11863 <at> debbugs.gnu.org
Subject: Re: bug#11863: Building test plugins
Date: Wed, 4 Jul 2012 23:39:11 +0100

On 4 July 2012 23:35, Stefano Lattarini <stefano.lattarini <at> gmail.com> wrote:
> tags 11863 + moreinfo
> thanks
>
> On 07/04/2012 10:43 PM, Reuben Thomas wrote:
>> I have a library that I want to build just for tests. Hence, I add it
>> to check_LTLIBRARIES. It's a plugin, so I want the .so (or .dll or
>> whatever) to be built, but it isn't!
>>
> It isn't built when you run "make check"?

The library is built, but no .so.

Maybe some traces will help show the difference.

With libalientest.la in pkglib_LTLIBRARIES:

$ make check
  CC     tests/alientest.lo
  CC     src/alien.lo
  CCLD   tests/libalientest.la
  CCLD   src/alien_c.la
make
make[1]: Entering directory `/home/rrt/repo/alien'
make  all-am
make[2]: Entering directory `/home/rrt/repo/alien'
make[2]: Leaving directory `/home/rrt/repo/alien'
make[1]: Leaving directory `/home/rrt/repo/alien'
make  check-local
make[1]: Entering directory `/home/rrt/repo/alien'
cp src/.libs/alien_c.so src/
cd tests && LUA_INIT= LUA_PATH="/home/rrt/repo/alien/src/?.lua;;"
LUA_CPATH="/home/rrt/repo/alien/src/?.so;;"
LD_LIBRARY_PATH="/home/rrt/repo/alien/tests/.libs"
/home/rrt/local/x86_64/bin/lua test_alien.lua
/home/rrt/repo/alien/tests
................................................
tests completed OK!
rm -f src/alien_c.so

With libalientest.la in check_LTLIBRARIES:

$ make check
  CC     src/alien.lo
  CCLD   src/alien_c.la
make  tests/libalientest.la
make[1]: Entering directory `/home/rrt/repo/alien'
  CC     tests/alientest.lo
  CCLD   tests/libalientest.la
make[1]: Leaving directory `/home/rrt/repo/alien'
make  check-local
make[1]: Entering directory `/home/rrt/repo/alien'
cp src/.libs/alien_c.so src/
cd tests && LUA_INIT= LUA_PATH="/home/rrt/repo/alien/src/?.lua;;"
LUA_CPATH="/home/rrt/repo/alien/src/?.so;;"
LD_LIBRARY_PATH="/home/rrt/repo/alien/tests/.libs"
/home/rrt/local/x86_64/bin/lua test_alien.lua
/home/rrt/repo/alien/tests
/home/rrt/local/x86_64/bin/lua: /home/rrt/repo/alien/src/alien.lua:73:
library alientest not found
stack traceback:
	[C]: in function 'error'
	/home/rrt/repo/alien/src/alien.lua:73: in function '?'
	/home/rrt/repo/alien/src/alien.lua:93: in function
</home/rrt/repo/alien/src/alien.lua:92>
	/home/rrt/repo/alien/src/alien.lua:99: in function 'load'
	test_alien.lua:3: in main chunk
	[C]: ?
make[1]: *** [check-local] Error 1
make[1]: Leaving directory `/home/rrt/repo/alien'
make: *** [check-am] Error 2

-- 
http://rrt.sc3d.org

Message #16 received at 11863 <at> debbugs.gnu.org (full text, mbox):

From: "Gary V. Vaughan" <gary <at> gnu.org>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: 11863 <at> debbugs.gnu.org, Stefano Lattarini <stefano.lattarini <at> gmail.com>
Subject: Re: bug#11863: Building test plugins
Date: Thu, 5 Jul 2012 13:19:04 +0700

Hi Reuben,

On 5 Jul 2012, at 05:39, Reuben Thomas wrote:
> On 4 July 2012 23:35, Stefano Lattarini <stefano.lattarini <at> gmail.com> wrote:
>> tags 11863 + moreinfo
>> thanks
>> 
>> On 07/04/2012 10:43 PM, Reuben Thomas wrote:
>>> I have a library that I want to build just for tests. Hence, I add it
>>> to check_LTLIBRARIES. It's a plugin, so I want the .so (or .dll or
>>> whatever) to be built, but it isn't!
>>> 
>> It isn't built when you run "make check"?
> 
> The library is built, but no .so.

check_LTLIBRARIES works somewhat like noinst_LTLIBRARIES, in that Automake
instructs libtool to build a convenience archive by default in both cases
(a convenience archive being a static archive of pic objects).

Arguably that's not the right thing for check_LTLIBRARIES, for exactly the
reasons you have been tripped up by here.  And I'd be in favour of changing
the semantics of check_LTLIBRARIES accordingly - libltdl based module
loaders will continue to cope just fine because the .la file is examined
to determine how to link and load the module.

Currently the best way to tell Automake to only build a libtool library
for `make check' without installing it, but at the same time to tell libtool
not to make a convenience archive is:

  check_LTLIBRARIES += tests/libalientest.la

  tests_libalientest_la_LDFLAGS = -module -avoid-version -rpath /dev/null

The -rpath argument tells libtool that this is not a convenience archive.
The parameter can be anything, because Automake will not install a
check_LTLIBRARIES object anyway, but /dev/null makes it clearer that we'r
doing something a bit odd here.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

Message #19 received at 11863 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: "Gary V. Vaughan" <gary <at> gnu.org>
Cc: 11863 <at> debbugs.gnu.org, Stefano Lattarini <stefano.lattarini <at> gmail.com>
Subject: Re: bug#11863: Building test plugins
Date: Thu, 5 Jul 2012 08:32:48 +0100

On 5 July 2012 07:19, Gary V. Vaughan <gary <at> gnu.org> wrote:
>
> Currently the best way to tell Automake to only build a libtool library
> for `make check' without installing it, but at the same time to tell libtool
> not to make a convenience archive is:
>
>   check_LTLIBRARIES += tests/libalientest.la
>
>   tests_libalientest_la_LDFLAGS = -module -avoid-version -rpath /dev/null
>
> The -rpath argument tells libtool that this is not a convenience archive.
> The parameter can be anything, because Automake will not install a
> check_LTLIBRARIES object anyway, but /dev/null makes it clearer that we'r
> doing something a bit odd here.

Thanks very much, that does exactly what I'm after.

-- 
http://rrt.sc3d.org

Message #22 received at 11863 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: "Gary V. Vaughan" <gary <at> gnu.org>
Cc: 11863 <at> debbugs.gnu.org, Reuben Thomas <rrt <at> sc3d.org>
Subject: Re: bug#11863: Building test plugins
Date: Thu, 05 Jul 2012 11:55:33 +0200

tags 11863 - moreinfo
thanks

On 07/05/2012 08:19 AM, Gary V. Vaughan wrote:
> Hi Reuben,
> 
> On 5 Jul 2012, at 05:39, Reuben Thomas wrote:
>> On 4 July 2012 23:35, Stefano Lattarini <stefano.lattarini <at> gmail.com> wrote:
>>> tags 11863 + moreinfo
>>> thanks
>>>
>>> On 07/04/2012 10:43 PM, Reuben Thomas wrote:
>>>> I have a library that I want to build just for tests. Hence, I add it
>>>> to check_LTLIBRARIES. It's a plugin, so I want the .so (or .dll or
>>>> whatever) to be built, but it isn't!
>>>>
>>> It isn't built when you run "make check"?
>>
>> The library is built, but no .so.
> 
> check_LTLIBRARIES works somewhat like noinst_LTLIBRARIES, in that Automake
> instructs libtool to build a convenience archive by default in both cases
> (a convenience archive being a static archive of pic objects).
> 
> Arguably that's not the right thing for check_LTLIBRARIES, for exactly the
> reasons you have been tripped up by here.  And I'd be in favour of changing
> the semantics of check_LTLIBRARIES accordingly - libltdl based module
> loaders will continue to cope just fine because the .la file is examined
> to determine how to link and load the module.
>
I'll gladly accept a patch in this direction, if you, as a libtool
maintainer, think it would offer better semantics.

> Currently the best way to tell Automake to only build a libtool library
> for `make check' without installing it, but at the same time to tell libtool
> not to make a convenience archive is:
> 
>   check_LTLIBRARIES += tests/libalientest.la
> 
>   tests_libalientest_la_LDFLAGS = -module -avoid-version -rpath /dev/null
> 
> The -rpath argument tells libtool that this is not a convenience archive.
> The parameter can be anything, because Automake will not install a
> check_LTLIBRARIES object anyway, but /dev/null makes it clearer that we'r
> doing something a bit odd here.
> 
> Cheers,

Regards,
  Stefano

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.