3

I want to set include and lib paths given an existing Makefile (below) in configure.ac. But I don't know how can I use $(shell XYZ-config --libs) command in configure.ac.

Could anyone help please? Thanks!!

# --------------------------------------------------------------------------
# Acquire configuration information for libraries that libs3 depends upon

ifndef CURL_LIBS
    CURL_LIBS := $(shell curl-config --libs)
endif

ifndef CURL_CFLAGS
    CURL_CFLAGS := $(shell curl-config --cflags)
endif

ifndef LIBXML2_LIBS
    LIBXML2_LIBS := $(shell xml2-config --libs)
endif

ifndef LIBXML2_CFLAGS
    LIBXML2_CFLAGS := $(shell xml2-config --cflags)
endif
Viren
  • 2,161
  • 22
  • 27

3 Answers3

5

I'd vouch for actually using pkgconfig instead of clumsy *-config scripts, which makes this a one-liner per package:

# configure.ac
PKG_CHECK_MODULES([libcurl], [curl])
PKG_CHECK_MODULES([libxml2], [libxml-2.0])

# Makefile.am
AM_CPPFLAGS = ${libcurl_CFLAGS} ${libxml2_CFLAGS}
bin_PROGRAMS = foo
foo_LDADD = ${libcurl_LIBS} ${libxml2_LIBS}

*-config scripts have a tendency to become large pieces of redundant code (just like syvVinit scripts vs. systemd unit files, for example) with deviating behavior: some -config scripts use --ccflags, others --cflags. Some use --libs, others use --ldflags—a terrible mess best avoided.

jørgensen
  • 10,149
  • 2
  • 20
  • 27
  • thanks j0rgensen. i tried using the pkg_check but i dont know how to include a lib or a header in PKG_CHECK_MODULES so I landed up using the below. I read i need to change PKG_*_PATH in environment but I will try it later sometime. Thanks again. – Viren Dec 12 '11 at 08:33
  • In case you don't have a curl.pc, you can still tell configure where it is: `./configure libcurl_CFLAGS="-I/path/to/headers" libcurl_LIBS="-L/whereever -lcurl"` – jørgensen Dec 13 '11 at 01:42
  • The user can specify everything manually, but it doesn't make a good user experience. OSX (out of box) doesn't have pkg-config but has xml2-config. – marcin Apr 30 '14 at 18:30
0

for benefits of others, putting the actual thing i used with help from answer provided by j0rgensen above. hope it will help someone sometime :)

In configure.ac: 

# Get xml2 library and include locations
AC_ARG_WITH([xml2-include-path],
  [AS_HELP_STRING([--with-xml2-include-path],
    [location of the xml2 headers, defaults to /usr/include/xml2])],
  [xml2_CFLAGS="-I$withval"],
  [xml2_CFLAGS='-I/usr/include'])
AC_SUBST([xml2_CFLAGS])

AC_ARG_WITH([xml2-lib-path],
  [AS_HELP_STRING([--with-xml2-lib-path], [location of the xml2 libraries])],
  [xml2_LIBS="-L$withval -lxml2"],
  [xml2_LIBS="-L/usr/lib -lxml2"])
AC_SUBST([xml2_LIBS])


# Get curl library and include locations
AC_ARG_WITH([curl-include-path],
  [AS_HELP_STRING([--with-curl-include-path],
    [location of the curl headers, defaults to /usr/include/curl])],
  [curl_CFLAGS="-I$withval"],
  [curl_CFLAGS='-I/Users/vshakya/durham_doll/curl/curl-7.23.1/BUILD/include'])
AC_SUBST([curl_CFLAGS])

AC_ARG_WITH([curl-lib-path],
  [AS_HELP_STRING([--with-curl-lib-path], [location of the curl libraries])],
  [curl_LIBS="-L$withval -lcurl"],
  [curl_LIBS="-L/Users/vshakya/durham_doll/curl/curl-7.23.1/BUILD/lib -lcurl"])
AC_SUBST([curl_LIBS])

Makefile.am, ditto like j0rgensen suggested above.

Viren
  • 2,161
  • 22
  • 27
  • 1
    This is a bad solution. I'll post an answer expanding on that comment. – William Pursell Dec 13 '11 at 12:59
  • Turns out the answer I just posted doesn't really address what I think is wrong with this answer. Using AC_ARG_WITH to enable the user to specify libraries is a terrible hack. What happens if /usr/foo/libcurl.a and /usr/foo/libxml2.a both exist, and the user says --with-curl=/usr/foo --with-xml2=/blah ? Answer: the user does not get what is expected. Users can set LDFLAGS, and that is standard. Using --with to specify a path instead of assigning to LDFLAGS is an exercise in futility. – William Pursell Dec 13 '11 at 13:16
