Difference between revisions of "Build Environment Effort/Status And Next Steps"

Revision as of 15:59, 31 January 2011

Integration of first milestone of the new build system in DEV300 m96

New features

With the integration of the CWS gnumake2 we got support for the following target types in our new build system:

• compiling and linking C, C++, Objective-C files into
  • shared libraries
  • non-GUI executables
• compiling src files into resources including localization
• copying a bunch of files ("package") into solver

For cxx compilation we also support some sub-targets:

• compilation of sdi files
• delivery of header files into solver
• processing of component files for UNO service libraries
• support for precompiled headers (currently used only with MSVC++)

Some features have been implemented differently. Here's a list of the most remarkable changes to the old build system:

• no intermediate libraries will be created anymore
• linking with MSVC++ does not use DEF files anymore; this requires proper dllimport/dllexport specifications in the code
• header dependencies on Unix platforms are created by the compiler, no additional makedepend step is required
• header dependencies in converted modules now always include those to headers in solver
• in converted modules a "build" command does not work (you will get a response telling what to do)
• when compiling with DEBUG=TRUE, PCH is not disabled automatically

Converted Modules

Along with the new features we converted the following modules to use the new build system:

• tools
• svl
• svtools
• xmloff
• framework
• toolkit
• sfx2
• sw

If you want to support us by converting other modules, please refer to Module Migration.

Detected problems, caveats and known issues

• Compiling with ENABLE_PCH=TRUE and DEBUG=T with MSVC creates dlls that contain debug information only for the symbols of the library; all debug symbols for linked libraries are missing
  • root cause: PCH object needs to be linked into DLL to let mspdbserv find the necessary debug information
  • fix time line: cws gnumake3
  • workaround: call "unset ENABLE_PCH" when compiling with debug until the bug is fixed
• make tells you: *** Warning: .LOW_RESOLUTION_TIME file (...) has a high resolution time stamp
  • root cause: different tools and file systems use different time stamps; some of them just have a resolution of seconds, others even support micro or nano seconds; for checking dependencies the build system is told that it must not use the sub-second parts as it can't rely on all tools and file systems using the full time stamps. The only way to do that is telling make that there are no such parts in the time stamps. Unfortunately this triggers this warning.
  • fix time line: can only be fixed in GNU make, thus unclear
  • workaround: setting the environment variable gb_HIRESTIME=TRUE silences the warning (but enables checking of sub-second parts); in case this causes permanent re-delivery of files to solver because the tools have different resolutions (e.g. micro seconds vs. nano seconds), you can't use the workaround and have to live with the warning; this case was found in builds over nfs on Solaris Intel.

Ongoing work in CWS gnumake3

Currently we are adding support for the following target types:

• GUI executables (done)
• static libraries (done)
• cppunit tests (done)
• junit tests (done)
• custom targets (done)

We are also working on fixing some problems found after integration of gnumake2:

• incomplete debug information when building with PCH enabled on Windows (done)
• broken mingw and freebsd ports (ongoing)
• broken builds caused by command line lenght limits (done where found)
• WERROR builds broken on unix platforms (ongoing)

The following modules have been converted successfully:

• comphelper
• sot
• vbahelper
• editeng
• svx

Roadmap for the next milestone

Work is ongoing for the following new target types (and it won't be fixed in gnumake3):

• idl compilation in udkapi, offapi, vbaapi und offuh
• compilation of java code into jar files

For all other target types we decided to prioritize them by the order of appearance. We are trying as much modules as fast as possible. Work is in progress in the following modules:

• writerfilter
• oox
• vcl

New requirements found in doing this get high priority. So far we detected the following missing target types:

• native resources
• custom targets for generation of cxx files (will be provided by gnumake3)

Other target types yet already planned, but not prioritized:

• external modules
• zip targets
• extensions
• ant builds
• image processing
• xcu processing