Issue 112339 - automatic and system-lucene build broken since m79
Summary: automatic and system-lucene build broken since m79
Status: CLOSED FIXED
Alias: None
Product: Build Tools
Classification: Code
Component: code (show other issues)
Version: DEV300m79
Hardware: All All
: P1 (highest) Trivial (vote)
Target Milestone: ---
Assignee: rene
QA Contact: issues@tools
URL:
Keywords: regression
: 111990 (view as issue list)
Depends on:
Blocks: 112263
  Show dependency tree
 
Reported: 2010-06-13 10:43 UTC by rene
Modified: 2013-08-07 15:35 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description rene 2010-06-13 10:43:08 UTC
Hi obo,

my m82 build(I skipped some milestones) failed:

Optimizing ...
Checking cfs file _0.cfs: Found
Checking segment file segments_3: Not found
segment file check failed, terminating...
dmake:  Error code 255, while making '../../unxkfgi6.pro/bin/sbasic_en-US.zip'

I guess this is because of your change in obo48
(http://www.openoffice.org/issues/show_bug.cgi?id=109700), which has serious
problems:

- it probably would not work with system-lucene (that's what I use, and which is
the only alternative on some platforms. Even if internal lucene was working,
using system-lucene shouödn't be broken)
- I guess you don't use system-lucene, so as you filed issue 109700 I guess the
same problem happens for you with internal system lucene, too. In the issue you say:

"Otherwise an error message need to be thrown, to trigger a rebuild
of the "damaged" file."

This
a) breaks automatic builds without any ability to intervene (any failure would
break it and there's no way to continue it after doing something) and
b) it just might be (as here with system-lucene) that it happens the same every try.

I also read in the issue that it breaks for MSP, so a quick'n'dirty fix for this
for everything !Windows would be this:

-- target.pmk  2010-06-13 09:33:45.000000000 +0000
+++ target.pmk-old      2010-06-13 09:31:09.000000000 +0000
@@ -37,11 +37,7 @@
 $(LINKALLTARGETS) : $(foreach,i,$(LINKLINKFILES)
$(COMMONMISC)$/$$(@:b:s/_/./:e:s/.//)/$i)
$(subst,LANGUAGE,$$(@:b:s/_/./:e:s/.//) $(LINKADDEDDEPS))
$(COMMONMISC)$/xhp_changed.flag $(PRJ)$/helpers$/hid.lst
        $(HELPLINKER) @$(mktmp -mod $(LINKNAME) -hid $(PRJ)$/helpers$/hid.lst
-src $(COMMONMISC) -sty $(PRJ)$/source$/auxiliary$/embed.xsl -zipdir
$(MISC)$/ziptmp$(@:b) -idxcaption $(PRJ)$/source$/auxiliary$/idxcaption.xsl
-idxcontent $(PRJ)$/source$/auxiliary$/idxcontent.xsl -lang
{$(subst,$(LINKNAME)_, $(@:b))} $(subst,LANGUAGE,{$(subst,$(LINKNAME)_, $(@:b))}
$(LINKADDEDFILES)) $(foreach,i,$(LINKLINKFILES)
$(COMMONMISC)$/{$(subst,$(LINKNAME)_, $(@:b))}/$i) -o $@.$(INPATH))
 .IF "$(SOLAR_JAVA)" == "TRUE"
-.IF "$(OS)" == "WNT"
        $(JAVAI) $(JAVAIFLAGS) $(JAVA_LIBRARY_PATH) -cp "$(my_cp)"
com.sun.star.help.HelpIndexerTool -lang $(@:b:s/_/./:e:s/.//) -mod $(LINKNAME)
-zipdir $(MISC)$/ziptmp$(@:b) -o $@.$(INPATH) -checkcfsandsegname _0 _3
-.ELSE
-       $(JAVAI) $(JAVAIFLAGS) $(JAVA_LIBRARY_PATH) -cp "$(my_cp)"
com.sun.star.help.HelpIndexerTool -lang $(@:b:s/_/./:e:s/.//) -mod $(LINKNAME)
-zipdir $(MISC)$/ziptmp$(@:b) -o $@.$(INPATH) -checkcfsname _0
-.ENDIF
    $(RENAME) $@.$(INPATH) $@
 .ELSE
        -$(RM) $(MISC)$/ziptmp$(@:b)$/content/*.*

In the current form, the build is constantly breaking without any means to fix
it (thus P1)
Comment 1 rene 2010-06-13 15:05:04 UTC
*** Issue 111990 has been marked as a duplicate of this issue. ***
Comment 2 rene 2010-06-14 08:46:46 UTC
oops just noticed my patch is reversed... The idea should be clear, though, anyways
Comment 3 oliver.bolte 2010-06-14 10:35:50 UTC
Fixed on MWS.
Comment 4 oliver.bolte 2010-06-14 10:36:43 UTC
@rene: verify, please.
Comment 5 rene 2010-06-14 11:40:22 UTC
obo: so the -checkcfsname is also not needed? ok.. I left it in as I backed just
obo48s changes out.

Patch which went into master (making it effectively sun-only) is ok for me :)
Comment 6 rene 2010-06-14 11:42:20 UTC
.
Comment 7 dtardon 2010-06-21 07:55:28 UTC
works fine -> closing