Hello Craig,
a couple of comments to the configure.ac script and Makefile.am file you
posted:
* Craig Sanders wrote on Fri, Nov 28, 2008 at 01:58:56AM CET:
>
> AC_INIT(
> [simple_signal_emitter_autotools],
> [0.0.1],
> [EMAIL PROTECTED],
> [simple_signal_emitter_autotools])
>
> # Inform aclocal and friends of where they can find additional
> # local Autoconf macros.
>
> m4_include([./m4/bnv_have_qt.m4])
While this line is completely OK as it is, I would prefer doing it
differently:
- Generally, do not use `./' prefixes to files unless there is a
specific reason to do so. Why is that a good idea? By this
inclusion, the file m4/bnv_have_qt.m4 becomes a prerequisite of
the configure script, and automake will be smart enough to notice
this dependency and add the file to the configure regeneration
rule in Makefile.in. Now, however, most non-GNU make implementations
do not identify `./FILE' with `FILE' in target or prerequisiste
names. So, in the hypothetical case that, for example, you have
a rule to generate `m4/bnv_have_qt.m4', then it would not be
updated before configure were out of date. Omitting `./'
would prevent this issue.
Of course this is not likely to have an effect in this case,
but it's a good rule to obey for portable makefiles.
- For third-party m4 files that provide extra macros, a good convention
to use is to let aclocal find them automatically, and maybe even
install updated versions into your package automatically. The former
can be achieved by
-- adding `ACLOCAL_AMFLAGS = -I m4' to the toplevel Makefile.am;
autoreconf will then pick this up when running aclocal; if you
invoke it manually, you should add these flags as first options.
The latter can be achieved with additionally
-- adding AC_CONFIG_MACRO_DIR([m4]) to configure.ac,
-- and then using `aclocal --install' (this requires Automake 1.10
or newer)
You can then just omit the m4_include line completely from
configure.ac, and notice that aclocal will put such a line into
aclocal.m4.
> AC_CONFIG_AUX_DIR(config)
>
> AM_INIT_AUTOMAKE(
> [simple_signal_emitter_autotools],
> [0.1])
This format is the old-style invocation of AM_INIT_AUTOMAKE.
You don't need it: you are already using the new-style AC_INIT
which provides package name and version number. Moreover, you
are using inconsistent version numbers in both. Solution is
to use plain `AM_INIT_AUTOMAKE' without further arguments here.
You can then decide to add Options in the first argument if you
like.
> AC_CONFIG_SRCDIR(
> [./src/main.cpp])
Again, I'd omit the `./'
> AC_PROG_CC
>
> AC_PROG_LIBTOOL
>
> AC_PROG_CXX(
> [${CXX}])
Why this argument? Plain AC_PROG_CXX should be equivalent in semantics
(a default list of compiler names is tried unless $CXX is set).
> AC_PROG_LIBTOOL
>
> BNV_HAVE_QT()
>
> AC_OUTPUT([
> Makefile
> ])
[ Makefile.am: ]
> bin_PROGRAMS = main
>
> main_MOC_FILES = ./moc_MySignalEmitter.cpp
Again, please omit leading `./'; several more instances.
> main_SOURCES = ./src/main.cpp \
> ./src/MySignalEmitter.cpp \
> ${main_MOC_FILES}
>
> main_CXXFLAGS = ${QT_CXXFLAGS} -I${srcdir}/include
>
> main_LDFLAGS = ${QT_LIBS}
>
>
> CLEANFILES = ${main_MOC_FILES}
>
> # Inform make of how to handle C++ Header files (.hpp) that need
> # to be processed by the Qt Meta Object Compiler (moc).
>
> .hpp.cpp:
> @echo ""
> @echo "----------------------------------------"
> @echo "moc is creating the file : [EMAIL PROTECTED]"
> @echo "... in directory : [EMAIL PROTECTED]/"
> @echo "... from input file : $< "
> @echo "$<"
> @echo ""
> ${QT_MOC} -o [EMAIL PROTECTED] $<
