trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: March 2012

Re: [trinity-devel] Tim - need a 'cheat sheet' to use to solve TQxzy not declared issues

From: "David C. Rankin" <drankinatty@...>
Date: Sun, 25 Mar 2012 00:06:49 -0500
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...

-- 
David C. Rankin, J.D.,P.E.