Here's
what I do. Create a patch. In this case to fix
the QString -> TQString. Then
build the package with the
patch. If the build succeeds then submit the patch in a bug
report. If the patch fails then submit a big report
explaining your effort.
Err OK... This is where I have a bit more
learning to know
what to patch where :)
Yeah, that's how I learn. I won't pretend to have mastered much, but I'm
willing to get my hands dirty. :)
I read the build failure. Most of the time the failure is straightforward. Sometimes not
and then I'll rerun the build without parallel building (NUMJOBS=-j1). That forces an
easier to read output because the build output is sequential. Slower too. :)
Read the failure and be sure to find the problem file. Often the output says in this file,
declared by that file, etc. The last file listed is the problem.
Then look at the line number, which is a number after a colon next to the name of the
problematic file.
Open that file from the sources and verify the text. In your case look for QString.
For me, I prefer not to edit my local GIT repository while experimenting because I have
not yet learned the many ways of the git commands. Therefore I copy that module to a
working directory. Then make another copy with the .new extension. I edit the problematic
file in the .new directory. In your case change QString to TQString.
Then in the parent directory of the two copied directories:
diff -urN module module.new > module-tqstring-fix.diff
Name the diff file to something that makes sense.
Then merge the patch into the build process as usual.
Darrell
