Apache OpenOffice (AOO) Bugzilla – Issue 22030
Check for the correct dmake version
Last modified: 2006-03-14 21:02:56 UTC
As discussed here: <http://porting.openoffice.org/servlets/ReadMsg?msgId=911436&listName=dev> Slight changes for dmake/ and config_office/ are needed.
Created attachment 10889 [details] Patch for config_office and dmake
Set target to 1.1.1 vq->ause: "del /FY objects" is 4nt syntax, is this OK for dmake/win95/microsft/vpp40/mk.bat?
MIght be better if you issue a make distclean (or dist-clean) in the dmake directory. This will purge everything to ensure a clean build (like config.h for example). All you have to do is run this and ignore errors or check for a Makefile and then run it.
I thought about the make distclean, but when you build dmake with winenv.bat (4nt) then you don't get a Makefile created and you can't do a distclean on the unixy targets. Propably we should do both, rm objects make disclean .
"del /FY" is ok for me as for "dos-like" builds we require a 4nt shell anyway.
OK, first of all I withdraw the suggestion of different output trees for *-tcsh and *-4nt. This is not useful as the output trees are independent of the used build system (tcsh vs. 4nt) with one tiny exception: dmake and therefore also: $SOLARENV/$OUTPATH/bin/dmake.exe This is managable without two trees, I change the summary to the new situation. I checked for files in dmake that are created during building dmake depending on the used system: Build with 4NT (dmake/win95/microsft/vpp40/mk.bat): dmake/dmake.exe dmake/objects/* dmake/startup/config.mk Build unixy style with configure: dmake/.deps dmake/Makefile dmake/config.h dmake/config.log dmake/config.status dmake/dag.o dmake/dmake.exe dmake/dmake.o dmake/dmakeroot.h dmake/dmdump.o dmake/dmstring.o dmake/expand.o dmake/function.o dmake/getinp.o dmake/hash.o dmake/imacs.o dmake/infer.o dmake/macparse.o dmake/make.o dmake/parse.o dmake/path.o dmake/percent.o dmake/quit.o dmake/rulparse.o dmake/stamp-h1 dmake/stat.o dmake/state.o dmake/sysintf.o dmake/msdos/.deps dmake/msdos/Makefile dmake/startup/Makefile dmake/startup/unix/Makefile dmake/startup/unix/cygwin/Makefile dmake/startup/unix/linux/Makefile dmake/startup/unix/macosx/Makefile dmake/startup/unix/solaris/Makefile dmake/startup/unix/sysvr4/Makefile dmake/startup/winnt/Makefile dmake/startup/winnt/mingw/Makefile dmake/startup/winnt/msvc6/Makefile dmake/unix/.deps dmake/unix/Makefile dmake/unix/arlib.o dmake/unix/dcache.o dmake/unix/dirbrk.o dmake/unix/libunix.a dmake/unix/rmprq.o dmake/unix/ruletab.o dmake/unix/runargv.o dmake/unix/tempnam.o dmake/win95/.deps dmake/win95/Makefile dmake/win95/microsft/.deps dmake/win95/microsft/Makefile This shows that the configure type build doesn't interfere with the 4nt build very much, ignore startup/config.mk as we use $DMAKEROOT, we only have to remove the two *.h to build dmake-4nt successfully. The configure build needs a make distclean (only when dmake/Makefile exists) I'll prepare new patches, ignore the old one.
Created attachment 11129 [details] New patch
I'll commit config_dmake2.diff shortly.
done
utomo> vq: Done is same as fixed ? (because you never change to started yet) if yes, you forget to change the status. please change it. Thanks
Done means committed that patch, this is only a part of the complete solution. I'll do the rest soon.
Hmmm, to check if the correct dmake is used, one can use this commandline for bash: if test "`dmake.exe -V | $AWK '/cygwin/ { print \"yes\" }'`" != "yes" ; then echo "Error! You're using the wrong dmake.exe"; fi It assumes that a dmake is there, no test for missing file, but this is IMHO ok. My problem is: Where to put it? And I have another problem, what to do in the 4NT case? vq->ause: Suggestions?
maybe "setsoenv" could push these lines to the generated script to setup the environment. IIRC, this script is called after bootstrap, so "dmake.exe" should exist.
setting to fixed since already committed.
vq->mh: I reopen the issue because it wasn't finished yet. I still have to put the check for the dmake somewhere. My build systems are running again since a few hours here but I will need some time to work on this. Setting target to 1.1.2
utomo > Vq: Just reminder, OOo 1.1.2 almost ready. do you have new patch ? Thanks ------- Additional comments from vq Tue Dec 9 06:56:27 -0700 2003 ------- vq->mh: I reopen the issue because it wasn't finished yet. I still have to put the check for the dmake somewhere. My build systems are running again since a few hours here but I will need some time to work on this. Setting target to 1.1.2
Retargeted. IMHO a very low priority.
retarget to 1.1.5
issue 58709 shows that a better check for the used dmake version is needed. Not only for W32-tcsh vs. W32-4nt but generally if dmake is new enough.
Created attachment 32508 [details] Patch to check the version of the used dmake
Created attachment 32509 [details] Patch to check cygwin vs. native build dmake
Committed to CWS vq25.
@ause: Please verify.
this check will instantly stop all builds in hamburg env. (still stuck with 4.1). .IF $(MAKEVERSION:s/-cvs//:s/.//:s/410/41/)>=43 IRC, 4.3 isn't as critical as 4.3-cvs regarding oooold makefiles, but until environment restructuring (versioned tools set) took place, it would be a huge effort to verify this. also the previous check .IF 400<=200 [do fail] indicates that dmake versions not being able to do comparison would treat the new test as TRUE - didn't check yet
> this check will instantly stop all builds in hamburg env. (still stuck > with 4.1). Erm, 1.9.x and newer ships with 4.3! .IF $(MAKEVERSION:s/-cvs//:s/.//:s/410/41/)>=43 > IRC, 4.3 isn't as critical as 4.3-cvs regarding oooold makefiles, but until > environment restructuring (versioned tools set) took place, it would be a > huge effort to verify this. Hmm, I thought I kept it compatible. Only warnings, no errors, so dmake43 should be a drop in replacement > also the previous check > > .IF 400<=200 > [do fail] > > indicates that dmake versions not being able to do comparison would treat the > new test as TRUE - didn't check yet Yep, my fault. I had it right the first time (not attached here) when I used <= 42, but I didn't like that. ;) Is easily fixed.
Fixed the last point in vq25. I see your problem with only one dmake for all development trees, but as issue 58709 shows there is already perfectly valid code in our sourcebase that leads to errors when a *buggy* dmake 4.10 version is used. We need somethink like this patch to check for dmake versions. OOo currently "delivers" (when bootstrap is used) the newly build dmake to $SOLARENV/$OUTPATH/bin/ or when dmake is found in the path lets configure check if it is version 4.3 or newer. I understand that you cannot deliver to solenv, but something similar sounds easy to implement for the Hamburg environment if something (maybe even build.pl) copies one of the needed dmake versions to some place in solver that is available only in the search path of the architecture that is currently build. We're only talking about two dmake versions so far, the old 4.10 or the current 4.3 from OOo 2.0. If this scheme is established one might even start to use dmake 4.4 from dmake43p01. I understand this takes time so I will propably back out the version checking part of the patch to get the rest of the CWS integrated but we should think about getting this fixed.
rt came up with the idea of supplying the required version in a variable set by configure/setsolar. this would allow to do the checking based on the used environment. this sounds like a workaround for the 2.x codeline until we solve our problem with the shared (stoneage) dmake here.
> rt came up with the idea of supplying the required version in a variable set by > configure/setsolar. this would allow to do the checking based on the used > environment. So you want to set something like DMAKEMINVER=40 (setsolar) or =42 (*env.set) Ugly ;) > this sounds like a workaround for the 2.x codeline until we solve our problem > with the shared (stoneage) dmake here. Why not just define FORCEDMAKEEXECUTABLE=/<something you know better than>/dmake43 in setsolar and place something like this in setsolar.pl (or build.pl): if( ! -x $ENV{SOLARVER}/$ENV{SOLARUPD}/$ENV{INPATH}/bin/dmake ) { `cp $FORCEDMAKEEXECUTABLE/dmake $ENV{SOLARVER}/$ENV{SOLARUPD}/$ENV{INPATH}/bin/` Pseudocode, you know what I mean.
I reverted the code that checks for the correct dmake version. I will open a new issue for this which can be integrated once the handling of the dmake version is a little more flexible in Hamburg ;) The rest should be OK as it's config_office only. @ause: please verify.
fine with me
closed