automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Main prog is configure-generated?


From: Micah J. Cowan
Subject: Main prog is configure-generated?
Date: Thu, 13 Jul 2006 13:17:37 -0700
User-agent: Mutt/1.2.5.1i

1) What is an appropriate setup when the primary "binary" file is generated
from the configure script?

2) What is an appropriate setup when the primary "binary" program file
is ready-to-go already (say, a shell script or somesuch)?

A project I'm working on initially started out as scenario (2) above
(awk script), but since I decided to have configure automatically detect
the appropriate location of awk, for inclusion into the shebang line, it
is now generated from configure (scenario (1)).

I wanted to set it up to install automatically. However, simply listing
it in bin_PROGRAMS is wrong: it assumes it should build it from
checkmk.c (the program name is checkmk). Additionally specifying
checkmk_SOURCES as empty is wrong too, as it results in overriding
appropriate make rules that are automatically generated because it is
generated by configure from checkmk.in.

My current workaround is to add it to EXTRA_DIST and use:

    $(DESTDIR)$(bindir): mkdir -p $@

    install-exec-local: $(DESTDIR)$(bindir) $(INSTALL_PROGRAM_ENV)
    $(INSTALL_PROGRAM) checkmk "$(DESTDIR)$(bindir)/checkmk"

    uninstall-local: rm -f "$(DESTDIR)$(bindir)/checkmk"

This feels wrong for a variety of reasons. For one thing, I had to build
my own $(DESTDIR)$(bindir) rule, since automake couldn't figure out that
it was needed. Just copying the rule over reminded me that I needed to
change "mkdir -p $@" to "mkdir -p -- $@": if the standard way of
building directories should change in the future (perhaps it will be
decided to muck with umask? or take advantage of possible GNU features
of mkdir, when available?), it'll be inconsistent with the automatic
rules once again.

I had almost forgotten to write an uninstall rule above, which would've
been written automatically. distcheck doesn't catch its absence, because
it only requires that the distuninstallcheck_listfiles return less than
or equal to 1 (why does it accept 1?!?).

I suspect there may be other problems of which I am not aware.

Is there a better way to handle this sort of thing? Is there a way to
tell automake not to try to add extra build rules, but install it as a
bin_PROGRAM?

-- 
TIA,

Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]