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

From Apache OpenOffice Wiki
Jump to: navigation, search
 
(21 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
{{Build Environment Effort}}
 
{{Build Environment Effort}}
  
−
== Integration of first milestone of the new build system in DEV300 m96 ==
+
=== Ongoing and planned work can be found [[Build_Environment_Effort/Current work|here]]. ===
 +
If you want to support us by converting modules from dmake to GNU Make, please refer to [[Build_Environment_Effort/Module_Migration|Module Migration.]]
 +
 
 +
== Integration of first milestone of the new build system CWS gnumake2 into DEV300 m96 ==
 
=== New features ===
 
=== New features ===
 
With the integration of the CWS gnumake2 we got support for the following target types in our new build system:
 
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
+
* compiling and linking C, C++, Objective-C++ files into
 
** shared libraries
 
** shared libraries
 
** non-GUI executables
 
** non-GUI executables
Line 24: Line 27:
 
* when compiling with DEBUG=TRUE, PCH is not disabled automatically
 
* when compiling with DEBUG=TRUE, PCH is not disabled automatically
  
−
=== Converted Modules ===
+
=== Converted modules ===
 
Along with the new features we converted the following modules to use the new build system:
 
Along with the new features we converted the following modules to use the new build system:
 
* tools
 
* tools
Line 35: Line 38:
 
* sw
 
* sw
  
−
If you want to support us by converting other modules, please refer to [[Build_Environment_Effort/Module_Migration|Module Migration]].
+
== 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 ===
+
== 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'''
 
* '''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
 
** root cause: PCH object needs to be linked into DLL to let mspdbserv find the necessary debug information
−
** fix time line: cws gnumake3
+
** fix time line: '''fixed in gnumake3, integrated into DEV300 m100'''
 
** workaround: call "unset ENABLE_PCH" when compiling with debug until the bug is fixed
 
** workaround: call "unset ENABLE_PCH" when compiling with debug until the bug is fixed
−
* '''make tells you: *** Warning: .LOW_RESOLUTION_TIME file `/cygdrive/d/OOo/o_gnumake3/DEV300/wntmsci12/lib/sfx.lib' has a high resolution time stamp'''
+
* '''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, other even support nano seconds; for checking dependencies the build system is told that it must not use the sub-second parts. The only way to do that is telling it that there are no such parts in the time stamps. Unfortunately this triggers this warning.
+
** 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 <tt>cp -p foo bar</tt> or <tt>touch -r foo bar</tt> will result in <tt>bar</tt>'s timestamp being truncated, and thus <tt>bar</tt> older than <tt>foo</tt>.
 +
**** 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
 
** 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 the tools have different resolutions (e.g. micro seconds vs. nano seconds); so you can't use the workaround and have to live with the warning; this case was found in builds over nfs on Solaris Intel.
+
** 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'''
−
== Ongoing work in CWS gnumake3 ==
+
** root cause: not supported yet
−
Currently we are adding support for the following target types:
+
** fix time line: planned for cws gnumake4
−
* GUI executables (done)
+
** workaround: not necessary
−
* static libraries (done)
+
* '''fwe library needs to export all symbols on Linux'''
−
* cppunit tests (done)
+
** root cause: ancient sv_decl... macro prevents proper usage of DLLEXPORT declarations
−
* junit tests (done)
+
** fix time line: planned for cws gnumake4
−
* custom targets (done)
+
** workaround: not necessary
−
 
+
* '''GNU make crashes at times on cygwin'''
−
We are also working on fixing some problems found after integration of gnumake2:
+
** root cause: there is a [http://savannah.gnu.org/bugs/?20033 bug] in GNU make 3.81
−
* incomplete debug information when building with PCH enabled on Windows (done)
+
** 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
−
* broken mingw and freebsd ports (ongoing)
+
** workaround: manual restarting the build until it finishes or building GNU make 3.81 from [http://ftp.gnu.org/gnu/make/make-3.81.tar.gz sources] with [http://savannah.gnu.org/bugs/download.php?file_id=13043 patch]
−
* broken builds caused by command line lenght limits (done where found)
+
** 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
−
* 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
 

Latest revision as of 18:30, 25 February 2011

Edit.png

Build Environment Effort

Quick Navigation

About this template


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
Retrieved from "https://wiki.openoffice.org/w/index.php?title=Build_Environment_Effort/Status_And_Next_Steps&oldid=194379"
Personal tools