[dev] Re: build.pl debug=1 for sw and svx
On 08.04.2011 11:19, Michael Stahl wrote: On 07/04/2011 10:05, Mathias Bauer wrote: On 06.04.2011 19:47, Michael Stahl wrote: 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... :( If in this case means: if there are generated headers, this is true. no, i mean for ordinary headers that are just copied. (that generated headers cause rebuild is really obvious...) for headers that are just copied, GNU make will consider the target in the outdir outdated, because, well, it doesn't exist, and will copy the header to the outdir. Ah, I see. I just overlooked that you talked about build after make clean. Sorry. of course the right question here is, why the hell are we copying all those headers? it seems pointless to me: they could just as well be included from the source directory instead of from the solver. I agree. OTOH this would be a huge change. The current way we include our headers from outside the current module assumes that they reside in a common root folder. If we took them from their location in the source directory, we either had to move all currently delivered header files into a common source directory or we had to change all include statements (e.g. from #include sfx2/objsh.hxx to #include sfx2/inc/sfx2/objsh.hxx. The third option to add all modules to the INCLUDE path is a no-go for performance reasons. There is a fourth, somewhat pragmatic option: add a second clean target that does't remove headers that are only copied but not generated. For those who now start to think that the rebuild caused by a make clean is a bug in the new build system: that's not true. The bug is that we copy header files in the build instead of using them where they are. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS Please don't reply to nospamfor...@gmx.de. I use it for the OOo lists and only rarely read other mails sent to it. -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: build.pl debug=1 for sw and svx
On 06.04.2011 19:47, Michael Stahl wrote: 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... :( If in this case means: if there are generated headers, this is true. And IMHO it's the only way a sane build system should work. A build system that relies on manual evaluation of dependencies by developers (as the build.pl/dmake combo) is insane. Dependency evaluation is what make tools and files are made for. In case of svx/sw the generated header files svxslots.hxx and globlmn.hrc cause some rebuilds in sw. Perhaps this is a good starting point to think about better dependencies. Files like these and the way we are using them are annoying. We can do better. globlmn.hrc is doomed once we get the work to get rid of context menu resource files finished. In case we moved all slot files into a single module and build them only if sdi files have changed, the second problem would be solved also. This would treat sdi files pretty much like idl files. The number one reason why changing header files causes too much rebuilds is that our classes and thus our header files are too large (so that including only what you need doesn't work), that we have still too much nested includes and that superfluous includes in source files rarely get removed. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS Please don't reply to nospamfor...@gmx.de. I use it for the OOo lists and only rarely read other mails sent to it. -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: build.pl debug=1 for sw and svx
On 07/04/2011 10:05, Mathias Bauer wrote: On 06.04.2011 19:47, Michael Stahl wrote: 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... :( If in this case means: if there are generated headers, this is true. no, i mean for ordinary headers that are just copied. (that generated headers cause rebuild is really obvious...) for headers that are just copied, GNU make will consider the target in the outdir outdated, because, well, it doesn't exist, and will copy the header to the outdir. all targets that depend on the header will then be rebuilt, because their prerequisite (the delivered header) has been rebuilt. when using the top-level makefile, this includes cxx files in other modules. currently we are using build.pl invoke GNU make once per module. in this case, cxx files in dependent modules will _not_ be rebuilt, because the check whether to rebuild the cxx file is done by a _different_ GNU make process than the one which copies the header. the second make process will just check the timestamps of the header and object file, and we use cp --preserve=timestamp so these are the same as the source file and thus the same as when you built the dependent module the first time. of course the right question here is, why the hell are we copying all those headers? it seems pointless to me: they could just as well be included from the source directory instead of from the solver. And IMHO it's the only way a sane build system should work. A build system that relies on manual evaluation of dependencies by developers (as the build.pl/dmake combo) is insane. Dependency evaluation is what make tools and files are made for. In case of svx/sw the generated header files svxslots.hxx and globlmn.hrc cause some rebuilds in sw. Perhaps this is a good starting point to think about better dependencies. Files like these and the way we are using them are annoying. We can do better. globlmn.hrc is doomed once we get the work to get rid of context menu resource files finished. In case we moved all slot files into a single module and build them only if sdi files have changed, the second problem would be solved also. This would treat sdi files pretty much like idl files. The number one reason why changing header files causes too much rebuilds is that our classes and thus our header files are too large (so that including only what you need doesn't work), that we have still too much nested includes and that superfluous includes in source files rarely get removed. this is of course true :) Regards, Mathias -- Religion is the ultimate hubris of man. -- Hillgiant -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: build.pl debug=1 for sw and svx
Hi, Am 06.04.2011 08:54, schrieb tora - Takamichi Akiyama: Could you tell me how to easily do build.pl debug=1 or similar actions in a specific, renovated module such as sw and svx after fully building the entire source code tree with normal options? The way I used to do was like this: (full build) cd $SRC_ROOT dmake (individual build with a debug option) cd sw cd sw make clean make -srj9 debug=t The first call of make removes all output files of sw from solver/workdir. The second call of make builds sw with debug, libraries go into solver/workdir/LinkTarget/Library. j9 builds with 9 processes in parallel. Regards Daniel -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: build.pl debug=1 for sw and svx
On 06.04.2011 08:54, tora - Takamichi Akiyama wrote:
Could you tell me how to easily do build.pl debug=1 or similar
actions in a specific, renovated module such as sw and svx after
fully building the entire source code tree with normal options?
The way I used to do was like this:
(full build)
cd $SRC_ROOT
dmake
(individual build with a debug option)
cd sw
mv $INPATH ${INPATH}-normal
build.pl debug=1
An attempt like that seems no longer applicable with the recent
DEV300_m10x.
It seems files being created are now stored in solver/, instead.
It is cool and makes me excited. :-)
To rebuild a single module with debug info in the new build system, use
cd sw
make -sr clean
make -sr debug=t
See also http://blogs.sun.com/GullFOSS/entry/gbuild_meet_the_new_boss.
Niklas
--
-
To unsubscribe send email to dev-unsubscr...@openoffice.org
For additional commands send email to sy...@openoffice.org
with Subject: help
[dev] Re: build.pl debug=1 for sw and svx
Hi Niklas, Daniel, and everybody interested in, On 2011/04/06 17:22, Daniel Rentz wrote: cd sw make clean make -srj9 debug=t The first call of make removes all output files of sw from solver/workdir. The second call of make builds sw with debug, libraries go into solver/workdir/LinkTarget/Library. j9 builds with 9 processes in parallel. On 2011/04/06 17:24, Niklas Nebel wrote: To rebuild a single module with debug info in the new build system, use cd sw make -sr clean make -sr debug=t See also http://blogs.sun.com/GullFOSS/entry/gbuild_meet_the_new_boss. Thanks a lot. It works very well. Additionally, gbuild: Meet the new boss (Same as the old boss) gives me a hot spice. Here is my appreciation for developers who intend to keep every log: bash$ mkdir log $ cd sw $ x=make -sr debug=t; (/bin/pwd; date; echo $x; echo; time $x; date) ../log/build_sw_`date +%Y%m%d_%H%M`.log 21 $ head `ls -t ../log/build_sw_*log | head -1` /xxx/ooo/build/local/DEV300/DEV300_m106/sw Wed Apr 6 18:10:58 JST 2011 make -sr debug=t ... $ tail -f `ls -t ../log/build_sw_*log | head -1` ... Best regards, Tora -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: build.pl debug=1 for sw and svx
Hi Tora, Am 06.04.2011 11:31, schrieb tora - Takamichi Akiyama: Hi Niklas, Daniel, and everybody interested in, On 2011/04/06 17:22, Daniel Rentz wrote: cd sw make clean make -srj9 debug=t The first call of make removes all output files of sw from solver/workdir. The second call of make builds sw with debug, libraries go into solver/workdir/LinkTarget/Library. j9 builds with 9 processes in parallel. On 2011/04/06 17:24, Niklas Nebel wrote: To rebuild a single module with debug info in the new build system, use cd sw make -sr clean make -sr debug=t See also http://blogs.sun.com/GullFOSS/entry/gbuild_meet_the_new_boss. Thanks a lot. It works very well. 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. 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. Regards, Christian -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: build.pl debug=1 for sw and svx
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. 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. 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 delivered 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. 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 `/x/solver/300/unxsoli4/inc/svx/sxsoitm.hxx' has a high resolution time stamp ...(repeated 2 by 500 times for each file)... 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??? $ 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 ... 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 -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: build.pl debug=1 for sw and svx
On 06.04.2011 18:45, tora - Takamichi Akiyama wrote: 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 `/x/solver/300/unxsoli4/inc/svx/sxsoitm.hxx' has a high resolution time stamp ...(repeated 2 by 500 times for each file)... 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??? Is it really copied again? The whole point of .LOW_RESOLUTION_TIME is to ignore these small differences (see http://www.gnu.org/software/make/manual/html_node/Special-Targets.html and http://wiki.services.openoffice.org/wiki/Build_Environment_Effort/Status_And_Next_Steps). Niklas -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: build.pl debug=1 for sw and svx
Hello Niklas, On 2011/04/07 2:04, Niklas Nebel wrote: On 06.04.2011 18:45, tora - Takamichi Akiyama wrote: 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 `/x/solver/300/unxsoli4/inc/svx/sxsoitm.hxx' has a high resolution time stamp ...(repeated 2 by 500 times for each file)... 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??? Is it really copied again? The whole point of .LOW_RESOLUTION_TIME is to ignore these small differences (see http://www.gnu.org/software/make/manual/html_node/Special-Targets.html and http://wiki.services.openoffice.org/wiki/Build_Environment_Effort/Status_And_Next_Steps). Thank you for the resources. Those explain exactly what I am encountering. The build environment I am using is running in a Solaris Zone on raidz2 ZFS with 6 disk devices as well as 2 disk devices configured as a ZFS mirror for boot disk. According to the log file of make -sr debug=t after running cd svx; make -r clean, the header files under $OUTDIR seemed to be re-created at the very beginning of make -sr, e.g. 00:12:16.643938904 -- not in the process of make -r deliverlog -- and then a time stamp was tried to adjust to the original one, but unfortunately its resolution seemed lost during cp -p, fstat(), or things like that in case of OpenSolaris x86. $ head log/build_svx_20110407_0012.log /wb/ooo/build/local/DEV300/DEV300_m100/svx Thu Apr 7 00:12:16 JST 2011 make -sr debug=t [ build PKG ] svx_inc [ build PKG ] svx_sdi [ build SDI ] svx/sdi/svxslots [ build DEP ] LNK:Library/libsvxsi.so [ build DEP ] LNK:Library/libsvxcoresi.so [ build DEP ] LNK:Library/libtextconversiondlgssi.so $ stat svx/inc/svx/sxsoitm.hxx ... Access: 2011-02-22 20:59:42.717435880 +0900 Modify: 2011-02-22 20:59:42.717474450 +0900 Change: 2011-02-22 20:59:42.717474450 +0900 $ stat $OUTDIR/inc/svx/sxsoitm.hxx ... Access: 2011-02-22 20:59:42.717435000 +0900 Modify: 2011-02-22 20:59:42.717474000 +0900 Change: 2011-04-07 00:12:16.643938904 +0900 But I am not sure, though. Best regards, Tora -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: build.pl debug=1 for sw and svx
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 delivered 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 `/x/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
[dev] Re: build.pl debug=1 for sw and svx
Hi Michael,
On 2011/04/07 2:47, Michael Stahl wrote:
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
`/x/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 :)
Good!
$ 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.
I've just tried it and learned that unfortunately, version 6.7 of /usr/gnu/bin/cp
-p truncates nanosecond part during copying a file.
you can set the GNUCOPY variable, or rebase to m106 where configure should
find it automatically.
Surfing in the Internet, I have devised a silly, pragmatic workaround.
1. Truncate sub-second part of all files in the module svx:
$ find svx -type f | xargs perl -e 'map{ $t=(stat($_))[9]; utime($t,$t,$_) }
@ARGV'
$ stat svx/inc/svx/sxsoitm.hxx
...
Access: 2011-02-22 20:59:42.0 +0900
Modify: 2011-02-22 20:59:42.0 +0900
Change: 2011-04-07 03:58:23.672122611 +0900
2. Do the same thing on the target files, just one time:
$ find $OUTDIR/inc/svx -type f | xargs perl -e 'map{ $t=(stat($_))[9];
utime($t,$t,$_) } @ARGV'
3. Give it a try:
$ make -sr deliverlog
[ build LOG ] svx
Yahh, make abandons complaining about .LOW_RESOLUTION_TIME.
That is, I know, just for fun. :-)
Best regards,
Tora
--
-
To unsubscribe send email to dev-unsubscr...@openoffice.org
For additional commands send email to sy...@openoffice.org
with Subject: help
[dev] Re: build.pl debug=1 for sw and svx
Hi, What I have learned: To compile an individual module including debug information, do like this: cd svx make -sr clean make -srj9 debug=t or cd svx rm -fr $WORKDIR/CxxObject/svx make -srj9 debug=t A warning message about .LOW_RESOLUTION_TIME on OpenSolaris with ZFS or NFS seems not harmful. It might be solved by re-compiling or slightly tweaking source code of cp command. ls command on OpenSolaris is aware of nanoseconds. $ echo x $ ls -l x -rw-r--r-- 1 tora users 1 Apr 7 10:32 x $ ls -E x -rw-r--r-- 1 tora users 1 2011-04-07 10:32:52.028730567 +0900 x Source codes are available at http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libcmd/common/cp.c http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/touch/touch.c http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/ls/ls.c hg clone ssh://a...@hg.opensolaris.org/hg/onnv/onnv-gate Resources: http://blogs.sun.com/GullFOSS/entry/gbuild_meet_the_new_boss http://www.gnu.org/software/make/manual/html_node/Special-Targets.html http://wiki.services.openoffice.org/wiki/Build_Environment_Effort/Status_And_Next_Steps Best regards, Tora -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
