Issue 15124 - re-running dmake, build stops on project ODK
Summary: re-running dmake, build stops on project ODK
Status: CLOSED FIXED
Alias: None
Product: Build Tools
Classification: Code
Component: code (show other issues)
Version: OOo 1.1 Beta2
Hardware: PC Windows XP
: P3 Trivial (vote)
Target Milestone: OOo 1.1 RC
Assignee: ooo
QA Contact: issues@tools
URL:
Keywords:
: 16762 (view as issue list)
Depends on:
Blocks:
 
Reported: 2003-05-31 12:09 UTC by simonbr
Modified: 2003-11-23 11:38 UTC (History)
5 users (show)

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


Attachments
Patch for odk/util/makefile.mk (567 bytes, patch)
2003-05-31 17:05 UTC, quetschke
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description simonbr 2003-05-31 12:09:03 UTC
re-running dmake after a fairly simple change (nothing to do with ODK) the 
build stops on below error. 
Is it possible that the build stops on an error code of zip simply 
meaning "archive already up to date"? 


Building project odk
=============
/cygdrive/c/ooo_1.1beta2_src/odk/source/bean/native/win32
-------------
/cygdrive/c/ooo_1.1beta2_src/odk/source/OOSupport
/cygdrive/c/ooo_1.1beta2_src/odk/pack/unzip_udk
/cygdrive/c/ooo_1.1beta2_src/odk/source/bean/com/sun/star/beans
mkdir.pl ../../../../../../wntmsci9.pro/class/META-INF/ >& /dev/null
/bin/rm -f ../../../../../../wntmsci9.pro/class/META-INF/MANIFEST.MF >& /dev/nul
l
echo Manifest-Version: 1.0 > ../../../../../../wntmsci9.pro/class/META-INF/MANIF
EST.MF
echo "Solar-Version: 644m13s1(Build:8600)" >> ../../../../../../wntmsci9.pro/cla
ss/META-INF/MANIFEST.MF
cd ../../../../../../wntmsci9.pro/class && zip -u -r officebean.jar  META-INF/MA
NIFEST.MF  com/sun/star/beans
updating: META-INF/MANIFEST.MF (deflated 10%)
-------------
/cygdrive/c/ooo_1.1beta2_src/odk/pack/copying
/cygdrive/c/ooo_1.1beta2_src/odk/pack/gendocu
/cygdrive/c/ooo_1.1beta2_src/odk/util
zip -urq odk644.zip odk644
dmake:  Error code 12, while making '../wntmsci9.pro/bin/odk644.zip'
echo: No match.

ERROR: Error 65280 occurred while making /cygdrive/c/ooo_1.1beta2_src/odk/util
dmake:  Error code 1, while making 'build_all'
echo: No match.
Comment 1 quetschke 2003-05-31 14:33:18 UTC
Yes, I can confirm the issue.

I even know the problem ;-) The:
  zip -urq odk644.zip odk644
doesn't touch the filedate, so a touch at the right place would
solve the problem.

Workaround: Remove the odk644.zip before you do the rebuild.
Comment 2 quetschke 2003-05-31 17:05:56 UTC
Created attachment 6562 [details]
Patch for odk/util/makefile.mk
Comment 3 quetschke 2003-05-31 17:12:05 UTC
Hi Simon,

the previous patch is untested ;-) Can you please try if it works?

Did all other modules rebuild without problem? I usually have problems
with the Modules which use the ALLTAR target.

The following is a hack for W32-tcsh builds:
RCS file: /cvs/tools/solenv/inc/tg_ext.mk,v
retrieving revision 1.44
diff -u -r1.44 tg_ext.mk
--- solenv/inc/tg_ext.mk	28 Apr 2003 16:44:13 -0000	1.44
+++ solenv/inc/tg_ext.mk	20 May 2003 15:06:26 -0000
@@ -177,6 +177,8 @@
 	@+cd $(PACKAGE_DIR) && chmod -R +rw * && $(TOUCH) $(UNTAR_FLAG_FILE)
 	@+cd $(PACKAGE_DIR) && find . -type d -exec chmod a+x {{}} \;
 .ELSE			# "$(GUI)"=="WNT"
+# Native W32 tools generate only filedates with even seconds, cygwin
also with odd seconds
+	+sleep 2
 	@+cd $(PACKAGE_DIR) && attrib /s -r  >& $(NULLDEV) && $(TOUCH)
$(UNTAR_FLAG_FILE)
 .ENDIF			# "$(GUI)"=="WNT"
 
@@ -212,6 +214,10 @@
 .ENDIF          # "$(GUI)"=="WNT"
 .ENDIF			# "$(PATCH_FILE_NAME)"=="none" ||	"$(PATCH_FILE_NAME)"==""
 .IF "$(T_ADDITIONAL_FILES)"!=""
