[Top][All Lists]
[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