On 06/04/2011 18:45, tora - Takamichi Akiyama wrote: > Hello Christian, > > On 2011/04/06 20:55, Christian Lippka wrote: >> While Niklas and Daniel are absolutely right, make clean may not always >> be what you want. >> >> For example, if you just want to rebuild svx with debug and do a >> make -sr clean, your next make in sw module would rebuild a lot of >> stuff, since all dependency to svx would fire.
actually, for a module like svx it shouldn't rebuild any cxx files in dependent modules (which takes up most of the time), because gbuild will preserve the timestamp of the original file when delivering. of course if headers are *generated*, then dependent cxx files will be rebuilt. hmm... on second thought, if you actually use the top-level makefile, then probably the cxx files will be rebuilt in this case... :( > I see. > >> If you only want to rebuild all obj files with debug, what you can >> do is >> >> rm -fr $WORKDIR/CxxObject/svx >> make -srj9 debug=t >> >> a lot faster and also modules depending on svx will not need >> a nearly full rebuild. this should of course work and is sufficient for a debug re-build. > That makes sense. I gave it a try following your suggestion. > It took only 15 minutes to re-make svx with debug=t while 16 minutes to > entirely re-make svx which involved resource files for both en_US and ja. > Yes, you are right, it's faster! For dependency across modules, I am being > confused with the following unexpected phenomena. > > Despite my expectation, libsvxsi.so has been "deliver"ed into $OUTDIR/lib/ > without explicitly executing "deliver.pl" > In addition to .so, Package_inc.mk seems to physically copy header files from > svx/inc/svx/ to $OUTDIR/inc/svx/. > $OUTDIR/inc/svx/deliver.log seems to be substituted with gb_deliver.log. yes, gbuild migrated modules do not use deliver.pl, because gbuild itself copies files to the solver/outdir. > make -r deliverlog running on OpenSolaris x86 prints same type of warning > messages and then eventually create the log file. > > $ make -r deliverlog > ... > make: *** Warning: .LOW_RESOLUTION_TIME file > `/xxxxx/solver/300/unxsoli4/inc/svx/sxsoitm.hxx' has a high resolution time > stamp > ...(repeated 2 by 500 times for each file)... yes, this warning is a well-known problem. > On OpenSolaris x86, even after executing "make -sr && make -r deliverlog," > the "delivered" file under $OUTDIR is slightly older (in nanoseconds) than > its original one. Consequently, copy action might occur again and again. > Should I use /usr/gnu/bin/cp instead of /bin/cp, or else??? btw, in DEV300m106 configure will now find /usr/gnu/bin/cp on Solaris, and use it :) > $ stat $OUTDIR/inc/svx/sxsoitm.hxx > ... > Modify: 2011-02-22 20:59:42.717474000 +0900 > ... > > $ stat svx/inc/svx/sxsoitm.hxx > ... > Modify: 2011-02-22 20:59:42.717474450 +0900 > ... that is exactly the problem that is solved by using the .LOW_RESOLUTION_TIME directive in the rules in Deliver.mk. ZFS has nano-second precision timestamps. as mentioned above, when copying files to the solver, gbuild preserves the timestamp of the source files, to prevent rebuilds in dependent modules. this is done using --preserve=timestamp option of GNU cp if it is available, and touch -r otherwise (such as in your case probably). unfortunately older versions of GNU cp, as well as Solaris 10 touch, only support micro-second precision timestamps. the result is that on every make invocation the files will be copied again, which is bad. to work around this, GNU make provides the .LOW_RESOLUTION_TIME option, which does not check the sub-second part of the timestamp. however, because the timestamps do have a sub-second part that is not zero, GNU make produces this annoying warning, and unfortunately there seems to be no way to turn it off. i haven't checked yet, but if the GNU cp in OpenSolaris can actually copy nano-second timestamps properly, then you can set the gb_HIRESTIME variable, so the .LOW_RESOLUTION_TIME is not used and the warnings go away. you can set the GNUCOPY variable, or rebase to m106 where configure should find it automatically. > Anyway, things that I am facing are really fresh for me. > I have hit the road to explore the new, wonderful world, solenv/gbuild/ :-) > > Thanks a lot, cheers! > Tora -- "The greatest dangers to liberty lurk in the insidious encroachment by men of zeal, well-meaning but without understanding." -- Louis D. Brandeis -- ----------------------------------------------------------------- To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
