This question may not make much sense if my understanding of both the pkg-config and environment modules is somewhat incorrect, but I'll ask anyways as I could not find anything specific on this topic. There might be an entirely better solution available, if that is the case, I am all ears!
I while back I started using modules to easily load my development environment as needed (i.e. using commands like module load foo etc.). More recently, I have adopted the meson build system for my projects. In meson, libraries are treated as dependencies, which are found using pkg-config in the background instead. So now I have two ways of discovering libraries and setting up their lib and include directory.
As an example, I have the following (simplified) module script for library foo (I am using lmod which is based on lua):
prepend_path("LD_LIBRARY_PATH", "/opt/foo/lib")
prepend_path("CPATH", "/opt/foo/include")
I could also have a pkg-config file (*.pc) doing something similar like (that is, if my understanding of pkg-config is correct)
prefix=/opt/foo
includedir=${prefix}/include
libdir=${exec_prefix}/lib
Name: foo
Cflags: -I${includedir}
Libs: -L${libdir} -lfoo
Now both seem to be doing pretty much the same thing (in terms of setting up my environment), but simply using modulefiles will not allow meson to find my dependencies and I still have to use pkg-config (which requires basically creating two files, either manually or dynamically, but that sounds like a maintenance burden and also not very clean). Equally, I could create the pkg-config file and add the location of that file into the PKG_CONFIG_PATH, i.e. something like
prepend_path("LD_LIBRARY_PATH", "/opt/foo/lib")
prepend_path("CPATH", "/opt/foo/include")
prepend_path("PKG_CONFIG_PATH", /path/to/*.pc/file)
but again this requires two files (pkg and module). I rather like the module environment and so don't want to ditch that, so is there a better / cleaner way of doing things, where I just load a module file which will allow pkg-config (and thus meson in turn) to know about the dependency?
As of today, there is no bridge between the environment module and the pkg-config tools. The best thing I think that could be achieved to keep the module system, is to have a script that queries every pkg-config files available and create the corresponding modulefile. And run that script regularly to keep things in sync.
Related
I am trying to build a library with a different build system, but files in the library require a config.h header file that is generated after running the configure scripts generated by autoconf.
This is the sequence of steps I am following to try and generate the config.h file that is needed
autoreconf -ivf
./configure --disable-dependency-tracking
The build system guarantees that the library gflags will be linked and the headers will be available at preprocessing time. But the configure script exits with the following error
configure: error: Please install google-gflags library
Is there some way I can get the list of required libraries (such as gflags) and then pass arguments to the configure script that tells it to assume that this library exists on the system? I went through the help output for both autoreconf and ./configure and wasn't able to figure this out.
Sorry for the long explanation and problem. I am very new to autoconf, etc.
The answer to your question is: no, it is not possible to get a list of dependencies from autotools.
Why?
Well, autotools doesn't track dependencies at all.
Instead, it checks whether specific features are present on the system (e.g. a given header-file; or a given library file).
Now a specific header file can come from a variety of sources, e.g. depending on your distribution the foo.h header can be installed via
libfoo-dev (Debian and derivatives)
foo-devel (Fedora)
foo (upstream)
...
In your specific case, the maintainers of your project output a nice error message telling you to install a given package by name.
The maintainers of your project also chose to abort with a fatal error if a given dependency is not available.
The reason might well be, that the project simply won't work without that dependency, and that is impossible to compile the program without it.
Example
Your project might be written in C++ and thus require a C++-compiler.
Obviously there is little use in passing some flags to ./configure so it assumes that there is a C++-compiler available if in reality there is none.
There is hope
However, not all is bad.
Your configure script might will have the ability to disable certain features (that appear to be hard requirements by default).
Just check ./configure --help and look for flags like
--enable-FOO
--disable-FOO
--with-BAR
--without-BAR
automation?
One thing to know about autotools, is that configure really is a program (the source-code being configure.ac) written in some arcane programming language (involving bash and m4),
This means that it can practically have any behavior, and there is no single standard way to achieve "dependecy tracking".
What you're trying to do will not work as umläute already said. On the other hand, depending on the package you're trying to build, you may be able to tell ./configure that a given library is there even if it isn't.
For instance if the script uses pkg-config to check for the presence of a library, you can use FOO_CFLAGS and FOO_LIBS to override the presence checking and telling it "yes those packages are there, you just don't know how to find them", but these are very package-specific so you may have to provide more information if that's what you're looking for.
I'm trying to install ncurses to a non system-wide prefix (for cross compilation).
Everything worked fine and I was able to install ncurses to the specified prefix, with the header files residing in <prefix>/include/ncurses.
A program I'm trying to compile (specifically GHC) doesn't find the headers, because it tries to #include <ncurses.h>, which doesn't work. (include <ncurses/ncurses.h> does work though, but GHC doesn't try this.)
So I thought installing the headers to <prefix>/include directly would do the trick, but I wasn't able to this. Passing --includedir=<prefix>/include to the configure script of ncurses didn't give the desired result, because the installed ncurses.h then tries to #include <include/ncurses_dll.h>, which doesn't work.
<prefix>/include is of course in the search path of the used CPP.
As a rule, --includedir for autoconf-based configure scripts is used to tell the makefiles where to install header files, not where to include them from during compilation.
Instead, the options that you might want to set would be in the CPPFLAGS variable. For instance, since GHC expects the ncurses header files only in the standard location, you might work around the problem by specifying both of the directories as -I options in CPPFLAGS.
Here are a few discussions to help:
4.8.1 Preset Output Variables (autoconf manual)
how to set include paths with autotools
With autoconf/automake, how do I specify include file paths?
What is the difference between DEFS and CPPFLAGS in autoconf and automake
By the way, that prefix/lib looks odd...
Regarding the comment about --disable-overwrite, Linux and some other platforms default to enabling this feature. OSX for one does not. At the end of configuring, the configure script runs a makefile rule to show the resulting configuration. If overwrite is disabled, you would see a message like this:
** Include-directory is not in a standard location
Maybe I am asking a silly question, but is there any way I can tell automake to put my project include files when I do a "make dist" but not when I do a "make install"?
Maybe I am not acting the right way, so to make it clearer I will tell what I need.
I need to deploy my applications in an embedded board and I use "make install" in a script to create a package that can be copied to the target board.
On the other side, I'd like to be able to update my toolchain with my libraries and include files.
In the first situation, I can't have any fat wasting my limited flash memory but just the necessary things to make the application to run.
In the second one, I need to have headers, pkgconfig and all of the stuff needed for development.
How I am supposed to configure my "Makefile.am" and which rules to expect so that I can reach my goals?
Really thanks.
I just want to be able to set a given script SUID, other data files
R/W arbitrary permissions and so on.
I think adding the $(DESTDIR) 's makefile user variable do that.
As it is not define by automake, "make install" use it empty,
but dpkg-buildpackage define it with the "make dist" target.
(see: http://www.gnu.org/prep/standards/html_node/DESTDIR.html#DESTDIR)
It help me to manage setuid install:
configure.ac:
# Add option to disable setuid during install, use in distcheck
AC_ARG_ENABLE(setuid-install,
AS_HELP_STRING(
[--disable-setuid-install do not set setuid flags during install]),
[enable_setuid_install=$enableval], [enable_setuid_install="yes"])
AM_CONDITIONAL(SETUID_INSTALL, test x"$enable_setuid_install" = "xyes")
Makefile.am:
if SETUID_INSTALL
install-data-hook:
/bin/chmod 4755 $(DESTDIR)$(bindir)myBinary
endif
I don't think autoconf was really designed to be a generic installer/uninstaller that'll give you that kind of control without at least some pain. You're looking for something like dpkg-buildpackage or rpmbuild where you can split up the output of make install into specific subpackages so you can have:
Package foo be for the embedded board and possibly toolchain, depending on what's in the package (DSOs, executables, and other files necessary at runtime)
Package foo-dev or foo-devel for the toolchain (headers, static libs, other files needed for development).
I'm trying to help the Ruby guys get the code working again on AIX. The Ruby guys are trying to use pkg-config to help users write modules. On AIX, the final link of the module needs to specify the entry point. In Ruby, the convention is to name that entry point Init_foo where "foo" is the module that is being added. Thus they need to add a flag: -eInit_foo
But since Init_foo is not a constant, pkg-config barfs when the ruby.pc file is given to pkg-config. I don't see a way to have variables in the pkg-config file that depend upon the target.
I thought I would ask here how this problem might be solved.
I am trying to compile c-sources with the configure, make, make install trilogy.
Since I want to compile the sources so that they use another library (XYZ) that is not used by default, I can specify that with a
./configure --with-XYZ=yes
However, for the moment, XYZ is not installed in a default location, so I guess I can specify the path to the location of XYZ with that same configure script. If my guess is right, I'd appreciate if someone could point me towards the right direction of how to do that.
Specify the library path on the command line like this:
./configure --with-XYZ=yes LDFLAGS=-L/path/to/xyz
The most general way is to specify the LDFLAGS (for -L) and CPPFLAGS (for -I) variables, like ptomato described.
In many cases, there are other ways that are specific to the option and the package that provides it. Sometimes it might be --with-XYZ=PATH, sometimes it could be --with-XYZ-path=PATH, sometimes pkg-config is involved. You need to read the particular installation documentation, or more often than not do some detective work.