Build Environment Effort/DBGUTIL

From Apache OpenOffice Wiki
Jump to: navigation, search

Edit.png

Build Environment Effort

Quick Navigation

About this template


Outline

Currently we always build pro and nonpro versions on every platform for each release (master) build. The difference between those builds is that in pro builds debugging code is masked by putting it into blocks with "#ifdef DBG_UTIL" or "#if OSL_DEBUG_LEVEL>0". It is very probable that having this code in a "pro" build, but making its execution depending on e.g. "if (bDebug) {...}" will not degrade performance so much that it can be noticed. So we think that uniting both builds is possible. Thus we could save a lot of time at doing master builds. A nice additional benefit would be that we would be able to activate debug code even at customer sites, so we would get better diagnostic tools.

We can make our "killnonpro" stuff compatible: make the changes, but leave the #ifdefs where they are. Later on we can first activate them in pro builds and later remove them. This gives us time to test and perhaps roll back.

The following questions came up:

  • Is our assumption true that performance is not hit considerably?
  • How much does our code size grow in pro builds, especially the size of those libraries we load on startup?
  • Is it acceptable that using stl debug code now will require a complete rebuild of all libraries depending on stlport?
  • Why do we use some different compiler or linker settings for nonpro builds on some platforms and what would be the consequence of losing that difference?

Explanation for the third item: stlport has a special debug version that is incompatible to the normal one (so choosing one of them is a compile time option). It allows range checking, checking iterators for stemming from the same containers etc. If a runtime check fails, the program will create an exception and allows developers to track down the error. Currently we automatically use the debug version in nonpro builds, but not in pro builds. Using this version of the library in pro builds surely will degrade performance as its code can't be put into "if (bDebug)" easily. We also would get crashes even for small bugs that per se are not very severe. So we can't use the debug version in our "united" builds.

Evaluation

Evaluation of performance requires a lot of code changes, so before we will do it we should evaluate the other items that don't require a lot of changes.

Code size

A simple comparison between the code in pro and nonpro builds would require to find out and check all differences between the builds, a much simpler way is doing a pro build with DBG_UTIL set to "TRUE" and OSL_DEBUG_LEVEL set to "1". A first glance on the code shows that a lot of debugging code is depending on "#ifndef PRODUCT". So it was necessary to replace that by "#ifdef DBG_UTIL". In most cases this was possible by a simple text search and replace, some cases required handwork. Besides that, the following changes where made (see issue 103452):

  • the variable PRODUCT_FULL was removed completely from all files
  • the variable PRODUCT is now used only in makefiles and their includes
  • the HDEFS variable was found to be unused and so it was removed also

All changes have been committed to the CWS killnonpro. They could be integrated even if we decided not to make the switch as they just consolidate the usage of defines.

What matters is code size for the Office startup (cold start performance), not so much the overall code size. The increase of code size for e.g. Writer is approximately 6%. This seems to be too much. We could make the larger parts loadable on demand, but there is a risk that over time too much debug code will get into the code loaded in startup. So another strategy is needed.

Making pro and nonpro comaptible by moving debugging stuff into dedicated libs

We could move the tools/debug stuff and its vcl additions into additional libraries so that tools and vcl no longer are incompatible between pro and nonpro. This enables developers to prepare selected libraries for "nonpro" support. Advantage: no annoyance by assertions from others. We need to decide if we want to prebuild nonpro libraries in the master build (without creating full nonpro installation sets).

With this model we would have the general assertion support in vcl. Assertions and other debugging messages as well as larger chunks of debugging code still will require building with DBG_UTIL and/ore OSL_DEBUG_LEVEL >= 1.

STLPORT debugging

We need to clarify the following:

  • how many developers use nonpro builds
  • how often do we profit from having STLPORT debug code active while developing code
  • which libraries do we need to rebuild to get an STLPORTDEBUG enabled build
  • is it acceptable to require instrumented builds for working with the debug code
  • can we set up regular STLPORTDEBUG builds and tests based on test scripts (like e.g. the valgrind tests)
Personal tools