Re: [dev] Re: CMake
On Fri, 11 Jun 2010 18:55:59 +0200 Michael Stahl michael.st...@sun.com 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
[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 ten...@iseries-guru.com 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: Re: OpenOffice.org Product Development
On Wed, 31 Mar 2010 12:52:18 +0200 Rene Engelhard r...@openoffice.org 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
Re: [dev] Re: Re: OpenOffice.org Product Development
On Wed, 31 Mar 2010 13:52:11 +0200 Rene Engelhard r...@openoffice.org 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: OpenOffice.org Product Development
On Wed, 31 Mar 2010 22:10:54 +0200
Sophie sgautier@free.fr 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
[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 remy...@remyroy.com 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=devmsgNo=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] Coding St{andards|yle}
On Wed, 10 Mar 2010 14:57:12 +0100 Thorsten Behrens t...@openoffice.org 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] Coding St{andards|yle}
On Wed, 10 Mar 2010 15:56:37 +0100 Stephan Bergmann stephan.bergm...@sun.com 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] Problem with building Open Office from mercurial
On Tue, 16 Feb 2010 00:21:36 +0100 Lukasz Szczygielek lszczygie...@gmail.com 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] Problem with building Open Office from mercurial
On Tue, 16 Feb 2010 11:43:41 +0100 Stephan Bergmann stephan.bergm...@sun.com 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] Should assertions abort?
On Fri, 12 Feb 2010 10:30:59 +0200 Rich ric...@nakts.net 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] Should assertions abort?
On Fri, 12 Feb 2010 13:12:08 +0200 Rich ric...@nakts.net 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 12:43:29 +0100 Malte Timmermann malte.timmerm...@sun.com 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 12:34:33 +0100 Christian Lippka christian.lip...@sun.com 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 13:10:01 +0100 bjoern michaelsen - Sun Microsystems - Hamburg Germany bjoern.michael...@sun.com 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_LEVEL2 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 14:38:18 +0100 Philipp Lohmann philipp.lohm...@sun.com 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 17:31:18 +0100 Christian Lippka christian.lip...@sun.com 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] Correction in OO.o Base
On Tue, 09 Feb 2010 17:12:23 +0100 Svatopluk Bláha svatopluk.bl...@quick.cz 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] Test Cleanup
On Mon, 14 Dec 2009 15:06:45 +0100 Stephan Bergmann stephan.bergm...@sun.com 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 arron.x...@gmail.com 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 jaisranj...@yahoo.com 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 frank.schoenh...@sun.com 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
Re: [dev] configure: error: Failed to find some (perl) modules
On Sat, 14 Nov 2009 19:17:40 -0500 Albretch Mueller lbrt...@gmail.com 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] 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
[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 juergen.schm...@sun.com 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] Announcement: Migration to Mercurial
On Tue, 27 Oct 2009 13:04:50 +0100 Christian Lohmaier cl...@openoffice.org 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 14:22:31 +0100 Jens-Heiner Rechtien jens-heiner.recht...@sun.com 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 14:25:40 +0100 Jens-Heiner Rechtien jens-heiner.recht...@sun.com 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
[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
Re: [dev] OpenOffice.org Wiki Categories
On Mon, 26 Oct 2009 13:38:44 +0100 Juergen Schmidt juergen.schm...@sun.com 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
Re: [dev] OpenOffice.org Wiki Categories
On Mon, 26 Oct 2009 14:59:28 +0100 Juergen Schmidt juergen.schm...@sun.com 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
[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: 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: 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]
[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::error_message .= new toplevel dir in module: Add 'NEW
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]
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 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 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 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] 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] 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]
