I am making a configure.ac file for a tool i made and i need to check whether pdflatex is installed in the users system. How do i do it ? For checking for other libraries i simply included the test programs using AC_COMPILE_IFELSE, but i dont know if pdflatex can be invoked from the program.
Also is it regular practise to install all the required packages automatically using some script or i can just specify in the readme file which packages are required and then its upto user to install those packages.
You can use AC_CHECK_PROG([have_pdflatex], [pdflatex], [yes], [no]) to simply check if it exists and set have_pdflatex to yes if so. It's more likely that you'll want to use AC_PATH_PROG([PDFLATEX], [pdflatex]) to find the actual path of the program if it exists and store it in PDFLATEX.
I think it's best to let the user install the prerequisites themself. You don't know how they install their software (apt? yum? pacman? emerge? source?) and it wouldn't be worth the effort to try to cover all cases. It's sufficient to just mention them in the README and to test for them with Autoconf macros.
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.
Im trying to establish if it possible to create a deb package for the following app:
http://openfoam.org/download/4-0-source/
It uses an Allmake shell script which contains various standard shell commands and wmake commands to compile the source. wmake appears to be specific to this application but does call make:
http://www.cfdsupport.com/OpenFOAM-Training-by-CFD-Support/node25.html
https://github.com/OpenFOAM/OpenFOAM-2.1.x/blob/master/wmake/wmake
Is it possible to call the shell script from within a debian/rules file? or is there a better way of doing this if it is indeed possible?
Any assistance is much appreciated.
Indeed, the general idea of the debian/rules file is to run whatever commands are required to configure and install the upstream package into a location suitable for the dpkg toolchain.
Modern debhelper-based debian/rules files are typically extremely terse, because most typical packages adhere to build conventions for which good, very simple canned helpers are available, but traditional, more complex and explicit rules files are well-documented in older Debian packaging documentation.
Basically, the debian/rules file is a Makefile; it should have a binary target with the commands to build the upstream package into the Debian package root.
https://www.debian.org/doc/manuals/maint-guide/dreq.en.html#rules is probably useful as a starting point - unless your needs are really arcane, the dh defaults will mostly make sense, and it allows you to easily override the parts which don't.
Should configure check for programs used to install files (such as unzip for example), or is that the job of the Makefile? The same applies for directory existence - should configure check that a user-defined directory actually exists (for example, to enable a certain feature of the program which needs to install files into a different location)? Both of these are install-time checks, but automake doesn't seem to have any capabilities to do this, only autoconf.
It's configures job to do system discovery tasks. If you need unzip for a customized install step, configure should discover it or be directed to it (e.g. via AC_ARG_VAR).
Enabling features is IMO better handled by AC_ARG_WITH or AC_ARG_ENABLE, because you can always create the directory as part of make install. But if you'd rather check for the existence of the directory, configure is the place to do it.
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 figure out how to have automake change the file permissions on a newly generated executable automatically. Essentially, I want it to perform a 'chmod' every time it creates the executable, but I can't find anything that allows me to specify arbitrary shell commands after compilation. Any suggestions?
Thanks a lot,
Kyle
If you use the standard variables such as bin_PROGRAMS and bin_SCRIPTS, the installed files should be made executable automatically. For other uses you could use a hook target such as install-exec-hook or install-data-hook. This is described in the documentation and in the autobook.