I have a configure script that writes a Makefile (from Makefile.in). The clean target currently removes everything created from within the makefile, but it doesn't delete the makefile itself. (I'm not using Autotools as you can probably tell)
My question therefore: Should the makefile also remove itself, requiring the developer to run ./configure again?
On the one hand, I want the clean target to properly clean up the source tree. But, on the other hand, I'd like to be able to type make clean test to check that everything's working as it should before committing; Running the configure script again seems weird somehow.
This is a stylistic question, rather than a technical question. The best place to go for answers is the automake manual, which will tell you:
`make clean'
Erase from the build tree the files built by `make all'.
`make distclean'
Additionally erase anything `./configure' created.
So, no, make clean should not delete Makefile. make distclean should delete Makefile, since it's created by configure not make all.
One of the best things about autotools is that they are consistent and standard. It's best to not irritate your users by flouting those standards.
I'd probably have a separate target for that. So clean would leave them able to build again but distclean or realclean or allclean or something would force a reconfigure. You could see which autotools clean target (if any) has similar behaviour.
The purpose of the clean target is usually to remove interim files, so you can start your compile from scratch. See more here For instance, a common makefile target is "clean," which generally performs actions that clean up after the compiler--removing object files and the resulting executable.
Related
I have makefile all: clean $(binary_output_path)/$(target_executable) which cleans output directory first and the build executable. The problem is when I want to use -j10: sometimes it start building and cleaning at the same time, so build fails, obviously.
How can I overcome this and have targets executed in order but on multiple cores?
You should add the dependency:
$(binary_output_path)/$(target_executable): | clean
However, this is not a good idea to use clean like that at all. Just have
all: $(binary_output_path)/$(target_executable)
$(binary_output_path)/$(target_executable): prerequisites
write your recipe here that builds this target
You should focus on writing makefiles in such a way that cleaning is not needed. If you must clean first before building your executable, find out why that is so, and write your commands that build the executable, in such a way that they work regardless of whether you have "cleaned" or not.
".MAKE" appears in gnu Makefile for a number of packages which use AutoMake, but appears to be undocumented as a "special" target in the online manual. Anyone know what it does?
This target doesn't do anything by itself. It has no special meaning to a make I know.
However, it is automatically generated when a project uses GNU Automake.
Automake creates the Makefile.in files, which ./configure will use to generate Makefiles.
It isn't listed among the targets in the documentation: only developers will need it, as its definition in a generated Makefile.in shows:
.MAKE: $(RECURSIVE_CLEAN_TARGETS) $(RECURSIVE_TARGETS) all check-am \
ctags-recursive install-am install-strip tags-recursive
The two variables are defined elsewhere in Makefile.in, and it appears that this target will attempt to do a full runthrough of everything that can be done at all: cleaning up the source tree, compiling the software, running automatic tests, installing it, uninstalling it, and a few steps that are only useful for developers. So this is basically a one-shot test run that might for instance be used during continuous build tests.
This is a clear example of why automake was created: a much-desired feature is missing from make (namely the ability to tell it to "do everything"), so automake provides it.
The chosen answer is inaccurate. The .MAKE target is not meant to be executed by anyone. It doesn't mean anything special to GNU make, however the make in, for example, FreeBSD, understands the prerequisites of .MAKE to be recursive make invocations. In particular, the recipes associated with them will be executed even when doing make -n (dry-run invocation) so that you can see what commands would be executed by the recursive makes. GNU make detects recursive make recipes by the presence of a reference to $(MAKE), or by the '+' token. So it's inserted by automake for compatibility purposes.
I have started recently to work with automake and autoconf and I am a little confused about how to distribute the code.
Usually when I get a code that works with a configure file, the only thing that I get is a confiure file and the code itself with the Makefile.am and so on. Usually I do
./configure
make
sudo make install
and thats all but when I generate my configure from a configure.ac file it toss out lots of files that I thought where just temporary but if I give the code to a partner and he makes configure, it doesn't work, it needs either remake the autoreconf or have all this files (namely instal.sh,config.sub...).
Is there something that I am missing? How can I distribute the code easily and clean?
I have searched a lot but I think I am searching for the right thing because I cannot find anything useful.
Thanks a lot in advance!
Automake provides a make dist target. This automatically creates a .tar.gz from your project. This archive is set up in such a way that the recipient can simply extract it and run the usual ./configure && make && make install invocation.
It is generally not recommended to check the files generated by Autotools into your repository. This is because they are derived objects. You wouldn't check in your .o files!
Usually, it is a good idea to provide a autogen.sh script that carries out any actions required to re-create the Autotools build infrastructure in a new version control system checkout. Often, it can be as simple as:
#!/bin/sh
autoreconf -i
Then set it chmod +x, and the instructions for compiling from a clean checkout can be ./autogen.sh && ./configure && make.
I have an autotools project. In one of its directories, I would like to run a script, after the make process is done. In other words, I'd like to have an option to "phony" target that would be executed last. Alternatively, I could use a dedicated m4 Macro (I only I knew which one...).
Any ideas?
Thanks
I'm assuming that by "autotools", you're using Automake as well as Autoconf. I can see two ways of doing this.
You can make a -hook rule in your Makefile.am. However, this can only be done for certain default targets: install-data, install-exec, uninstall, dist and distcheck. So, to make a rule that will be run immediately after install-exec, call it install-exec-hook. Then just run the script in the recipe for that rule.
Based on the wording of your question, though, it seems that you want to run the script after building. If that's the case, you can customize the all target with an all-local target and then run the script in the recipe for this target. Note that, according to the Automake documentation,
With the '-local' targets, there is no particular guarantee of
execution order; typically, they are run early, but with parallel make,
there is no way to be sure of that.
However, since the all target is phony, it shouldn't run until everything is built. Nevertheless, if you can run the script after installation, I would recommend that way since the execution order is guaranteed.
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).