-1

The package maintainer is the wrong person to be doing this work. pkg-config is a reasonable tool, but it has no place in the autotools. PKG_CHECK_MODULES should be banned.

From the package maintainer's perspective, it is the responsibility of the user (the person or process who invokes the configure script) to correctly set LDFLAGS and CPPFLAGS to inform the configure script of how the system is set up. If the user wishes to make life simple, they will setup the system so that the libraries and headers can be found by the compiler without making assignments to LDFLAGS or CPPFLAGS (eg, libraries will be in /usr/lib, headers in /usr/include). If the user wishes to make life difficult, that is the user's choice and the package maintainer should not worry about fixing the user's bad decisions. If a user chooses to install libraries in a non-standard place and wants to use pkg-config to somewhat simplify their life in the face of that bad decision, they could use pkg-config within a config.site file to make the appropriate assignments to LDFLAGS and CPPFLAGS. pkg-config is a reasonable tool in a config.site, but it has absolutely no place in configure.ac. It is the user's issue, and not the package maintainer's.

The bottom line is that users who choose to install libraries in non-standard locations should not expect the package maintainer to fix their problem for them.

William Pursell
  • 204,365
  • 48
  • 270
  • 300
  • 1
    But pkg-config also tells what C-flags need to be used: for example, `-pthread`. This isn't something you can do by setting up your library paths. – ptomato Dec 14 '11 at 13:42
  • @ptomato but it *is* something that can be set in a config.site, and that's where it should be done. The onus is on the user, not the package maintainer. – William Pursell Dec 14 '11 at 14:09
  • 1
    And how do you show dependencies between packages in a `config.site`? – ptomato Dec 15 '11 at 10:44
  • @ptomato: I'm not sure I understand the question fully. The basic mechanism I'm picturing is a config.site that includes something like: LDFLAGS="$LDFLAGS $(pkg-config --libs foo)", so that any information that is provided by pkg-config is available from the config.site. – William Pursell Dec 15 '11 at 13:11
  • @ptomato: are you talking about a situation where libfoo requires libbar, and you want that dependency to be transparent to the package maintainer? I would argue that in that case, the configure.ac should AC_CHECK_LIB for libbar and that such transparency is undesirable. – William Pursell Dec 15 '11 at 13:23
  • suppose I put `LDFLAGS="$LDFLAGS $(pkg-config --libs foo)` in `config.site`. If I understand correctly, that means that _every_ program I build with Autotools will be linked with libfoo. – ptomato Dec 16 '11 at 08:06
  • also, I think the transparency of dependencies is not only desirable but necessary. For example, suppose libfoo grows some new functionality in version 2.17 that requires libbar. If the maintainer of a package using libfoo has to list libfoo's dependencies manually in `configure.ac`, then their build will break when they upgrade libfoo to 2.17. If they fix it, it will require and link to libbar unnecessarily on older systems. This isn't a made-up situation, it happens occasionally with GTK and GLib. – ptomato Dec 16 '11 at 08:12
  • It seems to me that the package maintainer should list only the dependencies they actually _use_ in the package, and pkg-config should pull in the rest. – ptomato Dec 16 '11 at 08:12
  • @ptomato regarding assigning to LDFLAGS in config.site: yes, it is a kludge and the flags for libfoo would be included in every package that is configured using that config.site. A better solution would be something like usepackage, but the best solution is to install the libraries in standard locations. This does not address getting -lbar into LIBS when a dependency is introduced; you raise a good point there, which I cannot answer at the moment. – William Pursell Dec 16 '11 at 14:08
  • @ptomato The problem you are describing is really no different than an incompatible API change. (In fact, I think it could be said that it is an incompatible change.) If the user wishes to continue to be able to build projbaz that requires a libfoo without the libbar dependency, then both the old foo and the new foo must be available. – William Pursell Dec 21 '11 at 11:29
  • It's not so much the "standard locations" that is the problem as it is CROSS-COMPILATION. If the blasted thing can't grok being built into a non-standard location (yet in a standard place within the effective filesysystem) then the code you're producing IS NOT CROSS-PLATFORM and you probably ought not to be using Autotools in the first place as that's part of the PURPOSE there. – Svartalf Jul 27 '15 at 22:51