Tim, anyone,
It would be nice to have a troubleshooting 'cheat sheet' to use to solve TQwhatever not declared failures when they are encountered. I can read c++, I know what constructors are, what destructors are, what public and private members are, etc.., but with a project the size of TDE, with the multiple levels of submodule inclusion through the git tree, my eyes glaze over trying to chase down where the declaration problems are when they are encountered.
Case-in-point, tdeadmin. I ran into a build failure cause by 'TQListViewItem' has not been declared:
In file included from knetworkconfdlg.cpp:11:0: knetworkconfdlg.h:142:40: error: 'TQListViewItem' has not been declared In file included from knetworkconfdlg.cpp:31:0: ./knetworkconfdlg.ui.h:153:6: error: prototype for 'void KNetworkConfDlg::updateProfileNameSlot(TQListViewItem*)' does not match any in class 'KNetworkConfDlg' knetworkconfdlg.h:142:18: error: candidates are: virtual void KNetworkConfDlg::updateProfileNameSlot(int*) ./knetworkconfdlg.ui.h:147:6: error: virtual void KNetworkConfDlg::updateProfileNameSlot() In file included from knetworkconfdlg.cpp:688:0: knetworkconfdlg.moc: In member function 'virtual bool KNetworkConfDlg::tqt_invoke(int, TQUObject*)': knetworkconfdlg.moc:171:80: error: no matching function for call to 'KNetworkConfDlg::updateProfileNameSlot(TQListViewItem*)' knetworkconfdlg.moc:171:80: note: candidates are: ./knetworkconfdlg.ui.h:147:6: note: virtual void KNetworkConfDlg::updateProfileNameSlot() ./knetworkconfdlg.ui.h:147:6: note: candidate expects 0 arguments, 1 provided knetworkconfdlg.h:142:18: note: virtual void KNetworkConfDlg::updateProfileNameSlot(int*) knetworkconfdlg.h:142:18: note: no known conversion for argument 1 from 'TQListViewItem*' to 'int*'
If I knew where to start, then I wouldn't mind trying to figure out where to fix the declaration error. But not knowing whether I just start grepping within tdeadmin for TQListViewItem or whether I need to start in tqtinterface or what, I'm somewhat left chasing my tail. I don't know if it is possible, but I know it would help me and others if there was something like:
TQString objects are type ...... TQListViewItem objects are type .....
To fix TQxzy declaration issues:
(1) grep for '___________' in ___________; (2) if declare ___________ found then (3) ___________; else (4) then grep in ______________; (5) if declare ____________ found then ...........
Just some simple decision tree would go a long way to get everyone involved in helping with these issues and also provide a valuable tool that would help cut down bug squashing time even if the person can't solve it by being able to say 'I got to step 8 in troubleshooting and 1-7 are fine, but I can't figure out what to do next...'
Worth a thought. If somebody else can help here, please jump in.
It would be nice to have a troubleshooting 'cheat sheet' to use to solve TQwhatever not declared failures when they are encountered. I can read c++, I know what constructors are, what destructors are, what public and private members are, etc.., but with a project the size of TDE, with the multiple levels of submodule inclusion through the git tree, my eyes glaze over trying to chase down where the declaration problems are when they are encountered.
If I knew where to start, then I wouldn't mind trying to figure out where to fix the declaration error. But not knowing whether I just start grepping within tdeadmin for TQListViewItem or whether I need to start in tqtinterface or what, I'm somewhat left chasing my tail. I don't know if it is possible, but I know it would help me and others if there was something like:
TQString objects are type ...... TQListViewItem objects are type .....
To fix TQxzy declaration issues:
(1) grep for '___________' in ___________; (2) if declare ___________ found then (3) ___________; else (4) then grep in ______________; (5) if declare ____________ found then ...........
Just some simple decision tree would go a long way to get everyone involved in helping with these issues and also provide a valuable tool that would help cut down bug squashing time even if the person can't solve it by being able to say 'I got to step 8 in troubleshooting and 1-7 are fine, but I can't figure out what to do next...'
Worth a thought. If somebody else can help here, please jump in.
I have a copy of the original Qt3 docs. Sometimes I browse those docs to understand what is happening. I remove the T, t, or TQT_ prefix and the docs pretty much are the same.
Sometimes the problem is a missing header include. Often I grep the TQt headers for the particular function name. Then I look in the cpp to verify the respective header file is included.
Sometimes the trail is maddening because one TQt header includes another TQt header, which includes another TQt header. Ultimately there is an inclusion of the mother of all TQt headers, tqt.h. That is where my trail often ends because when the header is being included then there is some other explanation for the declaration error.
Then there are scope errors, as you alluded. Also class errors.
I get confused because the old code compiled fine without the TQt layer. Merely prefixing names should not cause problems. Yet things still break. Like you I don't know where to turn. I have spent hours and hours reading around the web trying to learn more. I do enjoy learning, but the cost is huge right now. I'm sure I have learned something along the journey, but most of the time I surrender. I can grasp only so much with my currently limited knowledge.
Darrell
On 03/24/2012 07:27 PM, Darrell Anderson wrote:
I get confused because the old code compiled fine without the TQt layer. Merely prefixing names should not cause problems. Yet things still break. Like you I don't know where to turn. I have spent hours and hours reading around the web trying to learn more. I do enjoy learning, but the cost is huge right now. I'm sure I have learned something along the journey, but most of the time I surrender. I can grasp only so much with my currently limited knowledge.
Darrell
That is the crux of the complex build system world we find ourselves in with TDE and the multi-layered autoconf or CMake build environment that has been developed. It truly is a thing of beauty to be able to do all that it does, but therein lies a double-edge sword of complexity.
For those that participated in the development of the system, or through specialized education, training or experience are fluent in it, then sorting through where scope and inclusion issues arise may be easily doable. But for those coming into the project, with good skills, but without specialized knowledge of those magical build tools, the learning curve is asymptotic. I'm no dummy and I'm not unfamiliar with complex code, but the TDE autoconf and CMake errors I encounter and down right bewildering.
It is just a downside to all the wonderful code generation that is done by the sophisticated build tools that TDE uses. That is why attracting and keeping the 'corporate knowledge' of how those items work is critical to the project. A primary goal has got to be capturing and documenting how they work as we go along and what to do if things go wrong. Otherwise, the project could die a quick death in the event that the Tims and Sergheis and Darrells and other key members were no longer with the project for whatever reason.
All good points, the wiki needs to on everyones mind as we go through this.
Equally important is knowing who holds this knowledge so when progress is being made and we run into these issues, we know who to contact to get resolution before the issues turn into week-long, month-long road blocks to moving R14 forward for everyone.
At least there is some solace. Through attempting to solve the problems, successful or not, we each pick up more of this knowledge than we may think. A little bit at a time...
-
Darrell Anderson -
David C. Rankin