Slavek,
avahi-tqt for 3.5.13-sru just needs the qt-watch.moc3 fix backported, then it builds fine. The diff is attached. I can't find a commit in http://git.trinitydesktop.org/cgit/avahi-tqt/ that matches, so this just might need to be reviewed and signed off.
The reference for the fix is here:
http://trinity-devel.pearsoncomputing.net/?0::6608
On 08/08/2012 11:22 PM, David C. Rankin wrote:
Slavek,
avahi-tqt for 3.5.13-sru just needs the qt-watch.moc3 fix backported, then it builds fine. The diff is attached. I can't find a commit in http://git.trinitydesktop.org/cgit/avahi-tqt/ that matches, so this just might need to be reviewed and signed off.
The reference for the fix is here:
I found it, it was commit 8f7a6ec9f95f
OK to backport to 3.5.13-sru
On Thursday 09 of August 2012 07:38:29 David C. Rankin wrote:
On 08/08/2012 11:22 PM, David C. Rankin wrote:
Slavek,
avahi-tqt for 3.5.13-sru just needs the qt-watch.moc3 fix backported, then it builds fine. The diff is attached. I can't find a commit in http://git.trinitydesktop.org/cgit/avahi-tqt/ that matches, so this just might need to be reviewed and signed off.
The reference for the fix is here:
I found it, it was commit 8f7a6ec9f95f
OK to backport to 3.5.13-sru
David,
I'm a little confused. The original code is: $(AM_V_GEN)$(MOC_QT3) moc $^ $@
Your proposed patch changes it to: $(AM_V_GEN)$(MOC_QT3) $^ $@
While commit 8f7a6ec9 changes the moc to tqmoc: $(AM_V_GEN)$(MOC_QT3) tqmoc $^ $@
Removing moc seems to me suspicious. Similarly, the replacement from moc to tqmoc makes me uncertainty.
Please have some more information?
Slavek --
On 08/13/2012 08:59 PM, Slávek Banko wrote:
On Thursday 09 of August 2012 07:38:29 David C. Rankin wrote:
On 08/08/2012 11:22 PM, David C. Rankin wrote:
Slavek,
avahi-tqt for 3.5.13-sru just needs the qt-watch.moc3 fix backported, then it builds fine. The diff is attached. I can't find a commit in http://git.trinitydesktop.org/cgit/avahi-tqt/ that matches, so this just might need to be reviewed and signed off.
The reference for the fix is here:
I found it, it was commit 8f7a6ec9f95f
OK to backport to 3.5.13-sru
David,
I'm a little confused. The original code is: $(AM_V_GEN)$(MOC_QT3) moc $^ $@
Your proposed patch changes it to: $(AM_V_GEN)$(MOC_QT3) $^ $@
While commit 8f7a6ec9 changes the moc to tqmoc: $(AM_V_GEN)$(MOC_QT3) tqmoc $^ $@
Removing moc seems to me suspicious. Similarly, the replacement from moc to tqmoc makes me uncertainty.
Please have some more information?
Slavek
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.
Dne út 14. srpna 2012 David C. Rankin napsal(a):
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,
I still have doubts about the patch. Reasons I got: 1) In the GIT never been such a form. 2) Other distributions not reported this problem. 3) The patch removes the command and leaves orphaned parameters. 4) When I tried to add it, on Debian/Ubuntu occurred FTBFS.
I can not help but still it shows me that the problem lies elsewhere. Specifically, in that instead of 'moc-tqt' is called directly 'moc'. Variable MOC_QT3 should be set to the 'moc-tqt'.
Please try this patch instead of your proposed. This is a reduced "essence" of patches 594a27c9, 18173187 and 7b10d93d.
Slavek
On 08/22/2012 10:03 AM, Slávek Banko wrote:
David,
I still have doubts about the patch. Reasons I got:
- In the GIT never been such a form.
- Other distributions not reported this problem.
- The patch removes the command and leaves orphaned parameters.
- When I tried to add it, on Debian/Ubuntu occurred FTBFS.
I can not help but still it shows me that the problem lies elsewhere. Specifically, in that instead of 'moc-tqt' is called directly 'moc'. Variable MOC_QT3 should be set to the 'moc-tqt'.
Please try this patch instead of your proposed. This is a reduced "essence" of patches 594a27c9, 18173187 and 7b10d93d.
Slavek
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.
On 08/24/2012 10:11 AM, David C. Rankin wrote:
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'll test the patch and report back. Looking closely at what my patch does and what your patch does, I appears that they both accomplish the same thing regarding the path information from 2 different directions:
AC_PATH_PROGS(MOC_QT3, [moc-tqt], no, [$QT3_PREFIX:$PATH])
You seem to be providing the ':$PATH' information explicitly, while:
'$^' is a list of all the prerequisites of the rule, including the names of the directories in which they were found.
What I don't know is which is the 'most correct' way to do it. After testing, if your works for my build, I'm happy just pushing yours. Will report back.
On Friday 24 of August 2012 17:20:08 David C. Rankin wrote:
On 08/24/2012 10:11 AM, David C. Rankin wrote:
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'll test the patch and report back. Looking closely at what my patch does and what your patch does, I appears that they both accomplish the same thing regarding the path information from 2 different directions:
AC_PATH_PROGS(MOC_QT3, [moc-tqt], no, [$QT3_PREFIX:$PATH])
You seem to be providing the ':$PATH' information explicitly, while:
'$^' is a list of all the prerequisites of the rule, including the names of the directories in which they were found.
What I don't know is which is the 'most correct' way to do it. After testing, if your works for my build, I'm happy just pushing yours. Will report back.
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 --
On 08/24/2012 07:25 PM, Slávek Banko 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
Bewildering??
All I have is:
cd ${srcdir}
## adjust pkgconfig path export PKG_CONFIG_PATH="${PKG_CONFIG_PATH}:/opt/qt3/lib/pkgconfig"
## patch avahi-tqt (3.5.13-sru not patched) msg "Patching - avahi-tqt..." patch -Np0 -i ${srcdir}/avahi-tqt-watch.moc3.diff
cd ${srcdir}/${pkgname#*-}
msg "Starting configure..." ./autogen.sh --prefix=${TDEDIR} \ --sysconfdir=/etc \ --localstatedir=/var
msg "Building - $pkgname..." make
Where the patch is:
--- avahi-tqt/avahi-tqt/Makefile.am +++ avahi-tqt/avahi-tqt/Makefile.am 2012-08-08 22:06:07.211460764 -0500 @@ -34,7 +34,7 @@ qt-watch.cpp
qt-watch.moc3: qt-watch.cpp - $(AM_V_GEN)$(MOC_QT3) moc $^ $@ + $(AM_V_GEN)$(MOC_QT3) $^ -o $@
libavahi_tqt_la_CPPFLAGS = $(AM_CFLAGS) $(QT3_CFLAGS) $(VISIBILITY_HIDDEN_CFLAGS) libavahi_tqt_la_LIBADD = $(AM_LDADD) $(QT3_LIBS)
I don't see where the difference could be?
On Saturday 25 of August 2012 03:08:26 David C. Rankin wrote:
Bewildering??
All I have is:
cd ${srcdir}
## adjust pkgconfig path export PKG_CONFIG_PATH="${PKG_CONFIG_PATH}:/opt/qt3/lib/pkgconfig"
## patch avahi-tqt (3.5.13-sru not patched) msg "Patching - avahi-tqt..." patch -Np0 -i ${srcdir}/avahi-tqt-watch.moc3.diff
cd ${srcdir}/${pkgname#*-}
msg "Starting configure..." ./autogen.sh --prefix=${TDEDIR} \ --sysconfdir=/etc \ --localstatedir=/var
msg "Building - $pkgname..." make
Where the patch is:
--- avahi-tqt/avahi-tqt/Makefile.am +++ avahi-tqt/avahi-tqt/Makefile.am 2012-08-08 22:06:07.211460764 -0500 @@ -34,7 +34,7 @@ qt-watch.cpp
qt-watch.moc3: qt-watch.cpp
- $(AM_V_GEN)$(MOC_QT3) moc $^ $@
- $(AM_V_GEN)$(MOC_QT3) $^ -o $@
libavahi_tqt_la_CPPFLAGS = $(AM_CFLAGS) $(QT3_CFLAGS) $(VISIBILITY_HIDDEN_CFLAGS) libavahi_tqt_la_LIBADD = $(AM_LDADD) $(QT3_LIBS)
I don't see where the difference could be?
What contain variable MOC_QT3 during your build? You can show it for example by adding: echo $(AM_V_GEN)$(MOC_QT3) moc $^ $@
before patched line.
Slavek --
On Friday 24 of August 2012 17:20:08 David C. Rankin wrote:
On 08/24/2012 10:11 AM, David C. Rankin wrote:
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'll test the patch and report back. Looking closely at what my patch
does and
what your patch does, I appears that they both accomplish the same thing regarding the path information from 2 different directions:
AC_PATH_PROGS(MOC_QT3, [moc-tqt], no, [$QT3_PREFIX:$PATH])
You seem to be providing the ':$PATH' information explicitly, while:
'$^' is a list of all the prerequisites of the rule, including the names
of the
directories in which they were found.
What I don't know is which is the 'most correct' way to do it. After
testing,
if your works for my build, I'm happy just pushing yours. Will report
back.
David,
I read the comments for bug 920, which addresses exactly the same problem. After all, refers the same proposed patch. But comments confirm what I have also stated. Patches 18173187 (partially) and 7b10d93d cherry picked into v3.5.13-sru.
http://bugs.pearsoncomputing.net/show_bug.cgi?id=920#c4
Slavek --
-
David C. Rankin -
Slávek Banko