Re: [tools-dev] EIS CWS AllowedRelease/AllowedTaskTargets Problems
On 22.06.2010 16:52, Philipp Lohmann wrote: Hi, On 6/22/10 2:49 PM, Bernd Eilers wrote: Mathias Bauer wrote: That's exactly what Stephan said: bureaucratic humbug. Well I know we do have some members in an implement_as_you_want_when_you_want_and_dont_care_about_qa-needs_roadmaps_or_documentation camp but I didn´t really expect you two to be in there ;-) Name calling aside: what about issues concerning extensions ? Right now I have to move the target from the correct milestone 1 of an extension to 3.3 or some such to satisfy EIS. Which is kind of bogus. However the CWS should be 3.4 or some such since that marks into which repository code line the CWS will get integrated. one of the objective of extensions was to have an Office independent release schedule. This automatically leads to an own issue tracking and own repository, from my point of view we even can have a simplified development process, since all the cws handling was introduced not to break office code. So I would leave it to the developers of the extension whether they want to have cws or another model. Sane extensions can't break office code ! Extensions, please break out of the Office workspace, Just my 2 cents, pl +2 cent, Martin - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] EIS CWS AllowedRelease/AllowedTaskTargets Problems
On 23.06.2010 00:13, Mathias Bauer wrote: On 22.06.2010 14:49, Bernd Eilers wrote: Mathias Bauer wrote: Hi, Hi, the right solution would be to remove the check. A target milestone is a hint when a particular should be fixed or is planned to be fixed. The same is true for a CWS. If a developers decided to fix an issue earlier or finish a CWS earlier, why should that be marked as failed? Because the data of the issue doesn´t match the data of the CWS and we have an inconsistent state in the tools that document what we are doing. Where is the point of not wanting to also change the issue data if the decision when to fix the issue did change. Why do you want to refuse to document that by changing the issue data. The failed status in this case is just a hint to the developer that there are issues on his CWS which either need to be fixed on another CWS which is based on another codeline or which need to be adjusted to be fixed on another target which might eventually also need an agreement about that with other stakeholders involved. That's exactly what Stephan said: bureaucratic humbug. Well I know we do have some members in an implement_as_you_want_when_you_want_and_dont_care_about_qa-needs_roadmaps_or_documentation camp but I didn´t really expect you two to be in there ;-) That's complete nonsense. Setting a target to an issue or CWS can be done short before or even after a CWS is integrated. If you ever had to change the targets of issues or CWS just because you had set them to the allowed target but then - when the CWS did not make it into the release - had to change it again, you might understand why I think that is bureaucratic humbug. The target release of an issue or CWS *before* it gets integrated is unrelated to what is documented or even to what exactly ends in the release. In a train model you never know the time of arrival exactly before the train really arrives. So a target release is just a declaration of what is aimed for, nothing else. Why else are we retargetting so much issues each and every release? From my experience from the 10 past years we should only set the target milestone when the code actually get integrated. From my point of view we should only set target milestones for regression issues and stoppers only. Nevertheless I think a cws should only be integrated if all issues have the right milestone set, so that we can track with Issuezilla what actually got into the release. Making this random will lead that the target milestone will randomly set. I will set the nomination right anyhow for 3.4 for release management only, so these people will be the only one to fight their bureaucratic humbug theirself :-). Martin Ciao, Mathias - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Re: Building OpenOffice.org with GNU make
Jussi Pakkanen wrote:
On Thu, Feb 11, 2010 at 2:01 PM, Martin Hollmichel
martin.hollmic...@sun.com wrote:
one problem right now is that the usage of linker mapfiles (e.g.
sal/util/sal.map) are not straight supported by cmake, unfortunately all
the
creation of several win32 import libraries are dependent to such
mechanism,
only some of the OOo Libs support the declspec(dllexport) or the Unix
visibility mechanisms. so here some work is required.
I'll try to look into this.
thanks,
I looked into it and got lost in a twisty passage of makefiles, Perl
scripts and lib/a/so files. Could someone give a brief description on
how the system works. Specifically how the different files are
processed and what is finally passed to the linker.
usually I analyse the build logs for understanding these kind of
mechanisms, here's my extract for sal module on Linux:
...
tr -d \015 sal.map | awk -f ./solenv/bin/addsym.awk
../unxlngi6.pro/misc/sal_uno_sal.map
Making: ../unxlngi6.pro/lib/libuno_sal.so.3
g++ -Wl,-z,noexecstack -Wl,-z,combreloc -Wl,-z,defs
-Wl,-Bsymbolic-functions -Wl,--dynamic-list-cpp-new
-Wl,--dynamic-list-cpp-typeinfo -Wl,--hash-style=both
-Wl,-rpath,'$ORIGIN' -Wl,-hlibuno_sal.so.3 -shared -Wl,-O1
-Wl,--version-script ../unxlngi6.pro/misc/sal_uno_sal.map ...
Another question is whether the map files currently solve any problem
that cannot be dealt with native symbol visibility settings?
as the linker script above shows, the option -version script is used,
the reason for this is explained in the ld man page:
Specify the name of a version script to the linker. This is typically
used when creating shared libraries to specifc additional information
about the version hierarchy for the library being created. This option
is only fully supported on platforms which support shared libraries; see
VERSION. It is partially supported on PE platforms, which can use
version scripts to filter symbol visibility in auto-export mode: any
symbols marked local in the version script will not be exported.
e.g. an exerpt from the sal-map file:
...
UDK_3.7 { # OOo 2.4
global:
osl_loadModuleRelative;
} UDK_3.6;
UDK_3.8 { # OOo 3.0
global:
rtl_bootstrap_encode;
rtl_convertStringToUString;
rtl_math_approxValue;
} UDK_3.7;
UDK_3.9 { # OOo 3.1
global:
osl_mapFile;
osl_unmapFile;
osl_readFileAt;
osl_writeFileAt;
rtl_math_expm1;
rtl_math_log1p;
rtl_math_atanh;
} UDK_3.8;
UDK_3.10 { # OOo 3.2
global:
rtl_logfile_hasLogFile;
rtl_math_erf;
rtl_math_erfc;
rtl_math_asinh;
rtl_math_acosh;
} UDK_3.9;
But you're also right, there are also still libraries around where the
native symbol visibilty could (and IMHO should) be used, but this would
require quite a lot manual code changes (many already have been done,
but not all yet),
hth,
Martin
-
To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org
For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Re: Building OpenOffice.org with GNU make
Jussi Pakkanen wrote:
On Wed, Feb 17, 2010 at 11:57 AM, Martin Hollmichel
martin.hollmic...@sun.com wrote:
usually I analyse the build logs for understanding these kind of mechanisms,
here's my extract for sal module on Linux:
...
tr -d \015 sal.map | awk -f ./solenv/bin/addsym.awk
../unxlngi6.pro/misc/sal_uno_sal.map
Making: ../unxlngi6.pro/lib/libuno_sal.so.3
g++ -Wl,-z,noexecstack -Wl,-z,combreloc -Wl,-z,defs -Wl,-Bsymbolic-functions
-Wl,--dynamic-list-cpp-new -Wl,--dynamic-list-cpp-typeinfo
-Wl,--hash-style=both -Wl,-rpath,'$ORIGIN' -Wl,-hlibuno_sal.so.3 -shared
-Wl,-O1 -Wl,--version-script ../unxlngi6.pro/misc/sal_uno_sal.map ...
There seem to be two phases in this. First you generate the target
file with awk and then pass it to the linker. The first one is
straightforward.
The latter is a bit trickier but not very hard. First you set a
dependency between the shared library and the generated version file.
Then you need to pass the file to the linker. CMake allows you to
define custom linker flags per target. To get the above you would add
something like this:
set_target_properties(sal PROPERTIES LINK_FLAGS -Wl,--version-script
${GENERATED_SAL_MAP_FILE})
the process for Windows (MSVC) is very similar, I already invented a
function add_mapfile(libname map) to do the job. I guess this
approach will work for all other platforms as well.
thanks,
Martin
-
To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org
For additional commands, e-mail: dev-h...@tools.openoffice.org
-
To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org
For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Re: Building OpenOffice.org with GNU make
Jussi Pakkanen wrote: On Wed, Feb 10, 2010 at 9:00 PM, Martin Hollmichel martin.hollmic...@sun.com wrote: yes, thank you, I used and modified some of your work (add_idl_db and build_rdb_from db functions) and added a more modules (up to rsc now). A word of warning: the functions I have written to deal with javamaker etc are broken. They work when run the first time but not the second time. I did not have the time and energy to debug them, I just wanted to get some sorts of results. as I said, I modified them to make them finally work :-) one problem right now is that the usage of linker mapfiles (e.g. sal/util/sal.map) are not straight supported by cmake, unfortunately all the creation of several win32 import libraries are dependent to such mechanism, only some of the OOo Libs support the declspec(dllexport) or the Unix visibility mechanisms. so here some work is required. I'll try to look into this. thanks, Martin - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Re: Building OpenOffice.org with GNU make
Martin Hollmichel wrote: There's also the dmake - cmake converter script so you don't have to keep writing the files by hand. from what I've learned from cmake so far, it seems the best idea to do an 1:1 conversion since this might lead to too much targets (and thus dependencies) and writing CMakeLists.txt seem in some cases lead to more efficient makefiles. of course this should read as it seems _not_ the best idea, to do an 1:1 conversion, Martin - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Re: Building OpenOffice.org with GNU make
Jussi Pakkanen wrote: On Mon, Jan 11, 2010 at 8:11 PM, Martin Hollmichel martin.hollmic...@sun.com wrote: I started some time ago a cmake prototype for OOo in my spare time (http://hg.services.openoffice.org/hg/cws/mh6bc/) for the latest status please see the latest ReadMe.txt in the Source root for the most recent status). You're invited to join this prototype, but be warned: it does not work and kills your cat when try to run that :-). You might want to look look at my attempt: http://lists.freedesktop.org/archives/ooo-build/2009-August/000181.html yes, thank you, I used and modified some of your work (add_idl_db and build_rdb_from db functions) and added a more modules (up to rsc now). It goes quite a lot further and solves some of the issues listed in your readme (detecting STLPort and Boost, etc). for the moment the external libraries are not in my main focus, There's also the dmake - cmake converter script so you don't have to keep writing the files by hand. from what I've learned from cmake so far, it seems the best idea to do an 1:1 conversion since this might lead to too much targets (and thus dependencies) and writing CMakeLists.txt seem in some cases lead to more efficient makefiles. one problem right now is that the usage of linker mapfiles (e.g. sal/util/sal.map) are not straight supported by cmake, unfortunately all the creation of several win32 import libraries are dependent to such mechanism, only some of the OOo Libs support the declspec(dllexport) or the Unix visibility mechanisms. so here some work is required. Martin - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Re: Building OpenOffice.org with GNU make
Mathias Bauer wrote: Jussi Pakkanen wrote: On Mon, Jan 11, 2010 at 7:57 PM, Thorsten Behrens t...@openoffice.org wrote: functionality? Even if CMake eventually turns out to be too slow, would it not make more sense to write your own custom CMake back end rather than the configuration/generation front end? I guess it's now my turn to ask for sample code here. ;) For a backend? No, sorry. I have never looked into that. But the issue raised earlier was that because CMake's Makefiles are recursive (or something) they are too slow, probably because automake does it this way and is slow. I personally do not think this will be an issue. When running on Windows, the time taken by makefiles when changing directories is insignificant compared to the time taken by the compiler. But I have only tried it under Virtualbox and not at all thoroughly. The problem is not because the makefiles are recursive. The problem is that it looks if CMake does not offer a way to include all makefiles of the whole project (or at least larger parts of it if you think about a split build) into a single process without clashing of target names. I can imagine that there might be a clashing of target names in a 1:1 transistion from makefile,mk to other makefiles, but I general I would consider the existance of target name clashes as a brain node (aka bug) which should be solved easy. So the only way to reuse CMake makefiles for a complete build is recursively calling them or - as we do today in OOo - serialize the process. I don't think that this is a matter of performance per se, it's just that the benefit is missing we wanted to get from the new single make process approach. no need to have this if you have unique targets, I guess ? Regards, Mathias Martin - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Re: Building OpenOffice.org with GNU make
Hi, I think it's cleaner, and there's definitely not much (should I say any?) redundancy left. Additionally, one can enhance the script to generate makefiles for pretty much every make tool of this world, including eclipse/netbeans/visual studio project files. I would like to point out that what you are doing is generating your own language and a build tool/generator based on that. There's nothing wrong with it as such, but this is reinventing the wheel again (just like Google's GYP). Instead of custom dmake/build.pl you would have custom gnumakegen/gnumake_or_something. What is the benefit you get from this instead of using something like CMake that already has a mature implementation of this functionality? Even if CMake eventually turns out to be too slow, would it not make more sense to write your own custom CMake back end rather than the configuration/generation front end? I second the demand for simple, readable description files. ath the first glance, this seem very easy with cmake, it was fun prototyping this on Linux for the OOo tool-chain up to the idlc. regmerge level. A lot of writing could be saved in comparisons to Ooo current build system. during the prototyping I also was surprise about all the stuff we're doing in Ooo's makefile's (some superfluous, some really needed) and I was surprised that much of the stuff already is covered by cmake (just proved by reading the documentation, not all tested in reality). Things are getting a bit more complicated, if you're looking on some old grown specialties of OOo, e.g the generations of import libraries on Win32. At some stage it is useful, if not even required to have an cmake expert with the OOo project who can determine with some experience how and where to implement such one-off's of OOo. so we still have three valid alternatives: * renew and modernize our old dmake environment * re-write the build environment with a more modern tool and use some more modern patterns * reuse and enhance already abstract buildenv like cmake. I'm not yet sure what will be the best way to go. For further information here is a Google Tech Talk about CMake and all related things (testing, code coverity, packaging, etc, etc) by one of the creators. If the build tool decision is not yet final, it is worth watching. The CPack and CTest enhancements of cmake are indeed quite impressive, a transition from scp to CPack would be very interesting (and kicking build.pl / deliver.pl and solver at the same time). I started some time ago a cmake prototype for OOo in my spare time (http://hg.services.openoffice.org/hg/cws/mh6bc/) for the latest status please see the latest ReadMe.txt in the Source root for the most recent status). You're invited to join this prototype, but be warned: it does not work and kills your cat when try to run that :-). Martin - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] requirements for a Windows build bot and cws box
Martin Hollmichel wrote: Hi, finally I come to the following proposal: 1 virtual machine running a Windows7 64bit instance with Visual Studio Standard installed for the Windows tinderbox. 2 additional virtual windows machines available for Developers, with the Express Version installed. In case we discover that we need more parallel sessions available, we consider the installation of Windows Server. the Virtual Boxes will be hosted on a Quad Core, 12 GB RAM machine in a data center any comments ? Martin http://wiki.services.openoffice.org/wiki/Community_Council/Funding_And_Budgets/Developer/WindowsBox#Proposal_for_a_Windows_Box Pavel, Thorsten, you may want to comment or approve these spendings for the developer budget ? Martin Martin Hollmichel wrote: All, I got a request to do some funding for a Windows build bot (to be funded be the OOo project, not by Sun as my mail adress suggest). build bots are now integrated in the EIS and are of invaluable help for development and QA. I can think of several scenarios: minimal buildbot: a virtual windows (home) instance on some already existent hardware plus a MS Compiler professional license (estimated cost: ca. 1000 € once). fast build bot: windows box on bare iron or virtualized in a hosting center with good bandwidth for providing install sets (my estimated extra costs: ca. 1200 € per year extra) fast developer machine: windows server allowing up to five 5 users, allowing remove building and debugging for developers with no windows access, several build bot instances (i have no real idea for the estimated hosting and license costs). Two questions: * what are our real demands and requirement for such a thing. * is there anyone volunteering for collecting real prices and costs for the various scenarios and maintaining the resulting setup ? Martin - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
[tools-dev] requirements for a Windows build bot and cws box
All, I got a request to do some funding for a Windows build bot (to be funded be the OOo project, not by Sun as my mail adress suggest). build bots are now integrated in the EIS and are of invaluable help for development and QA. I can think of several scenarios: minimal buildbot: a virtual windows (home) instance on some already existent hardware plus a MS Compiler professional license (estimated cost: ca. 1000 € once). fast build bot: windows box on bare iron or virtualized in a hosting center with good bandwidth for providing install sets (my estimated extra costs: ca. 1200 € per year extra) fast developer machine: windows server allowing up to five 5 users, allowing remove building and debugging for developers with no windows access, several build bot instances (i have no real idea for the estimated hosting and license costs). Two questions: * what are our real demands and requirement for such a thing. * is there anyone volunteering for collecting real prices and costs for the various scenarios and maintaining the resulting setup ? Martin - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] requirements for a Windows build bot and cws box
bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote: On Wed, 07 Oct 2009 15:19:55 +0200 Martin Hollmichel martin.hollmic...@sun.com wrote: All, I got a request to do some funding for a Windows build bot (to be funded be the OOo project, not by Sun as my mail adress suggest). build bots are now integrated in the EIS and are of invaluable help for development and QA. I can think of several scenarios: [...] fast developer machine: windows server allowing up to five 5 users, allowing remove building and debugging for developers with no windows access, several build bot instances (i have no real idea for the estimated hosting and license costs). Two questions: * what are our real demands and requirement for such a thing. * is there anyone volunteering for collecting real prices and costs for the various scenarios and maintaining the resulting setup ? IMHO, mixing buildbots and debugging on one machine is just asking for trouble. If there is a need for both and funding is available those should be two separate boxes (or at least two separate virtual boxes). ok, running the developer machine in a virtual environment should not be the problem. I know it might be tempting for licensing reasons (*) to use just one machine, but I really think it wouldnt work in practice. the main objective is to be in compliance with the licenses, that's why I am asking for reasonable configurations. Once we know about the costs for the various configuration we can decide what will be the most appropriate to choose. Best Regards, Bjoern Martin (*) BTW: Are there even CALs available for Visual Studio? - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] requirements for a Windows build bot and cws box
Herter, S. wrote: If you are going to do the build bot as a virtual machine, would it be possible to make the VM image(s) available to third parties? In theory this should be possible if you have the required licenses for those images. But I personally have not enough knowledge about the MS technologies if it is possible to ensure that an valid license will be verified for those images. Maybe some expert is around who is able to answer this question ?! We redistribute OpenOffice with our product unmodified. We download a copy of the source for the version we are redistributing so that we can be in compliance with the licensing. Back when 2.x first shipped we tried to get a Windows build going but not having someone who could devote full time to it we spent months working on it off and on but never got it working. It would be a huge help to small companies like us if we could download a VM image of a build environment we could use to build OpenOffice. That way we can be sure that the source we have matches the version we are redistributing. Having a build environment we could work with locally would also make it easier to try and fix any problems we find on our own rather than file a bug report and pray. Thanks. Martin - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
[tools-dev] should we drop gcc3 support ?
Hi, obviously OOo doesn't compile any longer with gcc3, see http://qa.openoffice.org/issues/show_bug.cgi?id=95511, should we now officially drop gcc3 ? Martin - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
[tools-dev] Re: [dev] Mercurial-Implementation: OOo domain developer public keys
Jan Holesovsky wrote: Hi Heiner, On Friday 28 August 2009, Jens-Heiner Rechtien wrote: Please contact me if you have problems, suggestions etc. Actually, I have a suggestion ;-) Do you think - with the switch to Mercurial - would it be possible to stop using the 'CWS' and 'MWS' terminology, and instead switch to the commonly used 'feature branch' and 'release branch' terms? +1, Martin Thank you, Kendy - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] EIS2 Source code link
Per Eriksson wrote: Hello, Maybe we should change the Source code link in EIS2 to point here instead? http://svn.services.openoffice.org/ooo/ I would like to remove this links in EIS in general, looks like another redundant entry point, Martin This page (as far as I know) provides more navigation through tags, cws'es etc. than opengrok. http://svn.services.openoffice.org/opengrok/xref/ Anyway CVS should be left, or marked as used for other versions. http://projects.openoffice.org/source/browse/ Maybe a complete page with all these three links should be provided? Best Per - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Re: EIS2 Source code link
Bjoern Michaelsen wrote: Martin Hollmichel mh at openoffice.org writes: I would like to remove this links in EIS in general, looks like another redundant entry point, While we at that, could we also remove the Administration section? It only contains broken links. at least for me some of the links are working (and I need them for some EIS administration work) but +1 for removing the not working links, Best Regards, Bjoern Martin - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
[tools-dev] Re: OOo Mercurial pilot
Jens-Heiner Rechtien wrote: Hi, time to start the OOo Mercurial pilot. Please find the details here: http://wiki.services.openoffice.org/wiki/Mercurial_Pilot unfortunately I didn't find any time yet to join the pilot, do I have still have some time to participate ? But anyhow, I have read only few comments about the pilot, maybe somebody from the participants can give a short summary about the status of the pilot ? Are there still any open issue we have to resolve (bonsai/cws query), do we need to do some more preparation for the transition ? Martin - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Adding PDF import extension
Alan, for this question I would ask Ingo on the d...@installation list. may I ask for the motivation to include the pdf import extension by default ? Martin Alan Yaniger wrote: Hi list-members, I'm trying to add the PDF import extension to my Windows build of OOo 3.1. It's causing the installation to hang. Below are the changes I made to the source tree. What am I doing wrong? Thanks, Alan diff scp2/source/ooo/module_hidden_ooo.scp /cygdrive/c/OOO310_m11/Clean/scp2/source/ooo/module_hidden_ooo.scp 1235,1244d1223 Module gid_Module_Root_Extension_PDFImport Name = gid_Module_Root_Extension_PDFImport; Description = gid_Module_Root_Extension_PDFImport; Files = (gid_File_Bin_pdfimport); InstallOrder = 2000; PackageInfo = packinfo_office.txt; ParentID = gid_Module_Root; Styles = (HIDDEN_ROOT); End diff scp2/source/ooo/file_ooo.scp /cygdrive/c/OOO310_m11/Clean/scp2/source/ooo/file_ooo.scp 3171,3177d3161 File gid_File_Bin_pdfimport Dir = gid_Brand_Dir_Share_Extension_Install; Styles = (PACKED); UnixRights = 444; Name = pdfimport/pdfimport.oxt; End diff setup_native/source/packinfo/packinfo_office.txt /cygdrive/c/OOO310_m11/Clean/setup_native/source/packinfo/packinfo_office.txt 639,670d638 module = gid_Module_Root_Extension_PDFImport script = shellscripts_extensions.txt solarispackagename = %PACKAGEPREFIX%WITHOUTDOTUNIXPRODUCTNAME%BRANDPACKAGEVERSION-pdfimport solarisrequires = %SOLSUREPACKAGEPREFIX-ure (Name=UNO Runtime Environment), %BASISPACKAGEPREFIX%WITHOUTDOTOOOBASEVERSION-core01 (Name=Core module for %PRODUCTNAME %PRODUCTVERSION), %BASISPACKAGEPREFIX%WITHOUTDOTOOOBASEVERSION-core02 (Name=Core module for %PRODUCTNAME %PRODUCTVERSION), %BASISPACKAGEPREFIX%WITHOUTDOTOOOBASEVERSION-core03 (Name=Core module for %PRODUCTNAME %PRODUCTVERSION), %BASISPACKAGEPREFIX%WITHOUTDOTOOOBASEVERSION-core04 (Name=Core module for %PRODUCTNAME %PRODUCTVERSION), %BASISPACKAGEPREFIX%WITHOUTDOTOOOBASEVERSION-core05 (Name=Core module for %PRODUCTNAME %PRODUCTVERSION), %BASISPACKAGEPREFIX%WITHOUTDOTOOOBASEVERSION-core06 (Name=Core module for %PRODUCTNAME %PRODUCTVERSION), %BASISPACKAGEPREFIX%WITHOUTDOTOOOBASEVERSION-core07 (Name=Core module for %PRODUCTNAME %PRODUCTVERSION), %PACKAGEPREFIX%WITHOUTDOTUNIXPRODUCTNAME%BRANDPACKAGEVERSION (Name=Brand module for %PRODUCTNAME %PRODUCTVERSION) packagename = %UNIXPRODUCTNAME%BRANDPACKAGEVERSION-pdfimport requires = %UREPACKAGEPREFIX-ure,%BASISPACKAGEPREFIX%OOOBASEVERSION-core01,%BASISPACKAGEPREFIX%OOOBASEVERSION-core02,%BASISPACKAGEPREFIX%OOOBASEVERSION-core03,%BASISPACKAGEPREFIX%OOOBASEVERSION-core04,%BASISPACKAGEPREFIX%OOOBASEVERSION-core05,%BASISPACKAGEPREFIX%OOOBASEVERSION-core06,%BASISPACKAGEPREFIX%OOOBASEVERSION-core07,%UNIXPRODUCTNAME%BRANDPACKAGEVERSION linuxpatchrequires = copyright = 1999-2007 by Sun Microsystems solariscopyright = solariscopyrightfile vendor = Sun Microsystems, Inc. description = Extension for importing PDF files - fom Sun - beta version destpath = /opt packageversion = %PACKAGEVERSION End - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
[tools-dev] DSCM - next step, start mercurial pilot
Hi *, The ESC meeting agreed more than a year ago to migrate OpenOffice.org's version control from CVS via subversion towards an distributed source code managment (DSCM) system. The ESC is also in agreement that right now git and mercurial are both systems which are able to fulfil the requirements we have but there is no vast majority towards one of the systems. This is no real surprise since also other projects still don't show a clear favorite. The ESC also is in agreement that we should migrate now or in the very near future we can not afford to wait which system will win the race. Since the release engineering team is in favor of mercurial I ask - as the tools project lead - the RE team to start the pilot for mercurial now so that we will be able to have the new DSCM available with the 3.2 release. This is not an easy decision. But we had the choice, this was possible by the availability of the free, open source projects bzr, git and mercurial. Thanks to them and the teams that worked on the evaluation for an migration to OpenOffice.org. This is not a decision against one of them because of technical concerns, it is a pragmatic decision, Martin - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] SVN and email notifications (resend)
Jens-Heiner Rechtien wrote: Hi Stefan, Email notifications can be implemented with the post-commit hook. We'll implement that. Is there any help needed with this ? Since life is now in the svn repository we need this, Heiner Martin Stefan Taxhet wrote: Hi, will we see email notifications of commits to the SVN repository? The list [EMAIL PROTECTED] is waiting for messages... ;-) Greetings Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo SCM project
Jörg Jahnke wrote: Hi, due to the trunk-only migration mentioned below, we do no longer have a dependency on the first release candidate of OOo 3.0, which is done on the OOO300 branch. At the same time, Heiner is ready to start the migration. So do we want to start the migration now i.e. prior to the RC? from my point of we don't need to wait for the release candidate to proceed with the migration as we decided to go with the trunk migration only (see http://wiki.services.openoffice.org/wiki/Scm_migration_scope). If nobody objects I would ask you to provide a concrete plan for the migration starting asap. Regards, Jörg Martin Jens-Heiner Rechtien schrieb: Hi, Jens-Heiner Rechtien wrote: Hi Guido, the migration is going nicely along. We do plan to migrate after the 3.0 RC. - We've got a box, a Sun Fire 4150 (8 cores, 64 GB RAM, no less). The URL will be svn.services.openoffice.org. An updated test repository will be on that machine RSN. - We'll use Subversion 1.5.1, that is with the build in merge tracking - The ESC council decided after some debate about the migration scope, aka how much history do we want (http://wiki.services.openoffice.org/wiki/Scm_migration_scope) We will go along with option c) trunk only, this will also help with later DSCM options. Some asked, so I probably should explain it in a bit more detail what we mean with trunk only migration: - only history on the main development line (trunk) will be migrated, thus no branches and tags - we'll migrate only files which are still active (nothing from the CVS Attic directories) - binary files will be pruned to the last version - Localization files (*.sdf) will be pruned to the last version Existing branches will be maintained in CVS. This includes the OOO300 branch, on which OpenOffice.org 3.0 will be released. Heiner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] resyncs to invalid MWS - bug in EIS/cws tools? Mistake by EIS admins/privileged users?
I also already wondered about xsltfilter10, Kurt wanted to do some investigation on how this could happen, Martin Christian Lohmaier wrote: Hi *, several cws have been resynced to an invalid master milestone, namely OOO300 line with m23, m28, m29 for example. Those masters don't exist yet (We're at OOO300_m2 currently) So who's at fault here? Admins who can set any arbitrary value bypassing the checks, or are the checks broken by themselves? from tinderbox' tag-list (which tinderbox gets from EIS via SOAP - checking e.g. pflin11 shows this data is matching that in EIS web-UI): xsltfilter10 : OOO300_m23 : cws_dev300_xsltfilter10 : beanshell config_office external filter odk officecfg oovbaapi rhino scp2 solenv swext wizards xalan : stax saxon hrovista2 : OOO300_m28 : cws_bea300_hrovista2 : desktop extensions fpicker sal sfx2 : dba31a : OOO300_m28 : cws_dev300_dba31a : comphelper connectivity dbaccess default_images filter forms framework offapi officecfg reportdesign sc scp2 solenv svtools svx sw testautomation vcl wizards xmloff : pflin11 : OOO300_m29 : cws_dev300_pflin11 : basic sc : How could this happen? Will this continue to happen? ciao Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo SCM project
Heiner, will there be any additional tools or documentation necessary of will our cws tools will wrap this completly ? Martin Jens-Heiner Rechtien wrote: Hi, an updated repository acording to (http://wiki.services.openoffice.org/wiki/Scm_migration_scope) is avaiable via: svn checkout svn://svn.services.openoffice.org/ooo/trunk or svn checkout svn+ssh://[EMAIL PROTECTED]/ooo/trunk for those who send me a ssh public key for the o3-build machine Heiner Jens-Heiner Rechtien wrote: Hi Guido, the migration is going nicely along. We do plan to migrate after the 3.0 RC. - We've got a box, a Sun Fire 4150 (8 cores, 64 GB RAM, no less). The URL will be svn.services.openoffice.org. An updated test repository will be on that machine RSN. - We'll use Subversion 1.5.1, that is with the build in merge tracking - The ESC council decided after some debate about the migration scope, aka how much history do we want (http://wiki.services.openoffice.org/wiki/Scm_migration_scope) We will go along with option c) trunk only, this will also help with later DSCM options. I'll keep you posted here. Heiner Guido Ostkamp wrote: Hello, State of the OOo SCM project We plan to switch over to Subversion in the second half of July. the second half of July is nearly over and I haven't heard any news regarding the final switch to SVN since that discussion in early June. Is it going to happen? Regards Guido - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo SCM project
Guido Ostkamp wrote: Hello, State of the OOo SCM project We plan to switch over to Subversion in the second half of July. the second half of July is nearly over and I haven't heard any news regarding the final switch to SVN since that discussion in early June. Is it going to happen? In last ESC meeting (http://wiki.services.openoffice.org/wiki/ESC_meeting_minutes_20080703#CVS_to_svn_migration:) is was agreed to schedule the migration after the release candidate of 3.0, unfortunately we already slipped a bit with the 3.0 release so the migration will not happen in July. On the other hand I also would be interested in the current status of the migration, is all well prepared, is there a staging server available for the repository, can we have a look in advance etc, Regards Guido Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] Trouble building DEV300_m6: stops in filters
please see issue 87925 for this, Martin Giuseppe Castagno wrote: Hi all, I'm trying to build dev300_m6 on Linux Debian lenny. It stops while building the module filter with: Building packages others ../../../unxlngi6.pro/misc/filters/fcfg_drawgraphics.others_flag === mkdir -p ../../../unxlngi6.pro/misc/filters/modulepacks /usr/bin/java -jar ../../../unxlngi6.pro/class/FCFGMerge.jar fragmentsdir=. tempdir= outdir=../../../unxlngi6.pro/misc/filters/modulepacks pkg=../../../unxlngi6.pro/misc/filters/modulepacks/fcfg_drawgraphics_others.xcu xmlpackage=Misc lcfg=/tmp/mkChGJEV ccfg=/tmp/mkHwqd9T touch ../../../unxlngi6.pro/misc/filters/fcfg_drawgraphics.others_flag 3a4,30 style:page-layout style:name=page-layout2 style:page-layout-properties fo:margin-bottom=10mm fo:margin-left=10mm fo:margin-right=10mm fo:margin-top=10mm fo:page-height=297.03mm fo:page-width=209.9mm style:print-orientation=portrait style:writing-mode=lr-tb /style:page-layout-properties ... a bunch of other xml like stuff and then ends with this: /draw:text-box /draw:frame draw:frame draw:style-name=graphic5 draw:transform=translate( 91.75mm 240.48mm ) draw:z-index=23 svg:height=-10.59mm svg:width=26.45mm text:anchor-page-number=1 text:anchor-type=page draw:image office:binary-data ... /office:binary-data /draw:image /draw:frame dmake: Error code 1, while making '../../../../unxlngi6.pro/misc/graphicformats_pdfi_unittest_writer_succeeded' ERROR: Error 65280 occurred while making /home/beppe/ooo-b/dev300-m6-std/build/current/filter/source/pdfimport/test/testdocs Java is 1.5, gcc is gcc (GCC) 4.2.3 (Debian 4.2.3-3) Any idea? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] Windows Compiler Versions
Martin Hollmichel wrote: There are also the Windows (Platform SDK's, also available as free download) * v5.0 ( just SDK header and Libraries) * v6.0 comes additionally with the C/C++ Compiler 14.00.50727 for x86 * v6.1 comes addtionally with the C/C++ Compiler 15.00.20706 for x86, this one is the compiler also available with Visual Studio 9.0 Beta. As for some feature for Windows Vista at least the SDK v6.0 is rquired, I would like to propose: - after the creation of the OOH680 code line for 2.4 release, we switch from 2003 to 2005 Compiler as default for the Developer Snapshots on the SRC680 code line. If that seems to be feasible, drop the support of the 2003 Compiler after 3.0 release. Is there any need to continue the support of the older SDK's ? Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] overhaul the windows symbol-ordinal mapfile system (known as def-files)
Hi, Vladimir was speeking about an increase of 3M of the install set due to exported sysmbol, how much will this be once the Office got installed ? Martin Jörg Jahnke wrote: Hi, to elaborate a bit more: There were concerns that using symbols instead of ordinals might lead to a significant performance loss during startup. Vladimir's performance measurements (see https://tools.services.openoffice.org/EIS2/cws.Attachment?cmd=readId=6381Filename=performancetest%20[%2018.%20Feb%202008,%2013:35%20(Windows%20XP)%20]) indicate that we would lose less than 2% speed on startup. IMO this is acceptable and we should thus get rid of building with ordinals. Any objections? Regards, Jörg Vladimir Glazounov schrieb: Hi all, because I investigated the case, I blogged about the theme here: http://blogs.sun.com/GullFOSS/entry/linking_office_libraries_for_win32 All comments are welcome. Vladimir Martin Hollmichel wrote: Hi, I just found at http://wiki.services.openoffice.org/wiki/OOo30_release_engineering_planned_changes that we plan to change the export by ordinal for windows. What is planned for OOo 3.0 ? Export by name or by alias ? Can you elaborate on this ? Is there an Issue or other documentation available ? Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo source split
Jan Holesovsky wrote: Hi Mathias, On Friday 12 October 2007 20:18, Mathias Bauer wrote: just stumbled about that the report design extension is built during the regular build process, wouldn't it be better at all to create a source tarball include jfreereport and reportdesign modules. Where we already achieved modularization in the sources we should IHMO also do the right packaging of sources, +1! What already is separated shouldn't become munged with the rest. We know how fast the separation can get lost. :-) I am a bit confused here - I thought that jfreereport was not JCA covered [though LGPL], so bundling it together was not what would you want on the source level? yes, two packages would be required. Either way, from my point of view it is plain 3rd party stuff, so I'd like to let it in ooo-libs-3rdparty. To avoid reportdesign intergrowth with Base, maybe ooo-apps-extensions would be the better option for reportdesign, what do you think? I don't understand why you want to create superbundles again, even if a more fine granular packaging is possible. Why should I care about jfreereport if I don't want to build any extension but just the core product ? Regards, Jan Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OOo source split
Jan Holesovsky wrote: Eg. the spellchecker (hunspell) itself is in the lingucomponent which I propose to put to ooo-apps-extensions (and thus to ship it together with the application). The dictionaries for it are in ooo-libs-3rdparty/dictionaries - the distros have their own packages, but it still must be possible to build with the internal ones. I'd prefer to treat the dictionaries as an own package and not to bundle them in a super-source-package ooo-libs-3rdparty package again. If we have meaningful smallest possible packages we should go with them. Regards, Jan Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] source code analysis
Hi Kay, just found as information in other patch issue a reference to project which also is doing source code analysis: http://oopp.multiracio.com/ I think we probably should also list them in http://wiki.services.openoffice.org/wiki/Other_Tools Martin Martin Hollmichel wrote: Hi Kay, I just stumbled about a patch of you where you mention your wiki page: http://wiki.services.openoffice.org/wiki/Architecture/Source_Code_Inventory and a Axivion source code analyzer; can you tell us more about this project ? Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] o3-build: X-libs not found when building bean, glib not found when building headless vcl-plugin
Christian Lohmaier wrote: Hi *, As mentioned in an earlier post, I'm trying out o3-build within a minimal chroot install. That chroot has no X11 installed, so it relies on the stuff o3-build provides. The build breaks at bean module, because checkdll cannot find various X-libraries. When trying to build m214, configure auto-enables the headless plugin, but the build then fails in vcl because it cannot find libglib. The wiki page mentions that the /o3/lx_ia32/lib must not be in LD_LIBRARY_PATH and the LDFLAGS - and that seems to be the reason for this breakage As a workaround I symlinked the following libs to solver/680/unxlngi6.pro/lib/: /o3/lx_ia32/lib/libXp.so.6 /o3/lx_ia32/lib/libXt.so.6 /o3/lx_ia32/lib/libXext.so.6 /o3/lx_ia32/lib/libXtst.so.6 /o3/lx_ia32/lib/libX11.so.6 /o3/lx_ia32/lib/libSM.so.6 /o3/lx_ia32/lib/libICE.so.6 /o3/lx_ia32/lib/libglib-2.0.so.0 I'm not sure whether checkdll or the bean/vcl modules is at fault here. If not, I suggest putting (symlinking) these libs to a workaround libpath that can be added to LD_LIBRARY_PATH/LDFLAGS to avoid the need for this workaround. (taking the libraries from the system would be pointless, since the point in using o3-build is to have a common build-environment that generates the same instsets, no matter on what machine it was built) Initially I had the assumption that the machine which is used for building has also all prerequisites installed required for running the binary finally. Gerd's try on ubuntu server already showed that this is not true at all, so I need to go the way to come also with a X11 baseline. It will take a few days until I can provide an update, since my vmware images for SuSe73 crashed, I need to reconstruct my Suse73 system first. ciao Christian Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[tools-dev] using a distributed SCM cross corporate networks
Hi, I just stumbled about how to use git in our corporate network (tried freecap on Windows) and failed. I wondered then at all if a distributed SCM makes sense at all if many developers are located in corporate networks, so access to distributed repositories might be difficult or need extra infrastructure. Are there already any thoughts on that ? Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] using a distributed SCM cross corporate networks
Jan Holesovsky wrote: Hi Martin, On Tuesday 24 April 2007 11:12, Rene Engelhard wrote: I wondered then at all if a distributed SCM makes sense at all if many developers are located in corporate networks, so access to distributed repositories might be difficult or need extra infrastructure. Are there Depends on how the distributed SCM does work (I don't know how git works). If it's able to work over ssh or http (as baz/br, but those are awfully slow with big things) there shouldn't be a problem, as ssh and http should be allowed for outgoing Should I enable http:// access to go-oo.org/git? this might ease things a bit, but nonetheless if I want to give you access to my repository, I need to set up a repository which can be access outside the corporate network, Regards, Jan Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] using a distributed SCM cross corporate networks
Thorsten Behrens wrote: Jan Holesovsky [EMAIL PROTECTED] writes: Should I enable http:// access to go-oo.org/git? Dunno what went wrong for Martin - I was able to clone your repo from within Sun. which platform did you use, I was trying on Windows, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] [OT] Re: [tools-dev] using a distributed SCM cross corporate networks
Some of the clones might be public, eg. ooo-build. if people agree on a push back, only some of the clones needs to be public, if this should be a pull back public access gets a problem. so right now it is no problem to access a cws which has not been integrated yet and can e.g. do something like tinderbox builds on it. The other way round hides all development behind corperate firewalls. Is this something we really want to do ? Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] [OT] Re: [tools-dev] using a distributed SCM cross corporate networks
Jan Holesovsky wrote: Hi Martin, On Tuesday 24 April 2007 15:48, Martin Hollmichel wrote: Some of the clones might be public, eg. ooo-build. if people agree on a push back, only some of the clones needs to be public, if this should be a pull back public access gets a problem. so right now it is no problem to access a cws which has not been integrated yet and can e.g. do something like tinderbox builds on it. The other way round hides all development behind corperate firewalls. Is this something we really want to do ? I'm not sure that I understand you... CWS is not visible until the developer does 'cvs commit', the git branch is not visible until the developer does 'git push' to the public repository. What is the difference? In CVS it is just one step to publish: cvs commit, if I understand git right, this is two step process: commit and push, I'm just wondering how much delayed code drop events we will get with this process. Esspecially if you think of some staggered development practices. Regards, Jan Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] Some data about the git tree...
Hi, Jan Holesovsky wrote: Hi, I've updated the http://wiki.services.openoffice.org/wiki/Git page, mainly the times of checkout/merge/etc. http://wiki.services.openoffice.org/wiki/Git#Comparison Thank you for the comparision. I think some rows in the table need some more explanation (e.g. which are the 3rd party modules, which commands actually have been used, etc.) and me be one can think of some missing items (resync, integration) I'll try to collect the data at least for CVS as well. Will you still do or should we look for some other volunteers ? Regards, Jan Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] 2.0.4 one install RPM
Hi, Vitor Domingos wrote: Hi, Is there any way to build only on RPM for the Linux install, rather than the multiple rpms and desktop-integration ? This has been a glitch on linux installations. I think you mean one rpm instead of having a whole bunch of them ? AFAIK this is not possible, what kind of a glitch do you mean ? Thanks. Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[tools-dev] Re: [qa-dev] status of o3-build iso image
Kirill S. Palagin wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 15, 2006 1:27 PM The next major steps for this project are: * make it also possible for the Windows platform That would be just great!! This will be not so easy as on Linux because we can't redistribute all of the Microsoft stuff. But I'm quite confident that we can ease the pain ;) Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] Building 2.0.3 on Linux: stlport fails
Hi, I'm playing a similar game with a preconfigured environment (http://wiki.services.openoffice.org/wiki/O3-build) and have the same problem with g++-3.4.1 and binutils-2.17 and no problem with g++-4.1.1 and binutils-2.17. Is there a recommended binutils version if I would like to have the option to choose between both compiler versions. Or might it be a better idea to configure the compiler with a specific binutils version ? Martin Simon Brouwer wrote: Hi all, Update: I think I encountered this problem because I was playing safe, at configuration specifying gcc and g++ version 3.3 because the build guide reported success with those. However, these may not be compatible with the (newer?) binutils 2.16.1 on my Ubuntu installation. I am building with the default gcc/g++ 4.0 now and so far it looks good. [EMAIL PROTECTED] schreef: Hi all, I am trying to build OOo 2.0.3 on the latest Ubuntu. Configure went OK, but the build stops in stlport. The last output is: cd ./unxlngi4.pro/misc/build/STLport-4.5/src make -f gcc-3.0.mak -j1 touch so_built_so_stlport /usr/bin/g++-3.3 -Wl,-rpath,'$ORIGIN' --fexceptions -shared -o ../lib/libstlport_gcc.so.4.5 ../lib/obj/GCC/ReleaseD/dll_main.o ../lib/obj/GCC/ReleaseD/fstream.o ../lib/obj/GCC/ReleaseD/strstream.o ../lib/obj/GCC/ReleaseD/sstream.o ../lib/obj/GCC/ReleaseD/ios.o ../lib/obj/GCC/ReleaseD/streambuf.o ../lib/obj/GCC/ReleaseD/stdio_streambuf.o ../lib/obj/GCC/ReleaseD/istream.o ../lib/obj/GCC/ReleaseD/ostream.o ../lib/obj/GCC/ReleaseD/iostream.o ../lib/obj/GCC/ReleaseD/codecvt.o ../lib/obj/GCC/ReleaseD/collate.o ../lib/obj/GCC/ReleaseD/ctype.o ../lib/obj/GCC/ReleaseD/monetary.o ../lib/obj/GCC/ReleaseD/num_get.o ../lib/obj/GCC/ReleaseD/num_put.o ../lib/obj/GCC/ReleaseD/num_get_float.o ../lib/obj/GCC/ReleaseD/num_put_float.o ../lib/obj/GCC/ReleaseD/numpunct.o ../lib/obj/GCC/ReleaseD/time_facets.o ../lib/obj/GCC/ReleaseD/messages.o ../lib/obj/GCC/ReleaseD/locale_impl.o ../lib/obj/GCC/ReleaseD/locale.o ../lib/obj/GCC/ReleaseD/locale_catalog.o ../lib/obj/GCC/ReleaseD/facets_byname.o ../lib/obj/GCC/ReleaseD/c_locale.o ../lib/obj/GCC/ReleaseD/c_locale_stub.o ../lib/obj/GCC/ReleaseD/complex.o ../lib/obj/GCC/ReleaseD/complex_exp.o ../lib/obj/GCC/ReleaseD/complex_io.o ../lib/obj/GCC/ReleaseD/complex_trig.o ../lib/obj/GCC/ReleaseD/complex_io_w.o ../lib/obj/GCC/ReleaseD/string_w.o `.L5217' referenced in section `.rodata' of ../lib/obj/GCC/ReleaseD/locale_impl.o: defined in discarded section `.gnu.linkonce.t._ZNK4_STL9money_getIwNS_19istreambuf_iteratorIwNS_11char_traitsIwE6do_getES4_S4_bRNS_8ios_baseERiRNS_12basic_stringIwS3_NS_9allocatorIw' of ../lib/obj/GCC/ReleaseD/locale_impl.o `.L5275' referenced in section `.rodata' of ../lib/obj/GCC/ReleaseD/locale_impl.o: defined in discarded section `.gnu.linkonce.t._ZNK4_STL9money_getIwNS_19istreambuf_iteratorIwNS_11char_traitsIwE6do_getES4_S4_bRNS_8ios_baseERiRNS_12basic_stringIwS3_NS_9allocatorIw' of ../lib/obj/GCC/ReleaseD/locale_impl.o `.L5338' referenced in section `.rodata' of ../lib/obj/GCC/ReleaseD/locale_impl.o: defined in discarded section `.gnu.linkonce.t._ZNK4_STL9money_getIwNS_19istreambuf_iteratorIwNS_11char_traitsIwE6do_getES4_S4_bRNS_8ios_baseERiRNS_12basic_stringIwS3_NS_9allocatorIw' of ../lib/obj/GCC/ReleaseD/locale_impl.o `.L5402' referenced in section `.rodata' of ../lib/obj/GCC/ReleaseD/locale_impl.o: defined in discarded section `.gnu.linkonce.t._ZNK4_STL9money_getIwNS_19istreambuf_iteratorIwNS_11char_traitsIwE6do_getES4_S4_bRNS_8ios_baseERiRNS_12basic_stringIwS3_NS_9allocatorIw' of ../lib/obj/GCC/ReleaseD/locale_impl.o `.L5492' referenced in section `.rodata' of ../lib/obj/GCC/ReleaseD/locale_impl.o: defined in discarded section `.gnu.linkonce.t._ZNK4_STL9money_getIwNS_19istreambuf_iteratorIwNS_11char_traitsIwE6do_getES4_S4_bRNS_8ios_baseERiRNS_12basic_stringIwS3_NS_9allocatorIw' of ../lib/obj/GCC/ReleaseD/locale_impl.o `.L7586' referenced in section `.rodata' of ../lib/obj/GCC/ReleaseD/locale_impl.o: defined in discarded section `.gnu.linkonce.t._ZNK4_STL9money_getIcNS_19istreambuf_iteratorIcNS_11char_traitsIcE6do_getES4_S4_bRNS_8ios_baseERiRNS_12basic_stringIcS3_NS_9allocatorIc' of ../lib/obj/GCC/ReleaseD/locale_impl.o `.L7654' referenced in section `.rodata' of ../lib/obj/GCC/ReleaseD/locale_impl.o: defined in discarded section `.gnu.linkonce.t._ZNK4_STL9money_getIcNS_19istreambuf_iteratorIcNS_11char_traitsIcE6do_getES4_S4_bRNS_8ios_baseERiRNS_12basic_stringIcS3_NS_9allocatorIc' of ../lib/obj/GCC/ReleaseD/locale_impl.o `.L7729' referenced in section `.rodata' of ../lib/obj/GCC/ReleaseD/locale_impl.o: defined in discarded section `.gnu.linkonce.t._ZNK4_STL9money_getIcNS_19istreambuf_iteratorIcNS_11char_traitsIcE6do_getES4_S4_bRNS_8ios_baseERiRNS_12basic_stringIcS3_NS_9allocatorIc' of ../lib/obj/GCC/ReleaseD/locale_impl.o `.L7741' referenced in section
Re: [tools-dev] Building 2.0.3 on Linux: stlport fails
Is there a recommended binutils version if I would like to have the option to choose between both compiler versions. Or might it be a better idea to configure the compiler with a specific binutils version ? It's always a good idea to configure gcc to the specific binutils you plan to choose. Gcc is known to adapt itself to the features of the used linker and assembler, as I found out the hard way some time ago. Actually any more or less recent binutils are fine, as long as they support the hide symbols feature. with that explanation I would expect the combination gcc-3.4.1 and binutils-2.17 working, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[tools-dev] meeting minutes: build environment 2006-08-24
participants: Ause, Kai Backmann, Michael Bemmer, Stephan Bergmann, Nils Fuhrmann, Martin Hollmichel, Matthias Huetsch, Heiner Rechtien, Juergen Schmidt. Kai B. provided some information about his investigation in the OOo build System. The main thesis he presented was that the overall build time of OOo is too high at this moment and that we need to reduce this time to attract more developers to step into OOo build. Michael Bemmer pointed out, that there is an agreement that lowering the barriers of entrance for contributing code to OOo is in very important topic for the project. Kai B. presented his analysis that about 33 % of overall build time is compiling C/C++ Files 27 % of the build time is needed by dmake/build tools 22 % of the time is needed for generating files dependencies. concentrating efforts for improvement to build system, especially wrt dependencies might have best results. Kai gave an introduction into jam which is an build tool which handles dependencies quite efficient. He also presented performance data about his jam build protoype for OOo which looked quite promising. additional technics like the usage of precompiled header files and batched compiling for several C++ files at once gives addtional speed up so that an build e.g. for Calc gives a speedup of more than factor 2. ause and Heiner argued that the configuration of the build environment could be tweaked at some places, so that the usage of dmake will lead to better results (technical details will be discussed on dev@tools.openoffice.org). next steps: * validations of the hot spots of the build system with different configuration of build environment and other optimizations; Kai will provide the modified tools for measuring this. * analysis of why is mozilla compiling each line of code about four times faster than OOo ? * review and feedback of jam prototype by Ause * Martin H. will set up follow up meeting right after OOo conference. Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] meeting minutes: build environment 2006-08-24
Martin Hollmichel wrote: participants: Ause, Kai Backmann, Michael Bemmer, Stephan Bergmann, Nils Fuhrmann, Martin Hollmichel, Matthias Huetsch, Heiner Rechtien, Juergen Schmidt. Joerg Jahnke and Malte Timmermann also participated in that meeting, ... sorry for that, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] OS/2 window size and positioning coordinates
Hi, for questions about the windowing system layer you should ask on dev@gsl.openoffice.org, Martin Yuri Dario wrote: Hi, still on the OS2 port, I have an open issue with native window sizing and positioning. When a window is moved using Os2SalFrame::SetPosSize, it seems to me that new position is expressed relative to the parent window, not to the screen coordinates. I found this for example for combo boxes, because the listbox was shown in a total wrong position. But also for sizing I have a problem: when I click a menu item, instead of showing a dropdown list of items, I see two arrows, like if the available space is not enough to show all the menu. Also here I think there is an error in coordinate system, but I still have to identify it. Since these errrors seems to be related, I'd like to read something about how the OOo windowing system is working. Is there a such document? Otherwise more help is needed :-) TIA, Bye, Yuri Dario /* * member of TeamOS/2 - Italy * http://www.os2power.com/yuri * http://www.teamos2.it */ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
