I have downloaded a macro from Autoconf Archive, and I want to use it. What do I have to put in my configure.ac file to make use this macro?
You may want to add AC_CONFIG_MACRO_DIR to configure.ac to the directory where the macro is:
AC_CONFIG_MACRO_DIR([path/to/macros])
You'll need to invoke the macro somewhere in this file also.
and in Makefile.am you'll probably need to set up ACLOCAL_AMFLAGS (if you are using automake):
ACLOCAL_AMFLAGS = -I path/to/macros
Then invoke autoreconf -fvi and you should be set.
I had this exact same question, and it was harder to find an answer than I thought. It looked like AC_CONFIG_MACRO_DIR was what I wanted, but if you are not using libtoolize, it appears that AC_CONFIG_MACRO_DIR is useless at present.
If you're using automake, I think the answer above is right.
I'm not using automake, so the only way I've found is to use the m4_include macro to suck in each .m4 file individually. I found this approach here:
http://www.flameeyes.eu/autotools-mythbuster/autoconf/macros.html
Hope this helps. (Considering how long autoconf has been around, it boggles my mind somewhat that there's no built-in way to just specify a directory in the .ac file. Seems like it would be an awefully common use case. Oh, well.)
As an alternative to Idav1s' solution (which is absolutely correct), you can install the macro in a location where aclocal will find it (use aclocal --print to see where aclocal is looking for .m4 files). Each approach has pros and cons. If you install the .m4 files in $(aclocal --print), you can use the macro in all of your projects without doing anything else. The primary drawback is that each developer who works on the project will have to install the macro on their box, and that requires each developer to have a reasonable understanding of the autotools.
I have this issue as well, and just fixed it. My environment is: CentOS 6.4, M4 1.4.17 , autoconf 2.69, libtool 2.4, automake 1.14
Here are the steps I used.
add m4 as AC_CONFIG_MACRO_DIR to your configure.ac
rm aclocal.m4 if it exists
mkdir m4 if it does not exist
# copy some dummy files into the folder
# or some versions of autoconf won't work
autoreconf -i --install
Isn't it enough to just save the m4 macro in certain directory and run autoreconf with the -I option:
autoreconf -i -I/path/to/your/m4/file
Or did I misunderstand you and do you want to integrate it permanently, without the person running autoreconf to worry about downloading the m4 file?
Related
I've created packages previously by using a Makefile, the command "dh_make --createorig", then adjusting files in the debian folder generated and finally using the debuild command to generate the .deb. That workflow is simple and works for me, but I was told to adjust it a little in a way that you could build the project from the sources without requiring the orig files and I'm unsure how to do it, but according to this (https://askubuntu.com/questions/17508/how-to-have-debian-packaging-generate-two-packages-given-an-upstream-source-arch) and this structure (http://bazaar.launchpad.net/~andrewsomething/imagination/debian/files) there must be a way. In my case I would have a folder with the sources and all of that and then a debian folder (generated with dh_make) but I'm unsure on how to avoid the debuild command to ask for the .orig files or if I should be using some other command for this.
Sorry for the superlong question, I think I provided all the relevant information, but I can clarify if anything is fuzzy.
The difference is in the version number in the file debian/changelog.
If you use 1.2.3-1 it implied Debian build 1 of an upstream package 1.2.3 --- for which the build programs (dpkg-buildpackage and whichever wrappers on top) --- assume an .orig.tar.gz to exists.
But if you use 1.2.3 it will consider the package 'Debian native' and the archive is just a .tar.gz and not an .orig.tar.gz.
Now the choice should not be driven by your convenience alone. If this has an upstream source, use the first scheme. If not, the second can be fine. In the packages I maintain I have both but way more of the former.
If you want to create a Debian directory directly in the source package (ie you're packaging your own work, rather than from an upstream release) you could use the --native option to dh_make
I think the question was asked differently, it was somewhat clear that the project was upstream and it's probably not a good reason to change its format to native.
Currently I package some upstream python project, this exact same question came to my mind. Why isn't there any dh_* hook to overwrite in order to generate this origin tarball on the fly so you do not get bothered by:
This package has a Debian revision number but there does not seem to be
an appropriate original tar file or .orig directory in the parent directory;
for a start, I added a makefile to the project:
# Makefile
VERSION:=$(shell dpkg-parsechangelog -S Version | sed -rne 's,([^-\+]+)+(\+dfsg)*.*,\1,p'i)
UPSTREAM_PACKAGE:=click_${VERSION}.orig.tar.gz
dpkg:
tar cafv ../${UPSTREAM_PACKAGE} . --exclude debian --exclude .git
debuild -uc -us
clean:
rm -f ../${UPSTREAM_PACKAGE}
debuild clean
so a simple make clean dpkg was all it needed to build the package.
Now I think the question remains if someone has some bright idea how to insert the tar operation within the debian/rules so I could just call debuild -uc -us and it magically creates the orig tarball I would be awsome :)
Created a simple debian/ubuntu package with some library files (*.so).
Works fine except, it installs them as default in the root path "/".
Since I've recreated my Makefile to output to $DESTDIR/ instead of "the usual" directory that I provide in the Makefile, when compiling from source, how do I now set the path of where the files should be installed now? I know there are several choices when using dh_make to create the package, "s" being the default one. Still, can't seem to find anything on where to tell dpkg to put the installed files.
Secondly, a Deb Library package containing only ".so" files should still be a "Single binary" since I gather that using the Library is for development purposes? Since this is a library, I just wanna make sure that's not the cause of the files being installed in the wrong location. What I mean is .so files and header files installation?
What I've used:
dh_make -e my#email.com -f ../myfile-1.0.tar.gz
dpkg-buildpackage -rfakeroot
and some configurations set i debian/control, $DESTDIR in Makefile.
Seems that it was fairly simple, yet very confusing. This works, not sure if there is a better solution.
In my makefile I have a few variables
InstallTo = /usr/lib
install:
mkdir -p $(DESTDIR)$(InstallTo)
cp $FILE_TO_COPY $(DESTDIR)$(InstallTo)
This way it will create the directory tree inside the *.deb file. I had some trouble using /usr/local/lib instead of /usr/lib/ and rmdir complained when trying to delete it and it had no files (just directories). Not sure why, but changed it to /usr/lib instead.
Since someone voted this up, I'm guessing someone were also looking for the answer and this is my solution. Perhaps someone can provide a better one if there is one.
Just a note, $DESTDIR variable is the variable that dh_make suggest the user to use in our Makefile. It's the path to where dpkg will build the program and where it will install it so it can be included in the .deb file.
I have a debian package that I built that contains a tar ball of the files, a control file, and a postinst file. Its built using dpkg-deb and it installs properly using dpkg.
The modification I would like to make is to have the installation directory of the files be determined at runtime based on an environment variable that will be set when dpkg -i is run on the deb file. I echo out the environment variable in the postinst script and I can see that its set properly.
My questions:
1) Is it possible to dynamically determine the installation directory at runtime?
2) If its possible how would I go about this? I have read about the rules file and the mypackage.install files but I don't know if either of these would allow me to accomplish this.
I could hack it by copying the files to the target location in the posinst script but I would prefer to do it the right way if possible.
Thanks in advance!
So this is what I found out about this problem over the past couple of weeks.
With prepackaged binaries you can't build a debian package with a destination directory dynamicall determined at runtime. I believe that this might be possible if installing a package that is built from source where you can set the install directory using configure. But in this case since these are embedded Ubuntu machines they don't have make so I didn't pursue such an option. I did work out a non traditional method (hack) for installing that did work. Since debian packages simply contain a tar ball relative to / simply build your package relative to a directory under /tmp. In the postinst script you can then determine where to copy the files from the archive into a permanent location.
I expected that after rebooting and the automatic deletion of the subdirectory under /tmp that dpkg might not know that the file package existed. This wasn't a problem. When I ran 'dpkg -l myapp' it showed as still installed. Updating the package using dpkg/apt-get also worked without a hitch.
What I did find is that if you attempted to remove the package using 'dpkg -r myapp' that dpkg would try and remove /tmp which wasn't good. However /tmp isn't easily removed so it never succeeded. Plus in our situation we never remove packages but instead simply upgrade them.
I eventually had to abandon the universal package due to code differences in the sources resulting in having to recompile per platform but I would have left it this way and it did work.
I tried using --instdir to change the install directory of the package and it does relocate the files but dpkg fails since the dpkg file can't be found relative to the new instdir. Using --instdir is sort of like a chroot. I also tried --admindir and --root in various combinations to see if I could use the dpkg system relative to / but install relocate the files but they didn't work. I guess rpm has a relocate option that works but not Ubuntu.
You can also write a script that runs dpkg-deb with a different environment for 6 times, generating 6 different packages. When you make a modification, you simply have to run your script, and all 6 packages gets generated and you can install them on your machines avoiding postinst hacking!
Why not install to a standard location, and simply use a postinst script to create symbolic links to the desired location? This is much cleaner, and shouldn't break anything in dpk -I.
I want to run 'make install' so I have everything I need, but I'd like it to install the things in their own folder as opposed to the system's /usr/bin etc. is that possible? even if it references tools in the /usr/bin etc.?
It depends on the package. If the Makefile is generated by GNU autotools (./configure) you can usually set the target location like so:
./configure --prefix=/somewhere/else/than/usr/local
If the Makefile is not generated by autotools, but distributed along with the software, simply open it up in an editor and change it. The install target directory is probably defined in a variable somewhere.
Since don't know which version of automake you can use DESTDIR environment variable.
See Makefile to be sure.
For example:
export DESTDIR="$HOME/Software/LocalInstall" && make -j4 install
make DESTDIR=./new/customized/path install
This quick command worked for me for opencv release 3.2.0 installation on Ubuntu 16. DESTDIR path can be relative as well as absolute.
Such redirection can also be useful in case user does not have admin privileges as long as DESTDIR location has right access for the user. e.g /home//
It could be dependent upon what is supported by the module you are trying to compile. If your makefile is generated by using autotools, use:
--prefix=<myinstalldir>
when running the ./configure
some packages allow you to also override when running:
make prefix=<myinstalldir>
however, if your not using ./configure, only way to know for sure is to open up the makefile and check. It should be one of the first few variables at the top.
If the package provides a Makefile.PL - one can use:
perl Makefile.PL PREFIX=/home/my/local/lib LIB=/home/my/local/lib
make
make test
make install
* further explanation: https://www.perlmonks.org/?node_id=564720
I tried the above solutions. None worked.
In the end I opened Makefile file and manually changed prefix path to desired installation path like below.
PREFIX ?= "installation path"
When I tried --prefix, "make" complained that there is not such command input. However, perhaps some packages accepts --prefix which is of course a cleaner solution.
try using INSTALL_ROOT.
make install INSTALL_ROOT=$INSTALL_DIRECTORY
I've stumbled on a make file "Makefile.am" and I tried to use "make -f Makefile.am" on it to no avail. What am I doing wrong?
It's an automake script/makefile. You can learn everything about automake, autoconf, libtool and such through the called autobook.
Basically, the steps would be to run automake, then autoconf, then configure, then make to build the software you have. These steps are neccessary to build the configure script, that automatically search for needed libraries and such on your system.
The process is not easy, unless your software also includes an already generated "configure" file. If so, the only thing you have to do (mostly) is to just run ./configure, then make, then make install to install the software to a default location. If you want to change configure options, you can also look at ./configure --help.
You stumbled upon an automake file, which is used to create a Makefile from the source, in this case Makefile.am.
From http://developer.gnome.org/doc/GGAD/z70.html, they explain it as:
automake processes Makefile.am to produce a standards-compliant Makefile.in. automake does a lot of work for you: it keeps up with dependencies between source files, for example. It creates all the standard targets, such as install and clean. It also creates more complex targets: simply typing make dist creates a standard .tar.gz file if your Makefile.am is correct.
Basically, you should run 'automake' to make the Makefile, and you will probably run into the same situation with the configure script with 'autoconf'.
Automake: http://www.gnu.org/software/automake/
Wikipedia article on automake: http://en.wikipedia.org/wiki/Automake
If you are trying to compile a 3rd party application from source, there is usually a 'configure' script located at the top of the source tree. If you run ./configure --help from that location, you'll get a list of options you can set. Usually, --prefix is the most common to use.
After running the script, you'll get standard Makefile's generated from the automake files. From there, you can just execute make normally.
Standard build steps for linux packages are:
./configure
make
make install
see "man automake" or google for autotools. likely you'll want to run something like autogen.sh first.