Created attachment 1011 [details]
The problem generated header

In the GIT repository:

http://git.trinitydesktop.org/cgit/tdenetwork/tree/krdc/rdp/rdpprefs.ui.h

Notice line 76:

tqDebug("current depth: %i", cmbColorDepth->currentItem() );

Not sure why your sources are different.

> In the GIT repository:
> 
> http://git.trinitydesktop.org/cgit/tdenetwork/tree/krdc/rdp/rdpprefs.ui.h
> 
> Notice line 76:
> 
> tqDebug("current depth: %i", cmbColorDepth->currentItem() );
> 
> Not sure why your sources are different.

Those files shouldn't present in repository at all. They are compile-time generated.

Do you see the same build failure when building against TQt3 rather than Qt3?

(In reply to comment #4)
> Do you see the same build failure when building against TQt3 rather than Qt3?
I haven't build tqt yet. But Slavek said he doesn't expect it with tqt.

>Those files shouldn't present in repository at all. They are compile-time generated.

Searching the entire GIT source tree shows 362 *.ui.h files. Are you saying none of them should be in the source tree?

(In reply to comment #6)
> >Those files shouldn't present in repository at all. They are compile-time generated.
> 
> Searching the entire GIT source tree shows 362 *.ui.h files. Are you saying
> none of them should be in the source tree?

Generally, yes. But it seems they exist since kde-3.5 times so some of them may be included to Makefile.am's or CMakeList.txt's so their removal can break build process in some particular cases.

Use tqDebug.

For reference, qDebug is provided by Qt4 and therefore we cannot safely use that method name in TQt3/TDE.

(In reply to comment #8)
> Use tqDebug.
> 
> For reference, qDebug is provided by Qt4 and therefore we cannot safely use
> that method name in TQt3/TDE.

It's not the explanation why qt's uic produces broken code...

(In reply to comment #3)
> > In the GIT repository:
> > 
> > http://git.trinitydesktop.org/cgit/tdenetwork/tree/krdc/rdp/rdpprefs.ui.h
> > 
> > Notice line 76:
> > 
> > tqDebug("current depth: %i", cmbColorDepth->currentItem() );
> > 
> > Not sure why your sources are different.
> 
> Those files shouldn't present in repository at all. They are compile-time
> generated.

No, they are not.  There are several ui-related files, and their purposes are listed below:
<uifile>.ui:   XML-format description of GUI structure
<uifile>.ui.h: User- or Qt Designer- generated bindings for the .ui file of the same name
<uifile>.h:    Automatically generated file (from uic)
<uifile>.cpp:  Automatically generated file (from uic)
<uifile>.moc:  Automatically generated file (from moc)

If something is regenerating or modifying a .ui.h file, there is something very wrong in the build system.

(In reply to comment #0)
> Created attachment 1010 [details]
> Build log
> 
> One of uic-generated header contains Debug() instead of qDebug() (or tqDebug()
> I'm not sure how it should be named now). See the log.
> 
> I'm Building with qt3/tqtinterface.

Are you using CMake or Autotools?

(In reply to comment #11)
> Are you using CMake or Autotools?

cmake(In reply to comment #10)

> (In reply to comment #3)
> No, they are not.  There are several ui-related files, and their purposes are
> listed below:
> <uifile>.ui:   XML-format description of GUI structure
> <uifile>.ui.h: User- or Qt Designer- generated bindings for the .ui file of the
> same name
> <uifile>.h:    Automatically generated file (from uic)
> <uifile>.cpp:  Automatically generated file (from uic)
> <uifile>.moc:  Automatically generated file (from moc)
> 
> If something is regenerating or modifying a .ui.h file, there is something very
> wrong in the build system.

are you sure about that? 
I'm not really into qt3 build process etc. But as I can see <uifile>.ui.h files are generated everywhere. So if you are right I suspect we got two bugs: 
1. One in Qt code generators (in a part of Designer or wherever those ui.h are come from)
2. In cmake core functionality.

On 3.5.13.1 that works well.

(In reply to comment #12)
> (In reply to comment #11)
> > Are you using CMake or Autotools?
> 
> cmake(In reply to comment #10)
<snip>
> are you sure about that? 

Yes.

> I'm not really into qt3 build process etc. But as I can see <uifile>.ui.h files
> are generated everywhere. So if you are right I suspect we got two bugs: 
> 1. One in Qt code generators (in a part of Designer or wherever those ui.h are
> come from)

Qt Designer (a GUI application) is supposed to be able to generate/edit ui.h files.  uic is not.

> 2. In cmake core functionality.
> 
> On 3.5.13.1 that works well.

Can you please attach a full verbose CMake build log to this report?  I would like to see exactly what tools are run and on which files during the build process.

Thanks!

> > I'm not really into qt3 build process etc. But as I can see <uifile>.ui.h files
> > are generated everywhere. So if you are right I suspect we got two bugs: 
> > 1. One in Qt code generators (in a part of Designer or wherever those ui.h are
> > come from)
> 
> Qt Designer (a GUI application) is supposed to be able to generate/edit ui.h
> files.  uic is not.
>
> > 2. In cmake core functionality.
> > 
> > On 3.5.13.1 that works well.
> 
> Can you please attach a full verbose CMake build log to this report?  I would
> like to see exactly what tools are run and on which files during the build
> process.
> 
> Thanks!

First off all sorry for such loud words, I can be sometimes really offensive and mistrustful to the source and other people's work when I can't find the reason of a bug.

First of all ui.h files are just being copied to build directory and then processed by the tqt-replace.
The blame in all this is the next substitution in tqt-replace:
 sed -i 's/\([ \t]\)tq\([^:(_)\t ]\)/\1\2/g' "$1"
I've got no idea that this is supposed to do but it renames tqDebug->Debug as well.

So now I think it's up to you to decide how to better fix it... 
IMHO to add another substitution for qDebug to tqt-replace is the right choise.

PS: And what do you mean under the «verbose build log»?

> First off all sorry for such loud words, I can be sometimes really offensive
> and mistrustful to the source and other people's work when I can't find the
> reason of a bug.

No problem; I know first hand how frustrating debugging can be!

> First of all ui.h files are just being copied to build directory and then
> processed by the tqt-replace.
> The blame in all this is the next substitution in tqt-replace:
>  sed -i 's/\([ \t]\)tq\([^:(_)\t ]\)/\1\2/g' "$1"
> I've got no idea that this is supposed to do but it renames tqDebug->Debug as
> well.

Weird!  I would expect that line to read:
sed -i 's/\([ \t]\)tq\([^:(_)\t ]\)/\1q\2/g' "$1"

If you make that change does the build succeed?

> PS: And what do you mean under the «verbose build log»?

CMake can either show or hide the program and arguments of each command it executes AFAIK.  I wanted to see what CMake was executing and when, but since you found the source of the problem I don't need the build logs :-)

Actually now that I think about it further, why are ui.h files being run through tqt-replace at all?  Only the .ui files themselves should be run through tqt-replace; this smells like a subtle TDE CMake build system bug to me.

(In reply to comment #15)
> > First of all ui.h files are just being copied to build directory and then
> > processed by the tqt-replace.
> > The blame in all this is the next substitution in tqt-replace:
> >  sed -i 's/\([ \t]\)tq\([^:(_)\t ]\)/\1\2/g' "$1"
> > I've got no idea that this is supposed to do but it renames tqDebug->Debug as
> > well.
> 
> Weird!  I would expect that line to read:
> sed -i 's/\([ \t]\)tq\([^:(_)\t ]\)/\1q\2/g' "$1"
> 
> If you make that change does the build succeed?

yes. 

So after all it's just a trivial mistake in the script since the first days of trinity existence >_<

> > PS: And what do you mean under the «verbose build log»?
> 
> CMake can either show or hide the program and arguments of each command it
> executes AFAIK.  I wanted to see what CMake was executing and when, but since
> you found the source of the problem I don't need the build logs :-)
You're about make VERBOSE=1? The log is attached since the bug filled... So I surprised and thought you know some very-verbose mode.

I'm pretty sure the mistake is actually in the cmake folder, at Line 25 of tde_uic.cmake:

http://git.trinitydesktop.org/cgit/cmake/tree/modules/tde_uic.cmake

As far as I know there is absolutely no reason to execute tqt-replace on those files, and also AFAIK Autotools does not do this, hence the reason Autotools sometimes works while CMake does not.

(In reply to comment #18)
> I'm pretty sure the mistake is actually in the cmake folder, at Line 25 of
> tde_uic.cmake:
> 
> http://git.trinitydesktop.org/cgit/cmake/tree/modules/tde_uic.cmake
> 
> As far as I know there is absolutely no reason to execute tqt-replace on those
> files, and also AFAIK Autotools does not do this, hence the reason Autotools
> sometimes works while CMake does not.

yes, if you say so, the lines 23 through 26 seems to be unnecessary. But  if this change will break something else requires a further testing...

Anyway that the «q» is missing in the tqt-replace sounds reasonable as well.

Please, this issue is still valid? On Debian and Ubuntu is tdenetwork built using CMake from 2 December 2012 and the problem does not occur.

(In reply to comment #20)
> Please, this issue is still valid? On Debian and Ubuntu is tdenetwork built
> using CMake from 2 December 2012 and the problem does not occur.

Sorry I've lost my test virtualmachines's and can't test it for now...
But it should be there...
It seems there was no major changes since it was opened. 
May be it compiles well  because you already fixed tqt-replace script somewhere? Or TQT_REPLACE_SCRIPT cmake variable haven't been set at all during configuration...

So keep it opened yet...

Is this problem still valid? I have been compiling package sets from GIT the past couple of weeks. I have no problem building krdc. krdc also was fixed recently with commit 339d5c5 as noted in bug report 1403. As reported in comment 10 of that report, I have no problem using krdc/krfb.

No response from the original reporter. Closing as WORKSFORME.