Re: building a qt library

[Craig Sanders]

Hello Ralf.

Thank you for your constructive feedback on how to write more robust 
configure.ac and Makefile.am files. I was aware of some of your suggestions 
(i.e. the calling of both the AC_INIT and AM_INIT_AUTOMAKE macros) but 
unfortunately had neglected to implement them in the particular files that I 
quoted in my original e-mail. Whereas some of your other suggestions were new 
to me and I will definately have to start incorporating them into my 
configure.ac and Makefile.am files in the future. 

To be honest, I also thought that there might have been a more elegant way in 
which to implement the custom rule for invoking the Qt Meta Object Compiler 
(moc) on the C++ source code files. That is, the rule which I have quoted below.

  .hpp.cpp:
      @echo ""
      @echo "----------------------------------------"
      @echo "moc is creating the file : address@hidden"
      @echo "... in directory         : address@hidden/"
      @echo "... from input file      : $< "
      @echo "$<"
      @echo ""
      ${QT_MOC} -o address@hidden $<

You couldn't recommend a more elegant way in which to accomplish this task 
could you?

Thanks once again for all of your feedback - it is most appreciated.

Have a great day.


- Craig

Ralf Wildenhues <address@hidden> wrote:
> 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],
>>         address@hidden,
>>         [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 : address@hidden"
>>      @echo "... in directory         : address@hidden/"
>>      @echo "... from input file      : $< "
>>      @echo "$<"
>>      @echo ""
>>      ${QT_MOC} -o address@hidden $<