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

Latest revision as of 18:30, 25 February 2011

Ongoing and planned work can be found here.

If you want to support us by converting modules from dmake to GNU Make, please refer to Module Migration.

Integration of first milestone of the new build system CWS gnumake2 into 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

Integration of second milestone CWS gnumake3 into DEV300 m100

New features

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

• build static libraries
• build GUI executables
• build cppunit tests
• build junit tests
• build custom targets for arbitrary generation of header and source files
• build generated cxx files

Converted modules

• svx
• vbahelper
• editeng
• sot
• comphelper

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: fixed in gnumake3, integrated into DEV300 m100
  • 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.
    • Solaris ZFS has nanosecond timestamps, which are also available on NFS exports; but many utilities do not support nanosecond timestamps, so cp -p foo bar or touch -r foo bar will result in bar's timestamp being truncated, and thus bar older than foo.
      • Ubuntu 9.04: coreutils 6.10: microsecond
      • Ubuntu 10.04: coreutils 7.4: nanosecond
      • Solaris 10u8 touch: microsecond
      • MacOSX 10.6 touch: microsecond
  • 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.
• adjustvisibility tool needs to be used in new build system on Solaris
  • root cause: not supported yet
  • fix time line: planned for cws gnumake4
  • workaround: not necessary
• fwe library needs to export all symbols on Linux
  • root cause: ancient sv_decl... macro prevents proper usage of DLLEXPORT declarations
  • fix time line: planned for cws gnumake4
  • workaround: not necessary
• GNU make crashes at times on cygwin
  • root cause: there is a bug in GNU make 3.81
  • more info: it doesn't crash always, and the more often the more parallel threads are used; at least Ubuntu seems to have a patched GNU make 3.81 without the bug
  • workaround: manual restarting the build until it finishes or building GNU make 3.81 from sources with patch
  • fix time line: GNU make 3.82 fixed the bug, but it has a performance regression and is not recommended; we will soon provide a patched GNU make for cygwin and ask the cygwin maintainers to patch their own version too