August 28, 2004 3:17 PM

Building SRC680_m52 (yes, I'm very patient...)

Milestone SRC680_m52 is tagged (not yet announced though). I have finished build of it on GNU/Linux and Solaris/SPARC, build on Windows is still running.

There are several identified/reported issues in this milestone. I hope this list can save you time when you try building it. And please do not laugh when you read ... is now ready and no known build problems are known.
  • #i32707# - binfilter: `acquire' undeclared (first use this function). Ken reported that this issue is also present on HEAD. Fix is already mentioned in the issue but is not yet integrated. It seems to be as simple as adding one #include:
    Index: xmloff_SchXMLAutoStylePoolP.cxx
    ===================================================================
    --- xmloff_SchXMLAutoStylePoolP.cxx     (revision 59)
    +++ xmloff_SchXMLAutoStylePoolP.cxx     (revision 60)
    @@ -58,6 +58,9 @@
      *
      *
      ************************************************************************/
    +
    +#include <xmlprmap.hxx>
    +
     // auto strip #include "SchXMLAutoStylePoolP.hxx"
     #include "PropertyMap.hxx"
  • #i33258# - configure can't work with Sun WorkShop C compiler because of wrong merge (invalid code). It also doesn't support Sun WorkShop C compiler 5.5 that I use on Solaris.
  • #i33459# - set_soenv.in is setting the variable DIRECTX_SUPPORT in the environment file, but e.g. canvas or avmedia (on HEAD) is checking for ENABLE_DIRECTX. For compilation on Windows, you need several files from HEAD!
  • #i32042# - desktop project depends on berkeleydb. I committed the fix to 20040815 so it will be integrated with this cws. But this is in milestones from about m46. It takes so long to merge such build critical issues...
  • #i32858# - dbaccess: toolbox.hrc: No such file or directory. This is also fixed in 20040815.
  • #i32398# - repeated builds in libxml2 result in a build failure. The patch is attached in the issue.
  • #i32565# - repeated builds in officecfg result in a build failure. The patch is not attached in the issue, because it is simply about adding missing underscore in $(MISC)$/$(TARGET)_delzip target.
  • #i33481# - this issue is multi-project. Several files are affected: autodoc/source/ary/inc/nametreenode.hxx, autodoc/source/ary/store/t_storg.hxx, stoc/source/security/lru_cache.h, ucb/source/inc/regexpmap.tpt. The typename was brought in by gcc34 changes but these changes broke .NET2002 compiler on Windows. We probably need to invent a mechanism to overcome this bug, because we want both .NET2002 and .NET2003 to be supported compilers.
  • #i33287# - two files (dp_parceldesc.cxx and dp_sfwk.cxx) in desktop project use the function OUStringToOString without rtl:: prefix.
  • #i33509# - nsplugin uses gtk/gtk.h include file, but doesn't add proper include paths in CFLAGS.
  • #i33458# - repeated builds in scripting/java fails on Windows. Temporary fix is in the issue - simply remove clean target from dependencies. Scripting project has several other minor/non-build issues (#i33504#).
  • #i31666# - solenv/inc/unitools.mk still needs to define several tools for cygwin/tcsh builds on Windows.
  • #i33009# - solenv/inc/wnt.mk contains wrong prefixes for options Zc:forScope and GR.
  • #i29787# - solenv/bin/guw.pl needs two changes to support options like Zc:forScope (see above #i33009#) and delayload.
Update:
  • #i33528# - sc/source/core/data/compressedarray.cxx compilation failure.
  • #i30357# - solenv/inc/packtools.mk wrongly assume that rpm and rpmbuild are installed in the same directory.
It seems that we have to invent a mechanism to not propagate those build critical issues between milestones and quickly fix them on HEAD. I proposed this solution on IRC (sorry for my English): with each and every milestone (like this one, SRC680_m52), new really-short-term child workspace named like build_only_fixes_src680_m52 (or similar) will be opened. It will stay opened for short time like three or four days and people will commit only build fixes there so this cws will be QA'ed and integrated just before the next milestone is to be prepared. It has several advantages: build critical fixes will be integrated much faster than now, people will start to use milestones because right now they can't (see the list of issues above) thus OpenOffice.org 2.0 will get much more testing. I'd like to hear your opinions (on IRC, of course ;-). -----

Posted by Pavel | Permanent link | File under: OpenOffice.org