On 08/13/2012 08:59 PM, Slávek Banko wrote: Sorry Slavek. What I did to create the patch was to look at http://trinity-devel.pearsoncomputing.net/?0::6608 tqt-interface in 3513-sru need exactly what I hand in the attached diff to the original message: qt-watch.moc3: qt-watch.cpp - $(AM_V_GEN)$(MOC_QT3) moc $^ $@ + $(AM_V_GEN)$(MOC_QT3) $^ -o $@ There should be _no_ tqmoc change. If I overlooked that in the commit 8f7a6ec9f95f then we can NOT use that commit. We may need a new one. Removing the 'moc' is fine as the makefile magic takes care of that. Without this patch, avahi-tqt will not build. Let me know if that makes sense. -- David C. Rankin, J.D.,P.E.

On 08/22/2012 10:03 AM, Slávek Banko wrote: OK, I will look into this further tonight. All I can say is that without it, I get a FTBFS. As I noted originally, I found the solution here: http://trinity-devel.pearsoncomputing.net/?0::6608 The gnu make expansion rule is explained here: http://www.gnu.org/software/make/manual/make.html Specifically: 4.5.4 Writing Recipes with Directory Search When a prerequisite is found in another directory through directory search, this cannot change the recipe of the rule; they will execute as written. Therefore, you must write the recipe with care so that it will look for the prerequisite in the directory where make finds it. For instance, the value of ‘$^’ is a list of all the prerequisites of the rule, *including the names of the directories* in which they were found, and the value of ‘$@’ is the target. Thus: foo.o : foo.c cc -c $(CFLAGS) $^ -o $@ The explanation of Automatic Variables is here: http://www.gnu.org/software/make/manual/make.html#Automatic-Variables 10.5.3 Automatic Variables $^ The names of all the prerequisites, with spaces between them. For prerequisites which are archive members, only the named member is used (see Archives). A target has only one prerequisite on each other file it depends on, no matter how many times each file is listed as a prerequisite. So if you list a prerequisite more than once for a target, the value of $^ contains just one copy of the name. As with the other person who originally posted http://trinity-devel.pearsoncomputing.net/?0::6608, the change is apparently necessary so that correct *directory* information is provided for the build. You must be exporting some path somewhere in your build such that telling make to use the correct directory information with '$^' results in double-path information in your build. I don't know. It is either broken on your end or on my end. I'm not using any exports to build, just the code from GIT. Building just from GIT without altering the environment requires the patch I submitted. I still don't completely understand why I need it and you don't other than what I explained above being the only logical guess I have. We need one of the makefile wizards on the list to take a look. -- David C. Rankin, J.D.,P.E.

On Friday 24 of August 2012 17:20:08 David C. Rankin wrote: The code that is in the GIT expects, that MOC_QT3 directs to moc-tqt. In this case is: $(MOC_QT3) moc $^ -o $@ expanded to: moc-tqt moc _input_file_ -o _output_file_ In your build environment probably MOC_QT3 directs to moc-qt3 == is expanded to: moc-qt3 moc _input_file_ -o _output_file_ And this leads to FTBFS for you. Therefore your patch which remove "moc" solves problem in your build environment. But for others is expanded to: moc-tqt _input_file_ -o _output_file_ And this leads to FTBFS for others. My patch tries to change your build environment == to set MOC_QT3 to moc-tqt instead of moc-qt3. Slavek --