Adding pkgconfig support for other autotools modules

[Thierry GAYET (Rennes)]

hi,

i have download the latest google test package and i have seen after
compilation, that any gtest.pc was installed on my /usr/lib/pkgconfig
directory.

I have modified the google test autotools files in order to add a .pc
file used by pkg-config.

If you are interested i send you here an unix patch i have generated
with this fix. I have talked with some other people that are using
gtest and i was surprised that have done it too, that's why i am
asking today to merge it in your next release.

The patch include :

- a bootsrap.sh script for generating end autotools scripts
- an autogen.sh script for automating the full generation (./
bootstrap.sh and ./configure)
- a gtest.pc.in template for the <stagindir>/usr/lib/pkgconfig/
gtest.pc
- a modification of the configure.ac template file
- a modification of the makefile.am template file

Here is the patch :

diff -Naur gtest-1.5.0-original/bootstrap.sh gtest-1.5.0-last/
bootstrap.sh
--- gtest-1.5.0-original/bootstrap.sh 1970-01-01 01:00:00.000000000
+0100
+++ gtest-1.5.0-last/bootstrap.sh 2010-06-09 11:42:24.000000000 +0200
@@ -0,0 +1,72 @@
+#!/bin/bash
+# Run this to bootstrap the files
+
+PACKAGE=gtest
+
+srcdir=`dirname $0`
+test -z "$srcdir" && srcdir=.
+
+DIE=0
+
+# check if configure.ac is there
+(test -f $srcdir/configure.ac) || {
+ echo -n "**Error**: Directory "\`$srcdir\'" does not look like
the"
+ echo " top-level package directory"
+ exit 1
+}
+
+# check for autoconf
+(autoconf --version) < /dev/null > /dev/null 2>&1 || {
+ echo
+ echo "**Error**: You must have \`autoconf' installed."
+ echo "Download the appropriate package for your distribution,"
+ echo "or get the source tarball at ftp://ftp.gnu.org/pub/gnu/"
+ DIE=1
+}
+
+# check for libtool
+(libtool --version) < /dev/null > /dev/null 2>&1 || {
+ echo
+ echo "**Error**: You must have \`libtool' installed."
+ echo "You can get it from: ftp://ftp.gnu.org/pub/gnu/"
+ DIE=1
+}
+
+# check for automake
+(automake --version) < /dev/null > /dev/null 2>&1 || {
+ echo
+ echo "**Error**: You must have \`automake' installed."
+ echo "You can get it from: ftp://ftp.gnu.org/pub/gnu/"
+ DIE=1
+ NO_AUTOMAKE=yes
+}
+
+
+# if no automake, don't bother testing for aclocal
+test -n "$NO_AUTOMAKE" || (aclocal --version) < /dev/null > /dev/null
2>&1 || {
+ echo
+ echo "**Error**: Missing \`aclocal'. The version of \`automake'"
+ echo "installed doesn't appear recent enough."
+ echo "You can get automake from ftp://ftp.gnu.org/pub/gnu/"
+ DIE=1
+}
+
+if test "$DIE" -eq 1; then
+ exit 1
+fi
+
+echo "Running libtoolize..."
+libtoolize --force --copy
+
+aclocalinclude="$ACLOCAL_FLAGS"
+echo "Running aclocal $aclocalinclude ..."
+aclocal $aclocalinclude
+
+echo "Running automake..."
+automake --add-missing --foreign $am_opt
+
+echo "Running autoconf ..."
+autoconf
+
+echo "You could now exec ./configure --help to see available options"
+
diff -Naur gtest-1.5.0-original/configure.ac gtest-1.5.0-last/
configure.ac
--- gtest-1.5.0-original/configure.ac 2010-04-16 00:02:09.000000000
+0200
+++ gtest-1.5.0-last/configure.ac 2010-06-09 11:42:24.000000000 +0200
@@ -14,7 +14,7 @@
AC_CONFIG_SRCDIR([./COPYING])
AC_CONFIG_AUX_DIR([build-aux])
AC_CONFIG_HEADERS([build-aux/config.h])
-AC_CONFIG_FILES([Makefile])
+#AC_CONFIG_FILES([Makefile])
AC_CONFIG_FILES([scripts/gtest-config], [chmod +x scripts/gtest-
config])

# Initialize Automake with various options. We require at least v1.9,
prevent
@@ -64,4 +64,7 @@
# and architecture characteristics.

# Output the generated files. No further autoconf macros may be used.
-AC_OUTPUT
+AC_OUTPUT(
+ Makefile
+ gtest.pc
+)
diff -Naur gtest-1.5.0-original/gtest.pc.in gtest-1.5.0-last/
gtest.pc.in
--- gtest-1.5.0-original/gtest.pc.in 1970-01-01 01:00:00.000000000
+0100
+++ gtest-1.5.0-last/gtest.pc.in 2010-06-09 11:42:24.000000000 +0200
@@ -0,0 +1,11 @@
+prefix=@prefix@
+exec_prefix=@exec_prefix@
+libdir=@libdir@
+includedir=@includedir@
+
+Name: libgtest
+Description: Google test framework for the C/C++ language
+Requires: pthread
+Version: @VERSION@
+Libs: -L${libdir} -lgtest
+Cflags: -I${includedir}/gtest
diff -Naur gtest-1.5.0-original/Makefile.am gtest-1.5.0-last/
Makefile.am
--- gtest-1.5.0-original/Makefile.am 2010-04-16 00:02:08.000000000
+0200
+++ gtest-1.5.0-last/Makefile.am 2010-06-09 11:42:24.000000000 +0200
@@ -1,5 +1,8 @@
# Automake file

+pkgconfigdir = $(libdir)/pkgconfig
+pkgconfig_DATA = gtest.pc
+
# Nonstandard package files for distribution
EXTRA_DIST = \
CHANGES \

Best regards

A+
Thierry GAYET

[Zhanyong Wan (λx.x x)]

Thanks for contributing, Thierry!

Chandler, would you be able to evaluate this (how severe it is,
whether the patch is good, etc)? We are switching to cmake, but will
probably need to support autotools as a legacy build script for a
while. If it's a big pain for the users, we should fix it. Thanks,

--
Zhanyong

[Zhanyong Wan (λx.x x)]

Adding back the mailing list and Chandler...

On Wed, Jun 9, 2010 at 11:10 AM, Thierry GAYET <thierr...@gmail.com> wrote:
> hi,
>
> I am currently use it and it work fine so if you need something more about
> don't hesitate to ask to me.
>
> Can u also telle me if you will accept it or not. thus i will follow the
> original release instead of my fixed one instead.
>
> Regards
>
> Thierry GAYET
>
> Zhanyong Wan (λx.x x) a écrit :

[Thierry GAYET]

hi,

I have another question about google test. In fact in our project, we have both C++ and also some C source code.

While i was investigating on the possibility to use a single unit test framework i have found and test yours with success.

Beside i have found others usefull links that was related some experience with C testing using gtest :
  http://stackoverflow.com/questions/148576/how-to-test-c-code
  http://github.com/meekrosoft/helloc

Before to start in this way i wanted to know your point of view about it ?

While your coding have been targeted for c++ source code, what is according to you the best vay to also test C code ; does the previous link can answer our question ?

If so have you ever planned to add it in your next roadmap ?

Thanks for your reply

Best regards

[Zhanyong Wan (λx.x x)]

C++ is mostly a superset of C, and can link with C code. Therefore
you can use gtest to test C code.

--
Zhanyong

[Vlad Losev]

2010/6/9 Zhanyong Wan (λx.x x) <w...@google.com>

C++ is mostly a superset of C, and can link with C code.  Therefore
you can use gtest to test C code.

This is mostly true but one should be looking out for gotchas when mixing C and C++.

A purely C library would take care of such issues (it would introduce a lot of its own, of course). I have heard good words of cmockery.
 

[Vlad Losev]

Zhanyong --

In light of the decision not to support installing Google Test into system directories, accepting this patch makes little sense. Of course, it is possible to reconsider that decision, given how many people seem to be using the feature, even with all its drawbacks. ;-)

Thierry --  Google Test currently provides the gtest-config script. That script, AFAICT, provides essentially the same functionality as the pkg-config patch you are offering. Are there specific reasons as to why that script isn't sufficient for your purposes?

Regards,
Vlad

2010/6/9 Zhanyong Wan (λx.x x) <w...@google.com>

Thanks for contributing, Thierry!

[Zhanyong Wan (λx.x x)]

On Wed, Jun 9, 2010 at 12:40 PM, Vlad Losev <vl...@google.com> wrote:
> Zhanyong --
>
> In light of the decision not to support installing Google Test into system
> directories, accepting this patch makes little sense. Of course, it is
> possible to reconsider that decision, given how many people seem to be using
> the feature, even with all its drawbacks. ;-)

Thanks, Vlad. I didn't know that pkg-config is for installed gtest. :)

I'd like to restate that we do *not* intend to support installing
gtest into system directories. It just lead to big pain down the road
too easily.

--
Zhanyong

[Chandler Carruth]

On Wed, Jun 9, 2010 at 12:45 PM, Zhanyong Wan (λx.x x) <w...@google.com> wrote:

On Wed, Jun 9, 2010 at 12:40 PM, Vlad Losev <vl...@google.com> wrote:
> Zhanyong --
>
> In light of the decision not to support installing Google Test into system
> directories, accepting this patch makes little sense. Of course, it is
> possible to reconsider that decision, given how many people seem to be using
> the feature, even with all its drawbacks. ;-)

Thanks, Vlad.  I didn't know that pkg-config is for installed gtest. :)

I'd like to restate that we do *not* intend to support installing
gtest into system directories.  It just lead to big pain down the road
too easily.

+1. That makes pkg-config a non-issue, and I'm also not fond of lots of other side-effects of this change. I'd like to focus on making googletest and googlemock more easily dropped into existing code bases rather than more easily installed or leveraged by distributions.

[Thierry GAYET]

hi,

For your information the pkg-config is today really well integrated to the autotools and not dependant to a specific distribution.

Thus, this is possible to use some commands:

pkg-config --exist --print-errors gtest : test if the libgest is installed
pkg-config --cflags gtest : give all the cflags for the compilation step
pkg-config --libs gtest : give all the ldflags for the link step

Then in another autotools files (configure.ac) this is possible to do :

PKG_CHECK_MODULES([GTEST],[gtest],[have_libgtest=yes],[have_libgtest=no])
if test "$have_libgtest" = no ; then
   AC_MSG_ERROR([Missing libgtest library!!])
fi

Easy and very usefull isn't it thanks to the buildin m4 macro. Today linux distributions are using .pc files as a standard through autotools projects.

What do you think about it ? Still opposed on the integration of my patch ?

A+
Thierry

2010/6/9 Zhanyong Wan (λx.x x) <w...@google.com>

Adding back the mailing list and Chandler...

--
A+
Thierry GAYET
+33.663.849.589
www.nextinnovation.org
www.apprendreindonesien.com

[Chandler Carruth]

On Thu, Jun 10, 2010 at 1:07 AM, Thierry GAYET <thierr...@gmail.com> wrote:

hi,

For your information the pkg-config is today really well integrated to the autotools and not dependant to a specific distribution.

I'm well aware, but the integration isn't as good as you make it out to be. It is well integrated into *some* versions of autotools, but not others. The variance of autotools and systems is incredible, so this does cause a support burden.

 

Thus, this is possible to use some commands:

pkg-config --exist --print-errors gtest : test if the libgest is installed
pkg-config --cflags gtest : give all the cflags for the compilation step
pkg-config --libs gtest : give all the ldflags for the link step

This is only possible if you *install* the package. As explained in the other emails, we are not recommending the installation of gtest of gmock. Instead, they should be packaged as part of the source code for a project. This is natural, as their sole purpose is the testing of that source code.

 

 Then in another autotools files (configure.ac) this is possible to do :

PKG_CHECK_MODULES([GTEST],[gtest],[have_libgtest=yes],[have_libgtest=no])
if test "$have_libgtest" = no ; then
   AC_MSG_ERROR([Missing libgtest library!!])
fi

This too only works for installed packages, and requires their configure.ac to be set up very specifically. I have seen this fail on numerous platforms and OSes.

 

Easy and very usefull isn't it thanks to the buildin m4 macro. Today linux distributions are using .pc files as a standard through autotools projects.

What do you think about it ? Still opposed on the integration of my patch ?

The opposition is not due to pkg-config (i *do* object to it, but that's besides the point). It is to any effort to support installation of gtest.

Thanks for contributing, and sorry to say no here, but I don't think this solves a real problem for gtest currently. Do let us know if there is some reason you *need* to install it on a system. I'd like to understand that problem, and see if we can solve it by removing the need rather than easing the installation.

[Thierry GAYET]

hi,

Okay for your reply.

I am working for a big industrial that develop some software on specific hardware.

The google test have been selected among a big list available for free and according for their features.

We are using a Continuous Integration server with Hudson and the google test package is used as well as xunit for unit and no-regression test.

We are working in a cross-compilation environment through Buildroot that generate root filesystem for our embedded system.

Thus this is not possible to include it with each system and it was easier to install it on our system and 'cos all our packages are autotools based, its was needed to have a pkg-config support through a .pc file.

Is this view interesting for you ?

Regards

Thierry GAYET

2010/6/10 Chandler Carruth <chan...@google.com>

[Hady Zalek]

Hi,

I'm not sure this is the same problem, but I actually do have a need to 'install' gtest/gmock. Not necessarily with autotools though....

We maintain a thirdparty binary repository to avoid recompiling code that rarely changes. The compilation options are guaranteed to be consistent with the 'user' code. When deploying a new version of gtest, I used to be able to 'make install'. Now I have to manually copy the binaries and includes into their respective directories which is error-prone. I agree that installing into system folders is not very safe, but what about this particular case?

That being said, would it be possible to add an 'INSTALL' command to the CMake script?

Cheers,

Hady

2010/6/10 Chandler Carruth <chan...@google.com>

[Chandler Carruth]

On Thu, Jun 10, 2010 at 1:27 AM, Thierry GAYET <thierr...@gmail.com> wrote:

hi,

Okay for your reply.

I am working for a big industrial that develop some software on specific hardware.

The google test have been selected among a big list available for free and according for their features.

We are using a Continuous Integration server with Hudson and the google test package is used as well as xunit for unit and no-regression test.

We are working in a cross-compilation environment through Buildroot that generate root filesystem for our embedded system.

Thus this is not possible to include it with each system and it was easier to install it on our system and 'cos all our packages are autotools based, its was needed to have a pkg-config support through a .pc file.

Is this view interesting for you ?

If you already have something that is pushing code onto build slaves, it seems like you would be able to push gtest, either in source or library form, as well. All in all, this seems a pretty special case, and so it might just make sense to maintain the pkg-config tools you need internally; I'm skeptical about other users of gtest encountering this problem and needing to take the system-installation approach to solving it. Certainly I know of a few similar situations where the oposite direction was taken -- embedding the source *in order* to leverage the existing CI infrastructure.

[Chandler Carruth]

On Thu, Jun 10, 2010 at 1:29 AM, Hady Zalek <hady....@gmail.com> wrote:

Hi,

I'm not sure this is the same problem, but I actually do have a need to 'install' gtest/gmock. Not necessarily with autotools though....

We maintain a thirdparty binary repository to avoid recompiling code that rarely changes. The compilation options are guaranteed to be consistent with the 'user' code. When deploying a new version of gtest, I used to be able to 'make install'. Now I have to manually copy the binaries and includes into their respective directories which is error-prone. I agree that installing into system folders is not very safe, but what about this particular case?

This is a more common case I suspect.

 

That being said, would it be possible to add an 'INSTALL' command to the CMake script?

I wouldn't be hugely opposed to some command to the CMake build system that would "bundle" the build outputs and the headers into a dumb tree (ie, a flat set of ./{bin,lib,include}/...) perhaps with facilities to build tarballs of it. Focus it on 1) static library linking, and 2) assuming little-to-nothing about the underlying OS. This becomes more of a binary distribution tool than an installation tool.

All this said, does it really merit this complexity? the includes are trivial -- it's already a separate tree. The libraries should consist of only 2 files. It seems like overkill at the end of the day.

[Thierry GAYET]

hi,

2010/6/10 Chandler Carruth <chan...@google.com>

On Thu, Jun 10, 2010 at 1:29 AM, Hady Zalek <hady....@gmail.com> wrote:

Hi,

I'm not sure this is the same problem, but I actually do have a need to 'install' gtest/gmock. Not necessarily with autotools though....

We maintain a thirdparty binary repository to avoid recompiling code that rarely changes. The compilation options are guaranteed to be consistent with the 'user' code. When deploying a new version of gtest, I used to be able to 'make install'. Now I have to manually copy the binaries and includes into their respective directories which is error-prone. I agree that installing into system folders is not very safe, but what about this particular case?

This is a more common case I suspect.

I,i think so 'cos as i have said at the beginning, most of the team that are using gtest are installing gtest with make install on the system.

then they are also using the autotools for accessing the libraries's data through pkg-config.

 

That being said, would it be possible to add an 'INSTALL' command to the CMake script?

I wouldn't be hugely opposed to some command to the CMake build system that would "bundle" the build outputs and the headers into a dumb tree (ie, a flat set of ./{bin,lib,include}/...) perhaps with facilities to build tarballs of it. Focus it on 1) static library linking, and 2) assuming little-to-nothing about the underlying OS. This becomes more of a binary distribution tool than an installation tool.

All this said, does it really merit this complexity? the includes are trivial -- it's already a separate tree. The libraries should consist of only 2 files. It seems like overkill at the end of the day.

Well, because lot of team are patching gtest for the same usage, why not including it in the release, that was my point of view when i have decided to send my fix.

Regards

[Hady Zalek]

Hi Chandler,

2010/6/10 Chandler Carruth <chan...@google.com>

On Thu, Jun 10, 2010 at 1:29 AM, Hady Zalek <hady....@gmail.com> wrote:

Hi,

I'm not sure this is the same problem, but I actually do have a need to 'install' gtest/gmock. Not necessarily with autotools though....

We maintain a thirdparty binary repository to avoid recompiling code that rarely changes. The compilation options are guaranteed to be consistent with the 'user' code. When deploying a new version of gtest, I used to be able to 'make install'. Now I have to manually copy the binaries and includes into their respective directories which is error-prone. I agree that installing into system folders is not very safe, but what about this particular case?

This is a more common case I suspect.

 

That being said, would it be possible to add an 'INSTALL' command to the CMake script?

I wouldn't be hugely opposed to some command to the CMake build system that would "bundle" the build outputs and the headers into a dumb tree (ie, a flat set of ./{bin,lib,include}/...) perhaps with facilities to build tarballs of it. Focus it on 1) static library linking, and 2) assuming little-to-nothing about the underlying OS. This becomes more of a binary distribution tool than an installation tool.

I've attached a patch that enables 'make install' into any directory of your choosing. It also adds a 'make package' which generates source and binary packages. Please note that I've only tested this with CMake 2.8 under Linux.

All this said, does it really merit this complexity? the includes are trivial -- it's already a separate tree. The libraries should consist of only 2 files. It seems like overkill at the end of the day.

Well, it's not necessary, but it would make things easier on us. Especially that supporting it with CMake is trivial. You could always recommend building gtest with the source and suggest the 'install' or 'package' command if all else fails.

Cheers,

Hady