The simplest answer; within the top level source directory Makefile.am:
# Install my_script in $(bindir) and distribute it.
dist_bin_SCRIPTS = my_script
So, $(bindir) is the default for scripts.
--
For a more robust implementation that actually covers init scripts for daemons/services (first quoting the authoritative source):
There is no need for EXTRA_DIST or any build rule: Automake infers them from AC_CONFIG_FILES (see Requirements). CLEANFILES is still useful, because by default Automake will clean targets of AC_CONFIG_FILES in distclean, not clean.
Link to source (http://www.gnu.org/software/automake/manual/html_node/Scripts.html):
Examples:
Install to a custom location:
# Yes, even though its `init_d_SCRIPTS`, we use `init_ddir`,
# with-out a second underscore.
init_ddir = $(sysconfdir)/rc.d/init.d
init_d_SCRIPTS = <yourscript>
# CLEANFILES = $(init_d_SCRIPTS)
Please note that $(sysconfdir) represents $(prefix)/etc; the base path to init.d or rc.d/init.d, and you can/should(?) un-comment the CLEANFILES line in either example if your init script is generated by Autotools.
Or install to the default location:
bin_SCRIPTS = <yourscript>
# CLEANFILES = $(bin_SCRIPTS)
Which will be $(bindir)
EDIT:
Both examples above assume you are having Autotools generate the init_d_SCRIPTS files, but what if we want to distribute an already created script instead and have that installed into our $(init_ddir) location?
init_ddir = $(sysconfdir)/init.d
dist_init_d_SCRIPTS = <yourscript>
The trick is that dist does not need to be followed by _bin_SCRIPTS, it can be dist_<your_var>_SCRIPTS. The primary SCRIPTS lets Autotools know the value is a script and how to handle it, while the keyword dist in the front alerts Automake to the fact that it is not going to be creating a file for us - and instructs Automake not to look for a makefile template in the script source directory.
I wanted to add this little edit since I just had to make the correction myself for a script I'm distributing with my source.
--
Extra
For those who will next worry about their init script with regard to packaging (specifically Debian packaging) - which makes this a reminder for myself more or less -> look here:
https://www.debian.org/doc/manuals/maint-guide/dother.en.html#initd
The error(s) I was getting included debuild trying to install the init.d file and conf file directly in /etc and /etc/init.d in the root of my filesystem, rather than in debian/<package>/<location> like it's supposed to during a package build.
I found that ultimately I had to remove an added rule that was provided in the Packaging Tutorial(s) for Debian where they have you override dh_auto_install. Specifically this bit in debian/rules:
#!/usr/bin/make -f
%:
dh $@
# If installing an upstream init.d script:
override_dh_installinit:
dh_installinit --name=<scriptname> --onlyscripts
# Remove the following:
# override_dh_auto_install:
# $(MAKE) DESTDIR=$$(pwd)/debian/<package> prefix=/usr install
After removing that rule (which wasn't necessary to remove until after adding my init.d script and conf file) everything generated and compiled absolutely perfectly....Including - in fact - dropping the bins into their destination using /usr prefix as was the desired effect of the override in the first place.
The override to the dh_installinit call tells debuild not to install the init script as the makefile will, and specifies to only make update-rc.d calls to register the script with the system. I chose to name the script different from the package; and so I was required to pass the --name= option.
Hope that helps someone, I know it'll help me in the future if this answer is allowed to remain in existence.
