Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | jpeg project detects previously applied patch on re-running dmake | ||||||
---|---|---|---|---|---|---|---|
Product: | Build Tools | Reporter: | simonbr | ||||
Component: | code | Assignee: | hjs <hans-joachim.lankenau> | ||||
Status: | CLOSED FIXED | QA Contact: | issues@tools <issues> | ||||
Severity: | Trivial | ||||||
Priority: | P3 | CC: | hans-joachim.lankenau, issues, quetschke | ||||
Version: | OOo 1.1 RC3 | ||||||
Target Milestone: | OOo 2.0 | ||||||
Hardware: | PC | ||||||
OS: | Windows XP | ||||||
Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||
Developer Difficulty: | --- | ||||||
Attachments: |
|
Description
simonbr
2003-08-23 10:39:39 UTC
Also: ============= Building project np_sdk ============= /cygdrive/g/oo_11rc3_src/np_sdk ------------- cd ./wntmsci9.pro/misc/build && cat ../../../mozilla-source-M16- stub.patch | tr -d "\015" | patch -b -p2 && /usr/bin/touch.exe so_patched_npsdk patching file mozilla/include/npapi.h Reversed (or previously applied) patch detected! Assume -R? [n] Also: ============= Building project zlib ============= /cygdrive/g/oo_11rc3_src/zlib ------------- cd ./wntmsci9.pro/misc/build && cat ../../../zlib-1.1.4.patch | tr - d "\015" | p atch -b -p2 && /usr/bin/touch.exe so_patched_zlib patching file zlib-1.1.4/contrib/minizip/unzip.h Reversed (or previously applied) patch detected! Assume -R? [n] Thanks! I'm not the only one who is getting this! jpeg is not the only project which sees this problem from time to time. I also saw it in: zlib, icu, expat, neon, jpeg or sablot I guess, the reason is that you/me somehow mix FAT32 / NTFS filesystems. (The comment in the following patch is WRONG) FAT32 only stores even seconds in its timestamps, and might be wrong to max. 2 seconds. My TEMP is located on a FAT32 drive, my sources on NTFS and I also got the same problem. I don't get it anymore because I always use the attached patch. Attention, the following patch propably doesn't work for ancient cygwin b2x installations. (Still used in Hamburg?) Created attachment 8690 [details]
Patch for the rebuild problem
Yes, my source tree is on NTFS disk G: and my C: disk is FAT32. I don't have too much experience with patch, how do I apply it? In your OOo source directory just do a: $ patch -p0 < rebuildprob.diff You can always first try: $ patch --dry-run -p0 < rebuildprob.diff to see if the patch applies without problems. Unfortunately this patch will only help if it already is applied when doing the first build of a project. But then you can rebuild as often as you like. ;-) I pointed the TEMP and TMP env variables to a directory on my NTFS disk; that also appears to help. I suspect this solved another problem (issue 18562) for me too. Suggested solutions: - implement Volkers patch in the source code, or - add a warning in the build guide not to have source and temp directories on different file systems additional 4 seconds per external module should be bearable if they avoid annoing re-patch failurs. if there is a general problem when using temp (fat32) and source (NTFS) it should be notice in the build guides anyway as it may also hit in other places. btw.: i put the target to OOo 2.0 but would also second a change to OOo 1.1.1 if desired... I'm not sure about the status of this issue, ause can you please enlighten me ? fixed dependency for additional files @vq: cannot reach you by mail. please check if the delay/speep is still required at all with the dependency changes made in "ause011". It is! I'm building m53, sources on NTFS, $TEMP and $TMP pointing to FAT32. Second build: $ build build -- version: 1.115 /w1/SRC680_m53/jpeg ------------- cd ./wntmsci10.pro/misc/build && cat ../../../jpeg-6b.patch | tr -d "\015" | patch -b -p2 && /bin/touch.exe so_patched_jpeg patching file jpeg-6b/jconfig.h Reversed (or previously applied) patch detected! Assume -R? [n] Argh! Sorry I didn't read carefully enough.
> @vq: cannot reach you by mail. please check if the delay/speep is still
> required at all with the dependency changes made in "ause011".
I didn't use ause011, but slightly patched m53. Is it enough to use tg_ext.mk
from ause011 ?
> Is it enough to use tg_ext.mk from ause011 ?
No, beside the problem that delay doesn't fly here, it still wants to repatch.
ok, now try this :-) new tg_ext.mk and unitools.mk Ok, with the new files it works. A nit: --- snip --- Making: ./wntmsci10.pro/misc/jpeg.dpc dmake subdmake=true -f makefile.mk depend=t ALLDPC ------------------------------ No Dependencies ------------- mv ./wntmsci10.pro/misc/build ./wntmsci10.pro/misc/build/jpeg-6b_removeme mv: cannot stat `./wntmsci10.pro/misc/build': No such file or directory rm -rf ./wntmsci10.pro/misc/build/jpeg-6b_removeme --- snap --- This comes from the "#untar" part of tg_ext.mk: +-$(RENAME) $(PACKAGE_DIR) $(PACKAGE_DIR)$/$(TARFILE_ROOTDIR)_removeme +-rm -rf $(PACKAGE_DIR)$/$(TARFILE_ROOTDIR)_removeme that looks a bit strange to me. Why first mv and then rm? And secondly why not add ">& $(NULLDEV)" to silence it? "rm -rf" on a path that consists of "$(VAR1)$/$(VAR2)" can be ugly when both are not set for any reason ;-) fixed again to get the CWS integrated see last comments by vq . |