Using gnu automake how do I display a custom message to the user during the make install stage?
I have been reading the automake manual and various other tutorials but have not yet found an answer, it may just be hidden somewhere in the manual and I failed to find it. Please point it out if you where it's explained.
I am converting some source to use automake and near the end stage of make install I would like to display a message to tell the user they should run a particular script to set up some extra things that shouldn't be part of a automake, or can not (easily) be done in an install-data-hook or something.
Additionally is there actually a clean way to run a custom script using automake (outside of install hooks and such)? I can imagine it's big nono so I am not seriously considering it, but I am curious.
Simply include an install hook in your Makefile.am file:
install-exec-hook:
echo "Do this other thing now"
Additionally is there actually a clean way to run a custom script
using automake (outside of install hooks and such)?
Install hooks are exactly what that is for.
http://www.gnu.org/software/automake/manual/html_node/Extending-Installation.html
Related
I'm trying to follow this example to build wget2:
https://gnutoolchains.com/building/
I've installed x86_64-8.1.0-win32-seh-rt_v6-rev0 preset (?) and first tried to build old version of wget1, but I've reached dead end. There is no way to run ./configure to create build target rules. Did I install something wrong? How I'm supposed to know what exactly is to install? Is it each new preset for each application I want to build? How I'm supposed to handle the insane list of requirements of wget2:
https://gitlab.com/gnuwget/wget2#build-requirements
And lastly - why is it so jank? Is it by design?
There is a way to run ./configure on Windows. You need MSYS2 for that, which will give you a bash shell and the tools needed by ./configure.
MSYS2 comes with a package manager (pacman) which allows you to install a more recent MinGW-w64.
I have a check for a header file in configure.ac in the source root
AC_CHECK_HEADER(log4c.h,
[],
[AC_MSG_ERROR([Couldn't find or include log4c.h])])
and I'd like to give different feedback on different platform to reflect different most straight forward ways of providing the header:
on Debian it should error with the message Couldn't find or include log4c.h. Install log4c using 'sudo apt-get install liblog4c-dev'
on OpenSUSE it should error with ... Install log4c using 'sudo yum install log4c-devel' (didn't research the package name, but you catch my drift)
on other systems (where I'm too lazy to research the package name) it should error with ... Install log4c by fetching ftp://.../log4c.tar.gz and installing with './configure && make && make install' in the source root
I
checked the AM_CONDITIONAL macro, but I don't get how to use it in configure.ac rather than in Makefile.am (as described in autoconf/automake: conditional compilation based on presence of library?)
found the tip to run esyscmd in stackoverflow.com/questions/4627900/m4-executing-a-shell-command, but adding esyscmd (/bin/echo abc) to configure.ac doesn't print anything when I run autoreconf --install --verbose --force.
Both answers describing the usage of conditional macros without the shell commands for the mentioned OS and links to predefined macros (like AC_CHECK_HEADER_DEBIAN, AC_CHECK_HEADER_SUSE, etc.) are appreciated.
The following configure.ac doesn't work:
AC_INIT([cndrvcups-common], [2.90], [krichter722#aol.de])
AC_CONFIG_MACRO_DIR([m4])
AM_INIT_AUTOMAKE([foreign -Wall subdir-objects])
AC_PROG_CC
AM_PROG_AR
AM_PROG_CC_C_O
AC_MSG_NOTICE([Hello, world.])
AC_INCLUDES_DEFAULT
AC_CHECK_HEADER(check.h,
[],
[
AS_IF (test "$(lsb_release -cs)" = "vivid", [echo aaaaaa], [echo bbbbbb])
])
LT_INIT # needs to be after AM_PROGS_AR
AC_CONFIG_HEADERS([config.h])
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
because ./configure fails with
checking check.h usability... no
checking check.h presence... no
checking for check.h... no
./configure: line 4433: syntax error near unexpected token `;'
./configure: line 4433: ` if ; then :'
There's also ./configure: line 4427: #include: command not found which happens no matter whether AC_CHECK_HEADER is specified.
Your configure.ac is almost ok. The only problem is space between AS_IF and the parenthesis. No whitespace is allowed between a macro name and the opening parenthesis in m4 scripts. This is correct syntax:
AC_CHECK_HEADER(check.h,
[],
[
AS_IF(test "$(lsb_release -cs)" = "vivid", [echo aaaaaa], [echo bbbbbb])
])
If you are looking for a way to detect different distros look for example at configure.ac of cgmanager.
Update
I noticed one more problem in your configure.ac.
AC_INCLUDES_DEFAULT macro expands to a set of default includes and can't be used here. It is not needed also. It will be used by default in your AC_CHECK_HEADER macro, as you omit last parameter.
This is the cause of line 4427: #include: command not found error you mention.
Update to your comment
First of all, running a system command itself, like lsb_release is not portable. You should first check, for example with AC_CHECK_PROG, for its presence.
Regarding the syntax I would first get the output of the command using backticks: result=`lsb_release -cs` and later test resulting output: test "x$result" = "xvivid". x is needed to avoid problems with empty value in some shells.
At last, I have doubts whether configure script is a proper place for all this distro specific messages. You may consider placing it in the README file.
Avoid those system specific messages.
Print one message which allows people to figure out what package to install on their respective system, but avoid naming the system specific package names and system specific installation tools.
You will never be able to add messages for all systems, so it is better to go the part of the way which you know and let your users go the rest of the way because they know their systems better than you can.
The proper way would be to write a software package outside but called from your configure which, given a header filename, foo.pc filename, library name, etc. figures out how to install that on the respective system. Then let system specific maintainers fix that package, and call it from configure if it is installed, and issue a generic error message otherwise.
A portable shell script local to your software package might do the same job to some extent. You still have to maintain all the system specific parts for all possible systems, though.
Hmm... now that I am thinking about that, the idea appears not that bad. I might add such a script to some of the projects I maintain and see how it turns out in practical use.
I would still try to keep most of that logic outside configure, though.
I'm using an autoconf/automake configure script on cygwin, and I have the problem that it doesn't fin my dependencies.
For example I do, in my configure.ac:
AC_CHECK_LIB(mp3lame,lame_init,,AC_MSG_ERROR(Required library LAME not found.))
AC_CHECK_HEADER(lame/lame.h,,AC_MSG_ERROR(Headers for LAME not found.))
To find lame. Lame is installed, if I do locate lame.h I find it in /usr/local/include/lame/lame.h. Now, if I set LIBRARY_PATH and INCLUDE_PATH with
export INCLUDE_PATH=/usr/local/include/
export LIBRARY_PATH=/usr/local/lib/
It works as expected. I have installed lame by downloading it and running:
./configure
make
make install
So I would think that it should end up in a "standard enough" path for my configure script to find it. In a similar way, I'm checking for the json parser jansson using:
PKG_CHECK_MODULES(JANSSON,jansson)
And it doesn't find it unless I do:
export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/
Is this a problem with cygwin (I wouldn't think so) or a problem with my configure.ac script?
This is not a problem with cygwin, nor with your configure.ac. It is a "feature" of PKG_CHECK_MODULES and is one of the reasons I recommend against using it. If a configure script generated from a configure.ac that uses PKG_CHECK_MODULES is used, it is necessary that the user set PKG_CONFIG_PATH. The best approach is to use AC_CHECK_LIB instead of PKG_CHECK_MODULES. You are absolutely correct that ./configure && make && make install gives you a standard installation that should work. The problem is that PKG_CHECK_MODULES does not play well with standard installations.
I'm trying to modify GTK2 on Ubuntu Oneiric.
I download the source:
apt-get source libgtk2.0-0
cd gtk+2.0-2.24.6/
I try to compile and overwrite the current GTK2:
./configure --prefix=/usr
sudo make
Soemhow I get an error (I have all the necessary libraries and the build-essential package etc):
In file included from gtkquery.c:26:0:
gtkquery.h:31:2: error: #error "gtkfilechooserprivate.h is not supported API for general use"
By the way, I am able to modify and recompile GTK3 with no problems with the same steps.
If use debuild, I get thousands of
dpkg-source: error: cannot represent change to gtk+2.3.0-2.24.6/gtk+2.0-2.24.6/something: binary file contents changed
You won't get anything near the Ubuntu-provided build if you try building it by hand that way -- you'll miss all the ./configure options and other settings. (Look into debian/rules for the full details of what they're setting.)
Instead, try debian/rules build.
For reasons I haven't investigated yet (possibly including me not understanding how it should work), that didn't work on the first package I tried, but setting up pbuilder let me build the package I wanted.
It might feel like overkill to get a clean chroot as a build environment, but it is way too easy to build yourself problems that no one else in the world can replicate because you've got something funny on your local system.
Nowdays I'm just trying to build libsamperate from source using MSYS on Windows, but i meet a configure checking problem I've installed FFTW & libsndfile before, their include files lib files and pkg-config files are all in the right place, but when I use sh ./configure to generate makefile for libsamprate the output always mentions
checking for pkg-config... no
checking for SNDFILE... no
I also set the PKG_CONFIG_PATH(usr/local/lib/pkgconfig) and tried many times but the result seems the same
Does anyone knows anything about this?
As mentioned in comments, your environment is not set up to run the pkg-config executable. There are many problems associated with pkg-config, and it has become increasingly popular to suggest that the correct solution is to stop using it completely. Unfortunately, if you are trying to install a package that does use pkg-config, you are not in a position to use that solution. The closest you can get is to set PKG_CONFIG to 'true' or ':' in your environment. This causes pkg-config to emit no output but always return true when it is run, so you need to specify locations of libraries and headers via the standard mechanisms (LDFLAGS, etc.).
pkg-config is great in that it allows a user (someone installing the package) to be ignorant of the standard flags. The problem with pkg-config is that it allows the users to be ignorant.
As a package maintainer, you should stop using pkg-config. As a user, you should either set PKG_CONFIG=: in your environment or in a config.site, or get in the habit of invoking configure with PKG_CONFIG=: as an argument. (If you are using packages that rely on ancient autoconf in which you cannot pass such flags as an argument, I'm not sure what the appropriate action is, but suggesting that the package maintainer upgrade is probably not a bad idea.)