[dev] Re: does anybody still use tcsh to build OOo?
Hi, AFAIK tcsh doesn't work anymore anyway - at least it's not supported anymore. I think that the only reason that we still create two scripts is that nobody was annoyed enough to remove the code doing this. :-) Months ago I worked on that but then got in serious merge conflicts as somebody else did some refactoring in configure.in. So I just abandoned that work. AFAIR the fix was quite annoying work as the generation of the scripts is scattered over the code. Regards, Mathias On 05.04.2011 13:48, Malte Timmermann wrote: I guess it shouldn't make a big difference for anyone whether he uses bash or tcsh for building OOo, so killing tcsh support is fine, IMO. Malte. Michael Stahl wrote, On 05.04.2011 13:04: hi all, currently configure generates 2 shell scripts for the environment, one for Bourne shell and one for tcsh. the tcsh file is known to ... annoy people. would anybody complain if the tcsh file were gone? -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help -- 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] java programmer
Hi I would like to contribute to OO by providing java programming skills. This is my first time with Open office so let me know where I can get started . Thanks Arjuna -- - 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: gnu make .LOW_RESOLUTION_TIME
On 07/04/2011 05:03, tora - Takamichi Akiyama wrote: Sorry again, I have just come up with a quick solution for the file systems using nanosecond time stamps. Problem: make: *** Warning: .LOW_RESOLUTION_TIME file `/x/solver/300/unxsoli4/inc/svx/sxsoitm.hxx' has a high resolution time stamp Cause: cp -p does not preserve a nanosecond part of time stamp. i've just checked on Solaris 11 express: both /usr/gnu/bin/cp [cp (GNU coreutils) 8.5] and /usr/bin/touch -r seem to support nano-second timestamps. Possible Solution: touch itself before cp -p to loose a nanosecond part of its time stamp. hmmm... this could work around the problem, but kind of interferes with our goal of a read-only source directory :) perhaps just installing new GNU coreutils on systems where this problem occurs is the way to go... -- Never attribute to conspiracy that which can be adequately explained by economics. -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: does anybody still use tcsh to build OOo?
On Thu, Apr 7, 2011 at 9:47 AM, Mathias Bauer nospamfor...@gmx.de wrote: Hi, AFAIK tcsh doesn't work anymore anyway - using tcsh as the shell used *by* the build: yes. But the environment files are for the user's shell, and there it would still work. Months ago I worked on that but then got in serious merge conflicts as somebody else did some refactoring in configure.in. So I just abandoned that work. AFAIR the fix was quite annoying work as the generation of the scripts is scattered over the code. configure has nothing to do with it, as it is generated by set_soenv[.in] ciao Christian -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] MacOSX+OOo3.3: loading a library via Java' System.loadLibrary(...)
Hi there, currently debugging a scripting language added to OOo 3.3 via an oxt-extension. The integration into OOo is done using the OOo beanshell programs, but adapted to the scripting language. The scripting language is ooRexx and there is a library that needs to be loaded via Java (using System.loadLibrary(BSF4ooRexx), which on MacOSX is named libBSF4ooRexx.dylib and located in /usr/lib and /usr/lib/java. Now the odd behaviour: 1. If using Tools - Macros - Organize Macros - Edit and running the script off the edit-window, everything works fine. The BSF4ooRexx library is found and used to run the script via the ooRexx interpreter. After doing this once one can execute any ooRexx macro by merely having it run, i.e. Too.ls - Macros - Run or Tools - Macros - Organize Macros - Run. 2. If all instances of OOo have been shut down, and then the same ooRexx script gets executed via Tools - Macros - Run, then an exception is thrown indicating that the library was not found! After such an error, even using the steps described above, would not successfully allow to load the library! o Now closing all instances of OOo and then starting over as described in step # 1 above, everything works again as described above. Going through the Java sourcecode that gets employed, the same steps are undertaken to load the ooRexx scripting engine. I.e. ScriptProviderForooRexx.java and ScriptSourceModel.java; the sourcecode of these files could be seen via the web using http://bsf4oorexx.svn.sourceforge.net/viewvc/bsf4oorexx/trunk/com/sun/star/script/framework/provider/oorexx/ (just click on the filename and then choose view). It seems that success and unsuccess is not caused by the scripting framework support, but seems to be linked to how OOo instantiates the ooRexx scripting framework? * Like, if the OOo dispatch interface is attempting to loading the scripting language it fails (and makes subsequent attempts to fail as well), * whereas if using the scripting framework editor to load a script first thing and run it off the editor in the first OOo session, then everything works (also subsequent dispatches). Does anyone have any ideas what might cause such a phenomenon? Any ideas highly welcome! TIA, ---rony -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: gnu make .LOW_RESOLUTION_TIME
Hi Michael, Thank you for your valuable inputs. On 2011/04/08 18:48, Michael Stahl wrote: On 07/04/2011 05:03, tora - Takamichi Akiyama wrote: I have just come up with a quick solution for the file systems using nanosecond time stamps. Problem: make: *** Warning: .LOW_RESOLUTION_TIME file `/x/solver/300/unxsoli4/inc/svx/sxsoitm.hxx' has a high resolution time stamp Cause: cp -p does not preserve a nanosecond part of time stamp. i've just checked on Solaris 11 express: both /usr/gnu/bin/cp [cp (GNU coreutils) 8.5] and /usr/bin/touch -r seem to support nano-second timestamps. That is a good news! This is my first impression when I have glanced at a source code of both OpenSolaris and GNU versions of cp command. They simply call fts_open() and fts_read() to obtain a nanosecond time stamp of original file and then set it to a newly created file. There seems no specific source code line about rounding-up or ignoring a nanosecond part. Therefore, I have concluded -- but not confirmed yet -- the OS that I am currently using might not be capable of setting nanosecond resolution to a file through the existing system call level API. $ cat /etc/release Solaris Express Community Edition snv_107 X86 Copyright 2009 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 26 January 2009 Michael's check result implies that the recent Solaris 11 express, obviously newer than what I am using, has become capable of both obtaining and assign a time stamp in nanosecond resolution. That's very nice. I appreciate you for checking it. Possible Solution: touch itself before cp -p to loose a nanosecond part of its time stamp. hmmm... this could work around the problem, but kind of interferes with our goal of a read-only source directory :) Yep, definitely! :) e.g. In my work environment, Zone A) hg pull, hg qnew, editing some source files, ... Zone B) building ooo. Zone C) testing it with a debugger. the directory is loop-back mounted with a read-only option. Okay, I am stopping digging this issue. It would shortly become unnecessary with Solaris 11. perhaps just installing new GNU coreutils on systems where this problem occurs is the way to go... That's right! Just in my case, the chance would be coming when my ZFS RAIDZ2 configured six 1.5TB disks reaches at disk full and consequently I would be forced to reconstruct my system with the latest OS. Thanks again, ciao, Tora -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