+.IF "$(GUI)"=="WNT"
+# Native W32 tools generate only filedates with even seconds, cygwin
also with odd seconds
+	+sleep 2
+.ENDIF # "$(GUI)"=="WNT"
     +$(TOUCH) $(PACKAGE_DIR)$/$(ADD_FILES_FLAG_FILE)
     +$(TOUCH) $(PACKAGE_DIR)$/$(PATCH_FLAG_FILE)
 .ENDIF          # "$(T_ADDITIONAL_FILES)"!=""
Comment 4 simonbr 2003-05-31 19:26:37 UTC
Hi Volker, 

I just ran "build" inside the odk subdirectory, and it finished 
without errors, so I would say yes, the patch fixes the problem. 

I have not seen the build stop in other modules when rebuilding. 

My compliments on the excellent Win32-tcsh build environment! 
Comment 5 Martin Hollmichel 2003-06-02 10:25:32 UTC
reassign
Comment 6 jsc 2003-06-03 15:18:52 UTC
i used the WRAPCMD command in cws sdk02. Fixed in RC.
Comment 7 quetschke 2003-06-03 16:24:42 UTC
Sorry to reopen the issue, I'm sure that the WRAPCMD was not
the needed fix, I just inserted it in my patch because it would cure
problems if $(ZIPFILE) or $(ZIPDIR) might contain pathes with DOSish
drive letters. So it's correct to use it there, but most probably not
needed.

I just verified that when you do something like:
----
$ zip -urq zip_urq testdir

$ ls --full-time zip_urq.zip 
-rw-rw-r--    1 q        none      9387651 Tue Jun 03 17:19:28 2003
zip_urq.zip

$ zip -urq zip_urq testdir

$ ls --full-time zip_urq.zip 
-rw-rw-r--    1 q        none      9387651 Tue Jun 03 17:19:28 2003
zip_urq.zip
---
the timestamp doesn't change, and therefore dmake fails.
The timestamp only changes if something changes in your $(ZIPDIR).

So, I think the touch is needed, but the $(WRAPCMD) should also stay.

Volker
Comment 8 jsc 2003-06-05 14:02:32 UTC
I don't like this solution because if nothing changed the old date is
ok because in future a new project sdk_oo depends on the porject and
if we touch the zip file the sdk_oo project will always be build even
if nothing has changed.
I changed the target back to OOo2.0 because this will increase the
build time and we should find another solution.
Comment 9 quetschke 2003-06-05 16:00:08 UTC
Hi Jürgen,
> I changed the target back to OOo2.0 because this will increase the
> build time and we should find another solution.
OK.

I suspect the "real" problem is that cygwin is has a feature that
"normal" w32 applications don't have.

Files created by applications linked against cygwin1.dll create
timestamps with even and odd seconds in the filetime.

Native windows applications only create even seconds.

I get bitten by this all the time when re-compiling projects which
use the ALLTAR macro. (I have a local patch for this, just wait 2
seconds at the right position)

If we sometime remove the cygwin b20 compatibility and only use
new-cygwin tools, this is easy to fix with the sleep command, even
for 4NT builds. ( I don't know if 4nt build have this problem )

If for OOo2.0 we require the new cygwin, the patch will be easy,
I guess a sleep 2 in front of the zip will be the cure.
(Only if two extra seconds, out of 10 hours don't matter ;-) )

CCing ause, just FYI
Comment 10 quetschke 2003-06-05 16:12:02 UTC
Hmm, maybe the sleep 2 has to go after the zip command.
Comment 11 quetschke 2003-07-13 07:57:08 UTC
*** Issue 16762 has been marked as a duplicate of this issue. ***
Comment 12 quetschke 2003-07-13 14:19:16 UTC
Hi Juergen, I had a new look at the problem.

It's not the timestamp problem I described before,
> Files created by applications linked against cygwin1.dll create
> timestamps with even and odd seconds in the filetime.
but just a bug in the makefile or zip.

man zip says: (exit code for zip)
     12     zip has nothing to do
Therefore dmake fails with an error when zip has nothing to update.

So, applying the following patch fixes the problem:

+++ odk/util/makefile.mk        13 Jul 2003 13:06:20 -0000
@@ -21,7 +21,7 @@
 
 
 $(BIN)$/$(ZIPFILE) .SETDIR=$(DESTDIR)$/.. .PHONY:
-       +$(WRAPCMD) zip -urq $(ZIPFILE) $(ZIPDIR)
+       +-$(WRAPCMD) zip -urq $(ZIPFILE) $(ZIPDIR)
 
 $(BIN)$/$(TARGZFILE) .SETDIR=$(DESTDIR)$/.. .PHONY:

I retarget this to 1.1RC.

OK for cws...rc2 ?

P.S.: I get exit level 3072 instead of 12 for cygwins zip, but that
      is an other error ;-) The fix is the same.
Comment 13 kay.ramme 2003-07-14 09:54:48 UTC
Michael, please take care of this.
Comment 14 ooo 2003-07-16 10:28:11 UTC
I introduced your patch into cws:ooo11rc2
Comment 15 Martin Hollmichel 2003-07-16 16:16:57 UTC
verified.
Comment 16 ooo 2003-08-25 10:42:03 UTC
closing