Re: [dev] Re: CMake
On Fri, 11 Jun 2010 18:55:59 +0200 Michael Stahl wrote: > > We did attempt to create non-recursive makefiles for CMake, and > > they are "less" recursive than they once were. However, we found > > it impossible to handle implicit dependencies of generated source > > files without using recursive calls to make. If you have a > > solution for that, we would be very receptive. > > i believe the gbuild system is designed so that GNU make will restart > itself automatically in such circumstances. > but i don't know how that works, maybe Björn will explain it... Hi all, see http://www.gnu.org/software/automake/manual/make/Remaking-Makefiles.html#Remaking-Makefiles for details: "To this end, after reading in all makefiles, make will consider each as a goal target and attempt to update it. If a makefile has a rule which says how to update it (found either in that very makefile or in another one) or if an implicit rule applies to it (see Using Implicit Rules), it will be updated if necessary. After all makefiles have been checked, if any have actually been changed, make starts with a clean slate and reads all the makefiles over again. (It will also attempt to update each of them over again, but normally this will not change them again, since they are already up to date.)" So this is done by including an not yet existing file and providing a rule for it -- GNU make will take care of the rest. Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Community Council Elections 2010-06: Announcement and Nomination
On Wed, 09 Jun 2010 12:12:11 +0200 "Charles-H. Schulz" wrote: > I would like to thank both Jan and Frank for nominating candidates. > I think we have two perfectly legitimate candidates for the elections > of the Product Development Representative. Just to make sure: Did Andreas already accept the nomination by Frank? Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Openoffice development
On Wed, 09 Jun 2010 07:05:29 +0200 Bartosz wrote: > Currently I'm building the OpenOffice DEV300 under Ubuntu ( > http://wiki.services.openoffice.org/wiki/Documentation/Building_Guide/Building_on_Linux > ). > > I would like to fix this bug: > http://www.openoffice.org/issues/show_bug.cgi?id=84723 > > I found the solution and now I would like to create the patch. Hi Bartosz, great that you start contributing! To contribute patches, you will need to sign the SCA: http://wiki.services.openoffice.org/wiki/Sun_Contributor_Agreement attach your patch to the issue while you are waiting for the SCA to be processed. More info about contributing patches: http://wiki.services.openoffice.org/wiki/Contributing_Patches If you contributed a few good patches, it will likely be easier for you to become a "DomainDeveloper" -- then you can create your own feature branches at hg.services.openoffice.org and escort it through buildbots and QA yourself. If you are having questions along the way, dont hesitate to ask on #dev.openoffice.org on freenode (IRC). It will likely be the fastest way to get an answer. Best Regards and Welcome, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] branchmirror extension
Hi list, playing a bit with hg I found it quite it quite easy to create extensions. First experiments resulted in the branchmirror extension which lets you update a set of branch repos (specified by regular expression) with one command, using not too much bandwidth. You will find the extension here: > http://mercurial.selenic.com/wiki/BranchmirrorExtension Comments, ideas etc. welcome. Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] How to use DBG_foo?
On Thu, 01 Apr 2010 16:40:11 -0400
Terrence Enger wrote:
> Greetings,
>
> What does it take to use, for example, the DBG_ASSERT function defined
> in debug.hxx? I have poked around on the wiki without success.
>
> I have added enough #include lines to get the file to compile, but now
> the link step is failing with undefined references to DbgFunc() and
> DbgOut(). I see that these functions are bound into libtlli.so, but
> how do I tell the build system to--pardon the pun--make the link?
In general -- dont do it. As Michael Stahl pointed out on:
> http://wiki.services.openoffice.org/wiki/Writer/Code_Conventions
"DBG_* is defined in module tools, and therefore evil by definition"
Consider using OSL_ENSURE and friends from sal/inc/osl/diagnose.h
instead.
If you still want you use the evil old tools asserts, you would need to
find the makefile where the linking gets done (most on the time
${MODULE}/util) and add the tool lib to the linked lib like this:
SHL[0-9]STDLIBS+= $(TOOLSLIB)
You would also need to make sure that your module depends (directly
or indirectly) on the tools module in the prj/build.lst file.
Best Regards,
Bjoern
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: OpenOffice.org Product Development
On Wed, 31 Mar 2010 22:10:54 +0200
Sophie wrote:
> The unbalanced was between the mail and the disclaimer on the wiki.
> Sorry that I didn't explain myself better adding confusion on
> something I found important. (BTW I never read Eric Bachard mails
> since almost 2 years or really by accident, this is irrelevant to my
> eyes). Björn has done a very important work and we should be all
> really thankfull to him. [you know there is always a but, here it
> comes ;-) ] But, when I saw this warning at the top of the log of the
> release minutes page [1], I thought of a contributor, where English
> is really not his beloved language. He will go away asap and won't
> contribute anymore once he has tried to read/understand this message.
> This not the goal of the wiki to discourage contributions... I will
> discuss this on the doc project when I have some time, but I wanted
> to clarify my "not so balanced" assertion.
Well, I when adding the {{PageIgnoresWikiGuidelines}} template to a
page I take a look at the log. The creators of those pages mostly
english speakers and very involved in the project, so I could assure
they knew about the stuff going on with the wiki cleanup or knew where
to complain to.
However, the newcomers on the wiki are indeed a problematic case: We do
not want to scare them away, OTOH the cleanup showed me most of
"litter" that has piled up (incomplete page, no context, no links, no
category and sometimes nonenglish) was created by people
making their first, only and incomplete contribution. Such pages do
more harm than good because they mess up the Wiki and render the search
useless with meaningless results.
When editing content on the wiki, it has always been quite
clearly below the edit box: "Please note that all contributions to
OpenOffice.org Wiki may be edited, altered, or removed by other
contributors. If you do not want your writing to be edited mercilessly,
then do not submit it here."
One thing we might consider is to link from the contribution guidelines
to "Communication" and "IRC Communication" and ask people to get in
contact before editing.
Actually, Im gonna add that to the template and the guidelines now.
Best Regards,
Bjoern
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: Re: OpenOffice.org Product Development
On Wed, 31 Mar 2010 13:52:11 +0200 Rene Engelhard wrote: > How is patch -pX lack of resources? How is telling people how they > need to change stuff to get a patch (which works for everyone else > except Sun and is needed there) finalized to get integrated a resource > problem? (The fix I have in mind is a triviality for someone who knows > how to add/hide stuff in the Options dialogs) First the issue must be understood(*), then the patch need to be reviewed, it must build warning-free on all platforms against baseline and be QA'ed. You cannot simply apply 10 patches and be done in half an hour. So you might consider our processes unsuited for our needs -- if you do so, that might be discussed. But that is per se a completely different discussion from the distinction between Sun and Non-Sun contributors. Best Regards, Bjoern (*) Which is not trivial at all: Some patches change behavior they consider as a bug, while others would consider the same as a feature. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: Re: OpenOffice.org Product Development
On Wed, 31 Mar 2010 12:52:18 +0200 Rene Engelhard wrote: > a stronger community means actively involving hughe parts of the > "community". which you don't. there's still many sun-internal decision > just posed to the "community" as a fact everyxone has to live with. Who is "you" here? Sun contributors are not the Borg and in a community they should be treated according to their individual merits and vices and not be hold in kin liability. > There's still bugs not fixed or cared about because it doesn't affect > *you* (but only people outside) So you want to have control over the way that Sun manages its resources? Thats not how it works in _any_ OSS project. If you would stomp into #gentoo, #debian or #ubuntu and request your personal itch to be scratched you would be laughed out the door. Well, on ubuntu you might be offered a support contract, but that is different from what you are suggesting here. > Or patches lingering around for no reason because no one cares about. That would be a different issue. But there are also non-Sun domain developers, so this is not specific to Sun contributors -- its plain old lack of ressources. > That's not true. At least not for all cases where stuff ends up in > go-oo. Or to put it another way: It has been true for at least quite a few cases. Finally, I do not like statements implying "You are at Sun and thus not part of the community.". Actually, that is quite an unfair discrimination. Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Wiki Cleanup: Mission Accomplished (Mostly)
Hi List, the Wiki Cleanup has been almost completed. There are just seven pages left in: http://wiki.services.openoffice.org/wiki/Special:UncategorizedPages If you can remove those, please do so. Also note the new Guidelines at: http://wiki.services.openoffice.org/wiki/Wiki_Contribution_Guidelines All previous guidelines now refer to that page. Please stick to them when creating new content or when updating old. Pages that ignoring the guidelines will be dealt with more vicously from now on (read: they might just be deleted). Some of the categories are still overflowing with pages. Please note that the administration guidelines[1] say: "Dont assign a page to multiple categories if one is an subcategories of another. Just use the most specific category. This eases reordering and reorganisation of categories." I already sorted out the Development (which had more than 200 members) and Writer categories, by creating subcategories and moving the content into them. A category with more than 100 members rarely helps anybody. Other categories still need help. The dev projects are asked to take responsibility for the pages in subcategories of "Development" and its subcategories. Please take a close look at the pages in the following categories: http://wiki.services.openoffice.org/wiki/Category:Calc (113 members) Please create subcategories and move the pages into the more specific subcategory. Best Regards and thanks to all who helped out, Bjoern [1] http://wiki.services.openoffice.org/wiki/Wiki_Administration_Guidelines - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Trying to build and hack efficiently
On Sat, 20 Mar 2010 20:45:07 -0400 Rémy Roy wrote: > I'm using Ubuntu 9.10 with the DEV300 branch. I've having some > troubles building with the PKGFORMAT="installed" option. I can build > successfully but in the end my LOCALINSTALLDIR only contains an > openoffice.org directory. It seems like it is missing the > openoffice.org3 directoy where I should be able to find the > executables. Hi Rémy, see http://www.openoffice.org/servlets/ReadMsg?list=dev&msgNo=25968 Please consider opening an issue for that (if only for the fact that then there will be a place to point people to). But I guess it wont get high priority since you can either leave LOCALINSTALLDIR unset and build directly into the output dir of instsetoo_native or you use FORCE2ARCHIVE and untar the result to you preferred location. Note that PKGFORMAT="installed" has been removed from the Building Guide exactly because of this weird behavior. Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: Coding St{andards|yle}
On Thu, 11 Mar 2010 17:26:12 +0100 Herbert Duerr wrote: > That was my point. The rule that got us the hardcoded WIN16-style > code then is not IMHO is not a good guide for the future. If the > timeless native types had been used it would have grown with the > platform. And thus would be ABI incompatible whenever the native types "grows". Naa, thats not better. This way we are, in theory, at least still free to make a sal_Int16 an 32-Bit value, whenever _we_ like to(*). With a native type, we are bound to whatever the platform deems appropriate. BR, Bjoern (*) Unless there is code that is _relying_ on overflows -- but that stuff breaks too with "native type growth". - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: Coding St{andards|yle}
On Thu, 11 Mar 2010 16:10:55 +0100 Herbert Duerr wrote: > >> And while you are at it also replace the countless methods that > >> still use sal_uInt16 instead of int as return value... goodbye > >> Win3.1! ;-) > >> > > Replace those methods with what? ;) > > With their int equivalents. E.g. > svx/inc/svx/svdpage.hxx: sal_uInt16 GetPageNum() const; > could be replaced by > svx/inc/svx/svdpage.hxx: int GetPageNum() const; Isnt that kinda contradicting the original post by thb? Shouldnt that be: sal_Int32 GetPageNum() const; /me wonders. BR, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Coding St{andards|yle}
On Wed, 10 Mar 2010 10:05:24 +0100 Thorsten Behrens wrote: > I'd therefore like to revisit the OOo coding standards > (http://wiki.services.openoffice.org/wiki/Category:Coding_Standards), > and ideally merge the non-controversial stuff from > http://wiki.services.openoffice.org/wiki/Writer/Code_Conventions > with the overall rules. +1 in general for this. However, the little word "non-controversial" might cover the next epic flamewar after SCM and build system. For me, most of the stuff in the writer code conventions are non-controversial(*) as I wrote most of the stuff. ;) Still, how do we ensure that the conventions are actually better applied? Its nice that we have them, but they are of little use, if they are commonly ignored. BR, Bjoern (*) Exception: The stuff about constants might need to be reworked with ALLCAPS being reserved for the preprocessor. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Coding St{andards|yle}
On Wed, 10 Mar 2010 15:56:37 +0100 Stephan Bergmann wrote: > Re wincing at obviousness of matching range: How is that any > different for plain int (with INT_MIN--INT_MAX range) vs., say, > sal_Int32 (with SAL_MIN_INT32--SAL_MAX_INT32 range)? Because our interfaces consist of sal_* types and users of interfaces might rely on the implicit guarantee that a component can handle the full range of the type. Bugs because some code uses some odd 16 bit integer internally are really annoying (and not as uncommon as one might guess *cough* writer core *cough*). Of course, using sal_* types internally does not solve the range problem (multiplying two sal_Int32 for example), but still ... BR, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Coding St{andards|yle}
On Wed, 10 Mar 2010 14:57:12 +0100 Thorsten Behrens wrote: > sure, I buy those. Would then be worthwhile to re-def the types you > listed in terms of their C/std:: counterparts. Can do that. > sal_sChar is indeed unused, sal_uChar not so much (but there should > be a trivial 1:1 mapping). > > Or better even, mass-move things like sal_Size/PtrDiff over to > size_t etc. Moving things over to std. c++ is of course preferable. But at least we should kill of defines that are unused and of questionable value (like sal_sChar) _right_ _now_ as that is easy to do and otherwise they will be used sooner or later. BR, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Problem with building Open Office from mercurial
On Tue, 16 Feb 2010 11:43:41 +0100 Stephan Bergmann wrote: > On 02/16/10 11:27, bjoern michaelsen - Sun Microsystems - Hamburg > Germany wrote: > > For now I just changed the description in the Building Guide to do: > > cd instsetoo_native && build --all > > > > which is what most devs actually do. > > Not smoketestoo_native? Valid point, Im feeling a bit guilty. However, since I dont like those various windows popping up on my desktop, I usually do a build, and only after that is successful, I hassle myself with setting up a vnc-session to run the smoketest in. I should script that, then I could go directly to the smoketest. BR, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Problem with building Open Office from mercurial
On Tue, 16 Feb 2010 00:21:36 +0100 Lukasz Szczygielek wrote: > I have a Linux Fedora 12 64 bit. After a configure and bootstrap and > source LinuxX86-64Env.Set.sh I discovered the problem. > > On the page I read that after this steps I should make: > dmake > > but then I had: > Checking module list > build -- version: 275224 > > Fetching dependencies for module testautomation from solver... failed > Fetching dependencies for module packimages from solver... failed > Fetching dependencies for module postprocess from solver... failed > Fetching dependencies for module l10n from solver... failed > > > WARNING! Project(s): > testautomation > packimages > postprocess > l10n Hi Lukasz, looks like this is the output from the check_modules rule which does call build.pl --checkmodules. build.pl --help says, that does "check if all required parent projects are availlable[sic]". Can someone from RelEng help out with a description a bit more verbose? For now I just changed the description in the Building Guide to do: cd instsetoo_native && build --all which is what most devs actually do. BR, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
On Fri, 12 Feb 2010 17:31:18 +0100 Christian Lippka wrote: > If we make the office crash in non pro than there will be never a > chance to get the qa to work on non pro again. Depends. If we make the master crash on tests in every milestone, sure. As said before an aborting assertion should only be used for corrupt internal state. If you notice a pointer to dead objects flying around or invalidated iterators that are used it is _Good_ to crash on non-pro, simply because continuing from there is pure luck (and its so much more fun to debug if dead objects have devastated the program state by a decent fandango on core). > Also, an assertion that aborts hinders my work with the office > as long as the assertion is not fixed. One abort assertion in writer > with 100 people working on the writer causes one to fix the issue and > 99 to idle until he has finished and commited the fix. If you like > your assertions to abort, you can press the cancel button. It not difficult to temporarily comment out the one assertion that went past the tests on the cws and on the master until that P1 is fixed. IIRC, Stephan said on FOSDEM that he intends to get tests to run on the master too. Assertion-free execution of those should be part of that. BR, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
On Fri, 12 Feb 2010 14:38:18 +0100 Philipp Lohmann wrote: > The obvious optimization for that process would be leaving things as > they are and introduce an OSL_ASSERT_ABORT for those who really want > that. still one would need: - to get rid of DBG_ASSERT, because it makes absolutely no sense to have both DBG_ASSERT and OSL_ASSERT). - to move all the non-informal assertions up to OSL_ASSERT_ABORT. And Frank and Christian should be the first to do that for their assertions, if those are, as they claim, only reporting seriously messed up internal state unlike those chatty noncritical observations us other devs seem to use assertions for. BR, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
On Fri, 12 Feb 2010 13:10:01 +0100 bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote: > Current situation: > - assertions might be anything from a informal "I didnt expect this > external data" to a critical "internal state corrupt" > > Desired situation: > - assertions are only "internal state corrupt" messages and should > abort > - everything else is tracing, logging On a second thought: Frank is afaid his asserts will get lost in all the OSL_TRACEs we have today, Stephan wants assertions to be assertions. Proposal: - Make all current OSL_TRACEs to a new OSL_TRACE_VERBOSE (available by OSL_DEBUG_LEVEL>2 or something) - Make all current OSL_ASSERTs and DBG_ASSERTs to OSL_TRACEs - Keep OSL_ASSERT for real asserts that abort (and creates an P1 when firing on a master) The migration will not change the behavior much but allows the introduction of real assertions. Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
On Fri, 12 Feb 2010 12:34:33 +0100 Christian Lippka wrote: > So you see OSL_ASSERTS from your code, but you never see asserts from > code that your code uses. Or things you break with your code in other > places. Im covering very broad ranges of modules with DEBUG=true, not just the module were I changed code. > Can you elaborate on the issues that bother you? Various little annoyances, each not taking long to debug, but those are adding up. > And I may be wrong but DEBUG=true in pro does not give DBG_ASSERTs. Which is a bug. DBG_ASSERT should be killed if favor of OSL_ASSERT anyway, or is there any valid use for having those two? > Assertions are different to build breakers enforced by the changes for > warning free code. You can very easy verify that you have not > introduced any compiler warning with your changing by simply build > the complete office (yes not 100% I know, but you can be very sure). > > But you can never be 100% sure that you didn't introduced assertions > since you can't check every code path there is that may be affected > by your changes. Therefore assertions will pop up in the master and > an abort will render non pro unusable so people will stop introducing > them. Assertions should be tested with the common tests (cwscheckapi has decent code coverage) preventing the non-pro master to become unusable. Assertions should be visible enough to get reported and rare enough to allow usual testing and development on the nonpro builds. Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
On Fri, 12 Feb 2010 12:43:29 +0100 Malte Timmermann wrote: > -1 for discussing here whether or not QA should use non-pros, because > it IMHO has absolutely no influence on how assertions should behave. > And if you want QA to use non-pros, they for sure would give up quite > soon when assertions always abort. With assertions being assertions and "give up" meaning reporting it, thats exactly the desired behavior. Current situation: - assertions might be anything from a informal "I didnt expect this external data" to a critical "internal state corrupt" Desired situation: - assertions are only "internal state corrupt" messages and should abort - everything else is tracing, logging For example, Frank is claiming his asserts are all serious issues and thus shouldnt be "degraded" to mere traces. So keeping "his" asserts as assertions, even if they abort should not scare anyone, right? Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
On Fri, 12 Feb 2010 13:12:08 +0200 Rich wrote: > (non-product, i assume ?) ahem, yes. > if the plan is to use these non-product builds for > developers only, then i stand corrected and have no opinion on the > issue :) Thats the plan as I understood Stephan (didnt he clarify that already in one of his followups?). BR, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
On Fri, 12 Feb 2010 09:11:21 +0100 "Frank Schoenheit, Sun Microsystems Germany" wrote: > - Developers should use non-product builds *only*. That's a very > apparent measure, still, a lot of people don't do. If you ask why, > often the answer is "it's unusable 'cause of the many assertions". > Hmm? I am one of the devs that rarely use a non-pro build, but not because "it's unusable 'cause of the many assertions", but because there are simply to many differences from the product build in them, causing issues (first of all: annoying build breakers). I do, however build with DEBUG=true to see assertions. On the topic of "what is an assertion": Yes, assertions should abort. Otherwise, they are not an assertion, but something that is better covered by OSL_TRACE. BR, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Should assertions abort?
On Fri, 12 Feb 2010 10:30:59 +0200 Rich wrote: > speaking as a user here, not a coder - if software can continue with > operating, it should. yes, it should warn me, but it should run as > long as possible, either allowing me to save the document, copy data > out of it or whatever. We are talking about product builds, so this does not effect and affect (pun intended) end-users. BR, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Correction in OO.o Base
On Tue, 09 Feb 2010 17:12:23 +0100 Svatopluk Bláha wrote: > Now, with which conditions I can obtain access to source code? Hi Svatopluk, see http://wiki.services.openoffice.org/wiki/Documentation/Building_Guide for getting started. Best Regards, Bjoern Michaelsen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Java Programming
On Tue, 09 Feb 2010 00:40:16 + rogerar...@gmail.com wrote: > If you could give me some guidance, I'd enjoy spending some of my > spare time working on > Java code for Open Office. Most of the "core components" of OpenOffice.org are written in C++, so if you want to keep away from that, you might be interested in developing extensions for OpenOffice.org. There is a good integration with Netbeans to get you started: http://wiki.services.openoffice.org/wiki/Extensions http://wiki.services.openoffice.org/wiki/OpenOffice_NetBeans_Integration Java is the recommended way to create OOo-Extensions and extension development is a good way to get used to the UNO-API. Best Regards, Bjoern Michaelsen P.S.: If you really intent to work on the core product (although that is mostly C++), take a look at the Building Guide to get started: http://wiki.services.openoffice.org/wiki/Building_OpenOffice.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Test Cleanup
On Mon, 14 Dec 2009 15:06:45 +0100 Stephan Bergmann wrote: > Hi all, > > I just embarked on a new project, namely to clean up and consolidate > the various test frameworks and corresponding tests available in the > OOo build environment. > ... > Comments on all of this are, of course, very welcome. Yay! Sounds like another great step forward for the development environment. Best Regards, Bjoern Michaelsen -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Building OpenOffice.org with GNU make
Hi Lists, The Build Environment Effort Team(1) has implemented a proof-of-concept on how to build OpenOffice.org using GNU make. The rationale for this is explained in this blogpost on GullFOSS: http://blogs.sun.com/GullFOSS/entry/building_openoffice_org_with_gnu The Build Environment Effort Team is carefully optimistic that updating the build system in this way would benefit the development of OpenOffice.org. Your questions, opinions and ideas about this topic at welcome. You are invited to discuss a possible move to GNU make and its implications on the mailing list d...@tools.openoffice.org. I will try to answer questions ASAP. Best Regards, Bjoern Michaelsen (1) http://wiki.services.openoffice.org/wiki/Build_Environment_Effort -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] How can I build source code using VS 2008
On Wed, 02 Dec 2009 09:48:21 +0800 Arron Xiao wrote: >I intend to build openoffice source code using VS 2008 C++, > However, I cannot find any resource about it on your web site. Can > you tell me relational link about it or give me some suggestion? May I ask where you looked (which pages you crossed) when searching for the resources on building OOo? We might consider adding a link to the Building Guide from there. Best Regards, Bjoern Michaelsen -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] interested in joining you
On Tue, 17 Nov 2009 19:56:42 -0800 (PST) Ranjeet Jaiswal wrote: > Hallo sir, I am an engineering graduate from university of Allahabad. > Interested to joining openoffice.org > Please tell me how I can start with you. Welcome Ranjeet, it depends on what tasks you want to perform. For development of OOo itself see: http://wiki.services.openoffice.org/wiki/Development For development of extensions to OOo see: http://wiki.services.openoffice.org/wiki/Documentation/DevGuide http://wiki.services.openoffice.org/wiki/OpenOffice_NetBeans_Integration to get started. see: http://extensions.services.openoffice.org/ for examples on what can be done with extensions for OOo. Best Regards, Bjoern Michaelsen -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Build System and visibility
On Tue, 17 Nov 2009 10:32:21 +0100 "Frank Schoenheit, Sun Microsystems Germany" wrote: > At least we'd need a makefile-clause for setting a default, /me > thinks. > > For instance, for libs exporting the usual three UNO entry points > component_*, I would like to have a "make everything private" > directive, plus a PUBLIC statement for the three functions. The default would be "everything private". > For other libs, which mainly provide tools for client code, a "make > everything public" directive would be useful. These tools libs fall in two categories: - either they are small helper libs, in which case it is not much effort to make every PUBLIC explicit in the source. - or it is one of the bigger framework libraries, in which case you would want to only export what is absolutely needed -> default: everything private. > Which means that you'd still need 2 of the 3 mechanisms, and the only > thing you could spare are the map files. Not sure this would be worth > the effort. I do not think that we still have that many libs that are not explicitly marked PRIVATE/PUBLIC on the function. So it would be only about those few "renegade libs" that do not follow the convention. A very important sideeffect would be that the visibility of a function can be seen directly in the source, not by: - the source - the mapfile - the makefile - That would be a huge improvement in readability. Best Regards, Bjoern -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Build System and visibility
Hi List, again some stuff from the Build Environment Effort(1). While figuring out the way we build libraries with the OpenOffice.org build system it became apparent that we seem to have way to many redundant ways to set the visibility of functions. From the top of my head: - map files - explicitly setting a compiler flag in the make file - XX_DLL_EXPORT/XX_DLL_IMPORT/XX_DLL_PRIVATE and friends However, using the XX_DLL_PRIVATE and friends should be "enough for everyone", right? So, it should be possible to simplify the build by only using XX_DLL_PRIVATE and friends, or does anybody see a use case that is not covered by it? If so, I would like to hear it ... ;-) Best Regards, Bjoern (1) http://wiki.services.openoffice.org/wiki/Build_Environment_Effort -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] configure: error: Failed to find some (perl) modules
On Sat, 14 Nov 2009 19:17:40 -0500 Albretch Mueller wrote: > I am trying to run config like that (from within a script) > but I an stumbling on "some" missing perl modules: > [...] > > checking for perl... /usr/bin/perl > checking the Perl version... checked (perl 5) > checking for required Perl modules... Can't locate Archive/Zip.pm in > @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 > /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 > /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at > -e line 1. > BEGIN failed--compilation aborted at -e line 1. > configure: error: Failed to find some modules > > I thought --enable-verbosity was going to give me more information > > but there are a lot of packages here: > > http://packages.debian.org/stable/perl/ > > which ones do I need to install in order to configure OO? in general, see: http://wiki.services.openoffice.org/wiki/Category:Distribution-Specific_Build_Instructions for the package names of the prerequisities on different distros. Best Regards, Bjoern -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Getting rid of implicit dependencies on default_images
Hi List, While working on the Build Environment Effort(1), we stumbled over the implicit dependency of all modules generating resource files on default_images. The resource compiler digs into the default_images directory for the files specified in the *.src/*.hrc files. However, since there is no need for rsc to actually read the file contents when generating *.res files, the dependency is much heavier than needed. After all, everything rsc needs to know is _if_ there is a file with a given name, but not its contents. To get rid of this dependency, we are considering to simply generate a file containing the dirstate of default_images (for example the output of "find default_images") and put that in the solver. rsc would use the contents of that file, and would not try to search default_images directly. This would: - reduce dependencies - for example allow to build sw without having a complete default_images around - ease further efforts like split build/better support for full deps Opinions? Best Regards, Bjoern Michaelsen (1) http://wiki.services.openoffice.org/wiki/Build_Environment_Effort -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: [extensions-dev] IDL references from the Wiki -> via IDL tags
On Wed, 11 Nov 2009 14:17:04 +0100 Juergen Schmidt wrote: > this can be seen more as a reminder to make use of the IDL tags, see > http://wiki.services.openoffice.org/wiki/Wiki_maintenance/IDLTagExtension > for detailed info. And while we at it, please also use: http://wiki.services.openoffice.org/wiki/Special:Interwiki http://wiki.services.openoffice.org/wiki/Template:M http://wiki.services.openoffice.org/wiki/Template:CWS http://wiki.services.openoffice.org/wiki/Template:Bug and follow the guidelines in: http://wiki.services.openoffice.org/wiki/User_Experience/SOP Best Regards, Bjoern Michaelsen -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Compilation problem
On Mon, 02 Nov 2009 14:40:31 +0100 Stephan Bergmann wrote: > On 11/02/09 14:02, Imre Steer wrote: > > 3. Run the bootstrap script and set up the environment variables > > with the LinuxX86Env.Set.sh and with: > > export LOCALINSTALLDIR="/usr/local/ooo" > > export PKGFORMAT="installed" > [...] > > 5. After about three hours the compilation finished, showed no > > error but I cannot find the resulting executables in the given > > directory, only URE has been put here. > > I assume what happens is the following: Per > instsetoo_native/util/makefile.mk, three products are built by > default, openoffice_en-US, sdkoo_en-US, and ure_en-US. If each > builds into $LOCALINSTALLDIR, and presumably removes the directory > before installing into it, the net effect would be to have just URE > (the product that happens to be built last) afterwards. (Also, if > you did a parallel build, you would probably get even more funny > results.) Is there a bug for this? If not, I think we should create one. This is really confusing for newcomers. For now, I removed PKGFORMAT=installed from the Building Guide. FORCE2ARCHIVE should do for now. Best Regards, Bjoern -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Announcement: Migration to Mercurial
On Tue, 27 Oct 2009 14:25:40 +0100 Jens-Heiner Rechtien wrote: > Regarding your idea with reorganizing the pages. I like that :-). > Maybe we could just forward the old pages to the new ones (only the > "OOo and Mercurial" one, no need to bother with rest). All pages moved, all wiki internal links updated. Redirects are in place (thats the default when moving). Maybe we can remove the redirect pages in 6 month when this stuff is "old". Best Regards, Bjoern -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Announcement: Migration to Mercurial
On Tue, 27 Oct 2009 14:22:31 +0100 Jens-Heiner Rechtien wrote: > Actually, I'm thinking about a hook which will prevent the creation > of new heads on the outgoing repositories. Not yet implemented, > though. This time, unlike last time, I am against such a hook. ;-) If somebody creates multiple heads on an outgoing repo, no harm was done to the master. This is different than with SVN. However, it has to be clear that such a repo will never be integrated unless all heads are merged. Still, having such repos on outgoing might be of value for experimental minibranches, where one is not certain if they might get integrated one day. When those are on outgoing repos: - They are on backup as long as it is uncertain if they will make it to the master. - They can be easily merged into "real cws" for integration once they seem fit for it. - They can be simply deleted with the repo if they prove faulty. Nothing of value will be lost. If you want to make absolutely clear that a cws wont be integrated when its repo has multiple heads, I would propose to add another "Test" to EIS showing this nifty stopsign and scary red boxes, if the cws repo has multiple heads. Best Regards, Bjoern Michaelsen -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Announcement: Migration to Mercurial
On Tue, 27 Oct 2009 13:04:50 +0100 Christian Lohmaier wrote: > Pushing the other ones doesn't do any harm besides wasting bandwidth > on a push. Thats not entirely true. This is the way there is harm by adding superficial heads to an outgoing repo: - RelEng expects a cws repo to contain exactly one head on integration. They do not want to have to figure out which of multiple heads should be integrated. This is a reasonable requirement. - Thus all heads on an outgoing repository need to be merged before integration. Since all heads are merged into one and this one head will be integrated, everything on the cws will be integrated in the master. - Thus there is no way to have an "scrap branch" on an outgoing repo that will not be integrated in the master. The only way to get rid of unwanted experimental branches is to open a new cws, cherrypick branches over to the new cws and then delete the old cws. tl;dr: Do NOT create multiple heads in outgoing repos. > [...] > real 0m1.551s > user 0m0.100s > sys 0m1.450s Well, thats all true with any real OS and FS. Unfortunately, on Windows time and space requirements are quite different. > ..instead just use hg push -r tip, to only push the head you're > actually working on. Or, if unsure, do not create multiple heads (unless temporarily on a local repo when you do the equivalent of a "cws rebase", in which case you are merging them immediately). Best Regards, Bjoern Michaelsen -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Announcement: Migration to Mercurial
On Tue, 27 Oct 2009 10:58:53 +0100 "Matthias B." wrote: > Maybe I've overlooked it but I haven't seen an equivalent to > > svn switch URL-of-CWS-or-tag This is certainly possible with hg. However, to use this functionality you would need multiple heads in one repository. Since this is _not_ currently supported by releng, you are completely on your own when doing so. If you are a not yet too confident in using hg, just use multiple repositories: It uses a bit more disc space, but will likely have break-even by not breaking your repos once. Anyway, here we go (totally unsupported by releng): > With svn I had one checkout which I switched to whatever cws or tag I > wanted to build and svn switch would only download the differences > between my current checkout and the target. That was fast, saved > bandwidth and hard drive space (believe it or not, I have to make do > with an 80GB hard disk). With Mercurial it looks like I have to clone > a complete repository whenever I want to build a CWS or a tag. Could > someone give me the Mercurial equivalent to the following sequence of > instructions: > > svn co http://svn.services.openoffice.org/ooo/trunk/ > cd trunk $ mkdir local_DEV300 $ cd local_DEV300 $ hg init $ hg unbundle /DEV300.hg > svn switch http://svn.services.openoffice.org/ooo/cws/blabla > # Now the current directory contains the OOo sources for CWS blabla hg pull CWS-URL hg up --clean (or hg up --clean -r last_cws_changeset) # Be really careful with --clean. Read the update help carefully! # last_cws_changeset is easily tracked with the bookmarks extension > svn switch http://svn.services.openoffice.org/ooo/tags/OOO320_m2/ hg up --clean -r OOO320_m2 # Be really careful with --clean. Read the update help carefully! # last_cws_changeset is easily tracked with the bookmarks extension > # Now the current directory contains the OOo sources for milestone > OOO320_m2 # NOTE: The changes from CWS blabla are NOT merged. Unless > they have been incorporated in m2 by > # the OOo developers, they are gone now from my checkout. > # This is an important point. I am NOT looking for a way to merge > changes from different trees. > svn switch http://svn.services.openoffice.org/ooo/trunk/ hg up --clean -r last_DEV300_changeset # Be really careful with --clean. Read the update help carefully! # last_cws_changeset is easily tracked with the bookmarks extension > # Now my repository is exactly as it was in the beginnig (assuming no > commits happened in the mean time) > > As mentioned in the beginning, I'm interested in a way of doing this > that is fast, bandwidth-efficient and diskspace-efficient. As shown, theres a way to do that. However, this local repository now contains multiple heads. Do NOT DARE to "hg push --force" these multiple heads to an outgoing repository or the wrath of RelEng will be upon you. You have been warned(*) ;-) Best Regards, Bjoern (*) At least twice, as the docs say this pretty clearly at: http://wiki.services.openoffice.org/wiki/MercurialCws#Publishing_changes -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Announcement: Migration to Mercurial
On Tue, 27 Oct 2009 04:42:37 -0400 "T. J. Frazier" wrote: > Jens-Heiner Rechtien wrote: > > Migration to Mercurial > > == [snip...] > > Documentation: > > -- > > > > Main entry point: > > http://wiki.services.openoffice.org/wiki/Mercurial > > Bj__rn has done a beautiful job of adding a TOC for the Mercurial > pages. Yeah, sorry. I could not keep my hands of it ;-) (and I really just found a template to copy'n paste) > The one problem I see is, will potential users be able to find > it? > Please think about where developers would look for this info, then > add links there. I added one on the main wiki page. As of now it is linked from: - Main Page - Main Page -> I want to be an OpenOffice.org developer - Main Page -> Build Environment Effort - Main Page -> Building Guide - Category:Mercurial - Category:SCM - Category:Development (Entry Page only) - Category:CWSTooling (were relevant) - I did not add Category:Build System and Category:Quality Assurance to not dilute them. Anything missing? Actually I think in the long run (in 6 month, after migration), it would not need to be on the Main Page anymore as current devs would know about it and newcomers will find it in the "I want to be ..." and "Building Guide" Pages. But now, its great to have it on the frontpage. Thanks for adding it! Best Regards, Bjoern Michaelsen P.S.: I was wondering if it would be a good idea to move the pages to subpages matching their current title. Of course one would keep the redirects from the "historic" titles to keep the links from the Mailing Lists working. OOo and Mercurial -> Mercurial/Getting Started MercurialCws -> Mercurial/CWS MercurialTipsAndTricks -> Mercurial/TipsAndTricks MercurialMigration -> Mercurial/Migration Opinions? -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] OpenOffice.org Wiki Categories
On Mon, 26 Oct 2009 14:59:28 +0100 Juergen Schmidt wrote: > bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote: > ah i see, but Marketing is so important from my point of view that i > wouldn't have searched under "Project". Well but that is my personal > problem with all the "sub" projects. I dont think "importance" should play a role on the Index Page. Thats what the main page is for. The index should: - offer a structure to search for things in a hierarchy - allow to attribute reponsibility for content in the wiki > For me it's still more natural to see the OpneOffice.org project with > several main entry points independent of any sub project. > > Related to a "MainIndex" i would expect entry points like > "Development", "Documentation", "Marketing" ... "Development", "Documentation" and "NLC" are right on the toplevel because they contain so many subcategories themselves (>15). "Wiki" is there because it contains important meta-information. However, "Development" is problematic in itself, as people use different definitions. Some use it for stuff doing development on top of OOo as a "blackbox"-framework via the API (Extensions, Basic macros etc.), while others use it for development on OOos internals itself. In the end this dilutes the category and its use. Good categories would seperate: - end users (category:enduser) - Developers using OOo as a blackbox platform (extensions, macros, etc.) (category:ApiDevelopment ?) - OOo internal development (category:CoreDevelopment ?) But its still a long way to get there. Best Regards, Bjoern -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] OpenOffice.org Wiki Categories
On Mon, 26 Oct 2009 13:38:44 +0100 Juergen Schmidt wrote: > it seems to be a good start but probably some more main categories > are necessary. But then the question is if we need it at all or if a > reworked main page would help to navigate in and through the wiki. Without categories, there will be an ever-growing number of obsolete, outdated and orphaned pages. This is not a problem for navigation from the main page, but it will make the search functionality of the wiki more and more useless. > I think a common agreement on how to use categories and sub > categories would be more helpful. Like: http://wiki.services.openoffice.org/wiki/User_Experience/SOP/Wiki/Categories http://wiki.services.openoffice.org/wiki/User_Experience/SOP/Wiki/New_Wiki_Pages for starters? Yes, I think every new page should be in at least one category that is a project (or a subcategory of a project). > Take a look for example on Tutorials. Clicking on the category shows > a lot of tutorials and when you expand the node in the main index you > get a sub category Basic:Tutorials. What does it mean, no other > tutorials or only a different usage of categories? Looks confusing to > me. Yeah, right. But I think ordering the categories is the second step, first we will need to get stuff into at least one category and make each category a direct or indirect subcategory of MainIndex. Then we can really see whats there and consolidate. That being said, I already did some obvious cleanups along the way (like merging the "Project" and "Projects" categories). > I miss for example the category "Conferences" and a related entry in > the main index. The same for "Marketing". Huh? MainIndex -> Project -> Markting -> Conferences seems pretty straightforward to me. That being said those _are_ already listed on the frontpage. Best Regards, Bjoern -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] OpenOffice.org Wiki Categories
Hi List, I tried to add a bit of structure to to the categories used on the Openoffice.org Wiki. I hope the most important ones are now a direct or indirect subcategory of the MainIndex at: http://wiki.services.openoffice.org/wiki/Category:MainIndex Please check, if "your" category has found a place in the hierarchy, if not, sort it in. In addition, I tried to sort categories in as at least one direct or indirect subcategory of an OpenOffice.org project. This is to help attributing responsibility for pages. Finally, I am proposing to link to [[:Category:MainIndex]] from the frontpage. Hopefully this will aid to keep the Wiki a bit more structured. Comments? Best Regards, Bjoern Michaelsen -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: Moving files in a Subversion CWS
Frank Schönheit - Sun Microsystems Germany wrote: Perhaps a postprocess hook which sends mails to EIS, keeping track of moved files, and issueing warnings upon integration when some change is about to be lost? I fear this is not possible in post-commit, as the info that something was a move isnt available anymore, because it will show up as a delete and an addition in the commit when you analyse it with svnlook. ugh. Best Regards, Björn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Re: Moving files in a Subversion CWS
Jens-Heiner Rechtien wrote: Hi, I wouldn't call for a complete ban but it looks like one has to be extra careful. Restructuring should be done in CWS which lives only a very short time. Best, say, opened on one milestone and integrated in the next (as first CWS) this would minimize the potential for data loss. As first CWS? Wouldnt that doom any changes from other CWS on the moved files because the file is already deleted when they are itegrated. *Confused* I thought _last_ CWS would be the safest ... Still data loss is possible even in this scenario, which IMHO is very scary. I would feel much more comfortable, if a naked move wouldnt be possible. As an (ugly, very ugly) workaround for now, we might need a command in the cws tool that registers the moved files by their "old name" (the name it is known as on the master) somewhere. This could be either in a svn property (on trunk??) or in a "administrative file" somewhere. It should at least be noted, if changes to a file are wandering to /dev/null. Have Fun, Björn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Re: Writer Code Conventions / Cpp Coding Standards
On 10/20/08 15:05, Thorsten Behrens wrote: I see. But this surely doesn't apply to all-new files, no? No (other than that you cannot checkout a file that exists in a working copy using a different case, but that is to be expected with caseinsensitive filesystems). (is there an svn bug filed for this already?) I dont know, maybe it is even fixed in current releases. I just remember doing a svn mv on *nix once and as it gets translated to a deletion and an addition with history, the addition might fail because the "old" file is still there. Ok, then fine with that - except that I'd veto the one-line if-statement (prevents setting a breakpoint there for various frontends), I extended the description, one liners arent strictly forbidden, but strongly adviced against. and the non-alignment of statements (proper editors do that en passant, and it's quicker to parse for the eye). [Now you see where it leads, when trying to agree on formatting ;)] We could fight a lng fight about that one(*), but shouldnt (or we should when we are sitting together some evening and having a beer). Lets just keep it with "we agree to disagree" there. The writer team is ok with the current proposal, if you want to propose the code conventions to other team, just leave out those you dont like. Please feel free to add recommandarions about SAL_NO_VTABLE, SAL_DLLPUBLIC_EXPORT, SAL_DLLPUBLIC_IMPORT and SAL_DLLPRIVATE. Will do - seeing that you're working on it, can you ping me for a handover in private? Adding stuff shouldnt be a problem, so just go for it. However, existing conventions have already meet the consensus of the writer team and thus should be kept for now. Have Fun, Björn (*) I would argue that alignment of statements is essential for deeply nested languages like lisp and ocaml, but actually hurts with C/C++ or Java. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Subversion precommit hook
On 10/20/08 17:10, Jens-Heiner Rechtien wrote: there was no need for crucifying yourself, server side we are python only. Actually we have no perl bindings installed. If I only had known that before. I like and know Python a lot better. I think we need to be a bit carefull with pre-commit hooks. Other than post-commit hooks they do influence the "user experience" of SVN, so they have to be fast. Well, we've got a very fast server so probably this is not really a problem. I would guess the scripts as of now are not really a performance issue - they only work on the diffs of a commit not on whole files/directory trees as the commit itself has to. Also, I would suggest to add features to the hook bit by bit and not all at once. Have Fun, Björn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Subversion precommit hook
On 10/20/08 17:39, Philipp Lohmann wrote: Hi, Jens-Heiner Rechtien wrote: I somehow don't like tying SCM functionality to commit messages, but that's may be just me. And should we enforce policy (like tabs vs spaces etc) via the SCM tool? is there another point where we could actually enforce policy ? Enforce as in preemptive, not cooperating ? It would have the advantage that people cannot simply forget this. OTOH code formatting has the potential to create a holy war about nothing (namely whitespace). Well, there is a clearcut requirement in the OOo coding style. And whitespace is not "nothing", as it is really reducing productivity on merges/rebases. Personally I'd prefer this to be not a check, but an automatic on the fly reformat - but I assume that would occasionally break a file, if the input deviates too much (or in an unexpected way) from the expected format. The only alternative point where this could be enforced is on the master: After all cws are integrated, all lines that were added/updated all reformatted. This would ensure no nonconforming new code will be added, without creating huge diffs that every cws would have to cope with on merge/rebase. Have Fun, Björn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Subversion precommit hook
On 10/20/08 15:08, Frank Schönheit - Sun Microsystems Germany wrote: See issue 95199 for my currently prepared (and already implemented) solution, though a post-commit hook also sounds interesting. I just tried to add an svn:ignored dir. That works. If someone does a "svn diff" in a module, and sees: ? source/somenewfile.cxx ? source/somenewfile.hxx he might be tempted to do a 'svn add *; svn ci -m "my message"' and goes to grap a coffee. When he returns he has happily commited the output trees. That seems kinda dangerous to me. If we svn:ignore output trees, we should also prevent them from being commited (if we have a list of platforms that are svn:ignored, we could also specifically look for those in the precommit hook). BTW this is just as dangerous when having the output trees in global ignore in the config. Have Fun, Björn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Subversion precommit hook
On 10/20/08 12:51, Rene Engelhard wrote: How should that be possible when you svn switch a complete tree to a cws (which you should do)? There's no need for any checks at all, if everybody does what he should do ;-). There's no modules anymore but one big tree. That check imho is moot. Indeed. However, the build system still sees a difference between a dir and a module. > > ... toplevel dirs in modules ... Err? Why should that be disallowed? And how does that help? For adding output trees you'd need a svn add on that anyway, so... If people do that you can't help them anyway... Currently we have the output trees svn:ignored. "svn add *" would still happily add the output trees. I would bet this will bite someone sometime. IIRC someone commited a output tree to the CVS once. However, I dont think it is essential to have such a check in the precommit hook - its merely a proposal. Have Fun, Björn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Subversion precommit hook
On 10/20/08 12:56, Frank Schönheit - Sun Microsystems Germany wrote: > > ... modules ... Not sure this is needed. AFAIK it is (at least in CVS times it was) necessary to do other things for adding a new module (announcement to releng etc.), so just preventing the commit doesn't really solve a problem, IMO. > ... toplevel dirs ... Not sure this is worth it. I still think ignore lists are the best way to prevent accidental committing of output trees, and for all other dirs, we should not force us to a special commit message without a need. Subversion does not care about "modules", however the build system might. Restricting toplevel dirs are probably an superfluous hassle - it was just something that was easily implemented after having code watching for certain dirs. I added the toplevel dir stuff, because you can still commit an svn:ignored directory. However, Im not vicious about that toplevel stuff. Given that pre- and postcommit hooks are basically working the same, using this precommit hooks as a base to create a postcommit hook should be easy. That hook should automagically svn:ignore output dirs when a new module is created in a cws. I think that would better than a cronjob svn:ignoreing all files as: - output trees are svn:ignored right after the module is created and even in the cws - you only need to manage the platforms in the postcommit hook, no need to track every platform/module combination. - Never allows changes/deleting of tagged versions preventing changes sounds good, preventing deletion of tags - not sure. At least in CVS times, tags became a pain in the neck over time (because there were so many), but this probably doesn't apply to SVN. Its less of an issue with svn and remember this check can be disabled by a special commit message (containing "MODIFY TAGS"). The svn-client would barf up that info too when rejecting a commit. Have Fun, Björn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Re: Writer Code Conventions / Cpp Coding Standards
On 10/09/08 14:49, Thorsten Behrens wrote: > ... Hi Thorsten, Sorry for taking some time to answer, it seems my newsserver sometimes ate messages > Generally, the list seems fairly parallel to the coding standards, > there are places where coding standard items are just repeated or > refined (e.g. when to make a header external, namespaces, > encapsulation, pimpl) - I would love to have this cross-referenced, > or even moved to the 'details' section of the coding standard. > This would improve the coding standards digestability, shorten your > list, and save people generally aware of the coding standards some > reading time. I will try to move the details out of the main description and add references to the coding standards where possible. > - I like the module organization section, but would add more, like >e.g. the convention of building libs one directory up (for >Writer), what generally the util & prj dirs are for & what they >should contain. Yes, I would love that too, however my idea of how this is supposed to look like is only vague. Maybe someone from RelEng might step up and add a few lines about how a "wellformed module" is layed out? >Maybe keeping filenames all-lowercase is a bit anachronistic - >but keeping them [a-zA-Z0-9.-] seems still crucial. True. OTOH, for example Subversion has some interesting behaviour with upper/lowercase filenames on Windows (commit "svn mv SomeFile.cxx somefile.cxx" on unix and update on Windows). >I'd relax the strict .hxx|.h rule a bit, taking udk headers for >example, which split templates up into separate declaration & >definition files Okay. > - the formatting section is probably the most controversial one >(and that's one of the reasons we didn't specify that in the >coding standards). Either skip it as well, or at least refrain >from catering for tools like lxr (which is obsolete now anyways). >The most frequent reader of the code is still you, and your >fellow devs (using a proper editor) - strive to make code readable >*there*. Well, lets just call them recommendations. If you do not have a stylistic preference on a topic, you could use those for guidance. > - in the general section, why the reference to cantrip.org? I fail >to see the connection (though deriving virtually from an >interface does have its merits). Also, recommending SAL_NO_VTABLE >for interfaces seems beneficial. > - maybe some words about SAL_DLLPUBLIC_EXPORT/SAL_DLLPUBLIC_IMPORT/ >SAL_DLLPRIVATE in the encapsulation part? I removed the camtrip.org-link. Please feel free to add recommandarions about SAL_NO_VTABLE, SAL_DLLPUBLIC_EXPORT, SAL_DLLPUBLIC_IMPORT and SAL_DLLPRIVATE. > > None of the conventions are obligatory for anybody, of cause, but > > they might make life a bit easier for all (especially for > > newcomers). > Yes, definitely. And well worth getting Writer (and other modules) > closer to this. But I still have mixed emotions about the minutiae > of formatting - why not simply referencing > http://wiki.services.openoffice.org/wiki/Editor_Emacs for people > that use a proper editor, and otherwise acknowledging that code > written by people that have *any* sense of style is generally > perfectly readable? ;) I liked that Emacs operating systems, but installed vim to have a proper editor ;-) . While it is true that code by one person with any sense of style is perfectly readable, it also true that 200 persons with any sense of style working in the same codebase will lead to documents formatted different every five lines, severely reducing readability. Have Fun, Björn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Subversion precommit hook
Hi list,
since we now have subversion, we might as well use the new features it
provides. I wrote a precommit hook on the weekend that does some
precommit sanity checks:
- It rejects commits changing files in a cws and outside of it (thus
hopefully preventing some accidental commits to a master
- It checks all *.{cxx|c|hxx|h} files for correct indentation (no tab
indentation on added/changed lines)
- Adding a new module has to be properly announced in the commit message
- Adding a new toplevel dir in a module has to be properly announced in
the commit message (this hopefully prevents accidental commit of
output trees)
- Never allows changes/deleting of tagged versions
I crucified myself to write the hook in perl because I thought it to be
the preferred language for releng stuff (I would have preferred python
myself).
All checks can be disabled with adding special strings to the commit
message.
Im looking forward to comments, ideas and additions. Is it a good idea
to use such a precommit hook? Whats relengs position on this?
Have Fun,
Björn
#!/usr/bin/perl
use strict;
use warnings;
use Getopt::Long;
#global constants
my $SVNLOOK_CMD="svnlook";
#global vars for checks
my $log_message = ""; # log message of transaction
my @added_files = (); # files added by the transaction
my @deleted_files = (); # files deleted by the transaction
my @updated_files = (); # files updated by the transaction
my @all_files = (); # all files touched by the transaction
my @all_dir = (); # all dirs touched by the transaction
my $error_message = ""; # error message of the precommit hook.
# if no check fails, the string is empty
# If an error occurs append the message
my @checks = (); # add checks to this array
sub check_cws_isolation
{
return if($main::log_message =~ /IGNORE CWS ISOLATION/);
my %touched_cws_hash = ();
foreach my $cws (@main::all_dirs)
{
if($cws =~ s/^cws\/([^\/]+)\/.*$/$1/)
{
$touched_cws_hash{$cws} = 1;
}
elsif(!($cws =~ /^cws\/$/))
{
$touched_cws_hash{"Non-CWS Location"} = 1;
}
}
my @touched_cws = keys(%touched_cws_hash);
if($main::debug)
{
print "DEBUG: touched CWS: @touched_cws\n";
}
if(@touched_cws > 1)
{
$main::error_message .= "cws isolation: Commit touches multiple cws. Do
a seperate commit for each cws.\n";
$main::error_message .= "cws isolation: Touched cws are:
@touched_cws.\n";
$main::error_message .= "cws isolation: Add 'IGNORE CWS ISOLATION' to
log message to force the commit.\n";
}
}
push(@checks, \&check_cws_isolation);
# helper: check if there is a tab-indent in new line
sub check_indentation_from_filediff
{
my @filediff = @_;
return if(@filediff == 0);
my $filename = $filediff[0];
my $nonconforming = "";
$filename =~ s/[^:]+: (.*)$/$1/;
return if(!($filename =~ /^.*\.(cxx|hxx|c|h)$/));
foreach my $line (@filediff)
{
$nonconforming = "true" if($line =~ /^\+\ *\t/);
}
if($nonconforming)
{
$main::error_message .= "indentation: Commit contains new/changed lines
with nonconforming indentation.\n";
$main::error_message .= "indentation: Offending file is: $filename.\n";
$main::error_message .= "indentation: Add 'NONCONFORMING INDENTATION'
to log message to force the commit.\n";
}
}
sub check_indentation
{
return if($main::log_message =~ /NONCONFORMING INDENTATION/);
my @diff_lines = split("\n", exec_svnlook("diff --no-diff-deleted"));
my @one_file_diff = ();
foreach my $line (@diff_lines)
{
if($line =~ /^[A-Za]/)
{
check_indentation_from_filediff(@one_file_diff);
@one_file_diff = ();
}
push(@one_file_diff, $line);
}
check_indentation_from_filediff(@one_file_diff);
}
push(@checks, \&check_indentation);
sub check_new_modules_in_cws
{
return if($main::log_message =~ /NEW MODULE/);
foreach my $new_module (@added_files)
{
if($new_module =~ s/^cws\/([^\/]+)\/([^\/]+)\/$/"$2" in "$3"/)
{
$main::error_message .= "new module in cws: Commit contains a new
module.\n";
$main::error_message .= "new module in cws: new module is:
$new_module.\n";
$main::error_message .= "new module in cws: Add 'NEW MODULE' to log
message to force the commit.\n";
}
}
}
push(@checks, \&check_new_modules_in_cws);
sub check_new_toplevel_in_module
{
return if($main::log_message =~ /NEW TOPLEVEL DIR/);
foreach my $new_topdir (@added_files)
{
if($new_topdir =~ s/^cws\/([^\/]+)\/([^\/]+)\/([^\/]+)\/$/"$3" in
module "$2" in cws "$1"/)
{
$main::error_message .= "new toplevel dir in module: Commit
containing a new toplevel dir in a module.\n";
$main::error_message .= "new toplevel dir in module: new toplevel
dir is: $new_topdir.\n";
$main::e
Re: [dev] SVN-ignored files
On 10/16/08 15:41, Jens-Heiner Rechtien wrote: > [...] There is another reason to use svn:ignore set in the repo: There is no way to check if all of us lazy devs really set the stuff in our local svn config. Having svn:ignore on the output tree dirs should make it extra hard for one lazy/tired dev to do an accidental commit containing an output tree. Have Fun, Bjoern P.S.: If a dev still manages to try this, there are only two things that might stop him: - Threats by releng ;-) - a precommit hook - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] SVN-ignored files
On 10/16/08 11:00, Malte Timmermann wrote: In short: Can we please add the platform-dependent output tree names as svn:ignore property to all modules? +1 +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Writer Code Conventions / Cpp Coding Standards
Hi there, OpenOffice.org has these Coding Standards: http://wiki.services.openoffice.org/wiki/Cpp_Coding_Standards As a new member in the writer team I tried to find some additional conventions that are current (good) practice. The results incorporating the feedback from other members of the writer team can be found here: http://wiki.services.openoffice.org/wiki/Writer_Code_Conventions Since the effort to codify some of the conventions tacitly agreed upon was generally well received, I thought I might post it as a inspiration for all OOo devs. Comments, criticism, discussion and additions are welcome! None of the conventions are obligatory for anybody, of cause, but they might make life a bit easier for all (especially for newcomers). Have Fun, Björn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] SVN Hooks for formatting (was: Re: [dev] VCS Keywords in License Headers)
On 10/06/08 09:57, Caolán McNamara wrote: And subversion (like cvs) has a precommit hook that can e.g. reject files with tabs in them. e.g. http://wordaligned.org/articles/a-subversion-pre-commit-hook +1 I would really appreciate such a hook, I just didnt dare to propose this yet. Have Fun, Björn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
