automake
[Top][All Lists]
Advanced

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

Re: Portable moc/uic support - works for me


From: Alexandre Duret-Lutz
Subject: Re: Portable moc/uic support - works for me
Date: Fri, 03 Feb 2006 08:01:45 +0100
User-agent: Gnus/5.110003 (No Gnus v0.3) Emacs/22.0.50 (gnu/linux)

>>> "PR" == Pavel Roskin <address@hidden> writes:

 PR> bin_PROGRAMS = foo
 PR> DISTSOURCES = foo.cpp
 PR> DISTHEADERS_MOC = bar.h
 PR> DISTHEADERS_NO_MOC = baz.h
 PR> FORMS = quux.ui

 PR> FORMHEADERS = $(FORMS:.ui=.h)
 PR> MOC_CC = $(FORMS:.ui=.moc.cc) $(DISTHEADERS_MOC:.h=.moc.cc)
 PR> UIC_CC = $(FORMS:.ui=.uic.cc)

 PR> BUILT_SOURCES = $(FORMHEADERS) $(UIC_CC) $(MOC_CC)
 PR> CLEANFILES = $(BUILT_SOURCES)
 PR> EXTRA_DIST = $(FORMS)

 PR> foo_SOURCES = $(DISTSOURCES) $(DISTHEADERS_MOC) $(DISTHEADERS_NO_MOC)
 PR> nodist_foo_SOURCES = $(MOC_CC) $(UIC_CC)

 PR> .ui.h:
 PR> $(QT_UIC) -o $@ $<

 PR> .h.moc.cc:
 PR> $(QT_MOC) -o $@ $<

 PR> .h.uic.cc:
 PR> $(QT_UIC) -o $@ -impl $< $(srcdir)/$(<:.h=.ui)

 PR> SUFFIXES = .h .ui .moc.cc .uic.cc

[...]

 PR> - How portable are double extensions? (I'm more concerned about UNIX
 PR> make issues than about MS DOS)

I'm not aware of any problem with them.  In fact I wouldn't even
call these "double extensions".  They are indeed extensions with
two dots, but you could also have extensions without any dots if
you want.  So if the double dot is a problem for some
filesystem, you could remove the first one.

 PR> - How portable is $(<:.h=.ui) in the suffix rules?

I think this should work.  Automake uses things like $(@:.info=)
in some of its rule already.

But why not rename this rule ".ui.uic.cc:" and use "$<"?

 PR> - How safe are substitution references like $(FORMS:.ui=.h) in Automake
 PR> variables?  Does Automake calculate them (I guess it does, but keeps the
 PR> original line in Makefile.in)?

It's expected to work.  Automake indeed performs such
substitutions when it iterates over the contents of a variable.


Unlike GNU Make, some Make implementations (e.g. Sun's) do not
know how to chain implicit rules.  So if such a make wants to
build quux.moc.cc and quux.h doesn't exist, it will not think
about building this missing file with another implicit rule.
Maybe your declaration of BUILT_SOURCES avoids such problems,
but anyway I think it would be safer to write implicit rules
that depend on existing files (*.ui) rather than built files
(*.h) when possible.
-- 
Alexandre Duret-Lutz

Shared books are happy books.     http://www.bookcrossing.com/friend/gadl





reply via email to

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