You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@openoffice.apache.org by hd...@apache.org on 2013/05/08 17:39:19 UTC

svn commit: r1480326 - /openoffice/branches/rejuvenate01/

Author: hdu
Date: Wed May  8 15:39:18 2013
New Revision: 1480326

URL: http://svn.apache.org/r1480326
Log:
Create branch rejuvenate01 for a platform refresh

- support for XCode4 and its SDKs
- support for the Clang compiler
- support for 64bit Mac AOO
- support for a TR1 compatible STL
- prepare to drop stlport for the platform's native STLs
- replace functionality deprecated in XCode4's SDKs (OSX>=10.7)
- support for building with C++11 mode enabled
- support for 64bit-only OSX JREs

Added:
    openoffice/branches/rejuvenate01/   (props changed)
      - copied from r1480321, openoffice/trunk/

Propchange: openoffice/branches/rejuvenate01/
------------------------------------------------------------------------------
--- svn:mergeinfo (added)
+++ svn:mergeinfo Wed May  8 15:39:18 2013
@@ -0,0 +1,6 @@
+/incubator/ooo/branches/AOO34:1346776-1346777,1347535,1348052,1348914,1350569,1352456,1358991,1359004,1359010,1359024,1359546-1359547,1359553,1359555-1359556,1360552,1368968,1369110,1371068
+/incubator/ooo/branches/alg/linecap:1226811-1232461
+/incubator/ooo/branches/alg/svgreplacement:1205420-1220782
+/incubator/ooo/branches/writer001:1356067-1386577
+/openoffice/branches/alg/clibboard:1428975-1437368
+/openoffice/branches/sidebar:1415095-1466374



Re: New branch rejuvenate01

Posted by Juergen Schmidt <jo...@gmail.com>.
Am Mittwoch, 8. Mai 2013 um 20:16 schrieb Herbert Dürr:
> Hi,
>  
> I'd like to point to the new branch named "rejuvenate01" for advancing  
> AOO's platform support. The main focus is the upgrade of our codebase.  
> E.g. the MacOSX platform support had nearly stagnated since 2007 and  
> thus even getting the build requirements right on a current Mac was  
> becoming very very difficult and with the rejuvenation it should not  
> only work out of the box, but make leaps ahead.
>  
> Other platforms will soon benefit from this work too as it will allow us  
> to use the platform's native STLs. This means that we'll be able to use  
> the platforms C++ libraries instead of having to provide our own. It  
> also makes debugging easier because debuggers tend to understand the  
> native STL containers.
>  
> Improved support for other compilers is good because it because the look  
> from a different angle benefits the code quality. Clang has already  
> found some interesting bugs.
>  
> There are still rough edges in the new branch, especially in the  
> configure scripts. To build it with XCode4 you currently have to set the  
> build environment variables CC and CXX manually e.g.
> export CC="`xcrun -f clang` -arch x86_64"
> export CXX="`xcrun -f clang++` -arch x86_64"
> then run the configure and the build steps as usual. Please set the
> --without-stlport
> to benefit from the libc++ support.
>  
> This will get you a 64bit build of AOO for MacOSX. If you don't want to  
> build it yourself but want to play around with it you could try [1]
> [1] http://people.apache.org/~hdu/AOO_Mac64_rejuv.dmg
> Please note that this is only compatible with MacOSX >= 10.7 because  
> that is the oldest SDK still provided with the latest XCode4.
>  
> Other noteworthy things are that the branch still uses wrappers around  
> the STL to emulate stlport4 and to let the compiler find compatibility  
> issues. This approach also allows to keep the diff to trunk minimal for  
> now which makes reviewing easier. Once we decide we can drop these  
> wrappers then the replacement of all stlport4 includes by their TR1  
> counterparts (such as boost/tr1 or the powerful libc++ library) will be  
> mechanical and aided by compiler diagnostics.
>  
>  


Thanks for the detailed info and update if this important work. As a Mac user Zi am looking forward to upgrade my work env to XCode4...
Anyway great work and I will support you next week with the configure stuff.

I am sure some projects will be very interested to use your work and hopefully they will credit it appropriately ;-)

Juergen
>  
> Have fun!
> Herbert
>  
> On 2013/05/08 5:39 PM, hdu@apache.org wrote:
> > Author: hdu
> > Date: Wed May 8 15:39:18 2013
> > New Revision: 1480326
> >  
> > URL: http://svn.apache.org/r1480326
> > Log:
> > Create branch rejuvenate01 for a platform refresh
> >  
> > - support for XCode4 and its SDKs
> > - support for the Clang compiler
> > - support for 64bit Mac AOO
> > - support for a TR1 compatible STL
> > - prepare to drop stlport for the platform's native STLs
> > - replace functionality deprecated in XCode4's SDKs (OSX>=10.7)
> > - support for building with C++11 mode enabled
> > - support for 64bit-only OSX JREs
> >  
> > Added:
> > openoffice/branches/rejuvenate01/ (props changed)
> > - copied from r1480321, openoffice/trunk/
> >  
>  
>  
>  
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>  
>  



Re: New branch rejuvenate01

Posted by Herbert Duerr <hd...@apache.org>.
Hi Jan,

> thx. for the explanation. I will try to configure the branch saturday for
> ubuntu 12.04...do you want me to commit changes directly or do you prefer
> patch files ?

I trust you, you earned the trust of all the community so we voted you 
in as committer and you seem to be very motivated on this topic... so
let's roll! If this wasn't clear enough: commit directly :-)

Have fun!
Herbert

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org


Re: New branch rejuvenate01

Posted by janI <ja...@apache.org>.
On 10 May 2013 09:41, Herbert Duerr <hd...@apache.org> wrote:

> Sorry for the late answer, we had a public holiday yesterday:
>
>  [...]
>>> I agree, but since a lot of this stuff had co-dependencies (e.g. 64bit
>>> JRE
>>> ->  64bit UNO ->  XCode4 ->  clang ->  allows C++11 ->  no-stlport4 and
>>> XCode4
>>> ->  newer SDK) it wasn't easy to come up with a name that covered the
>>> different aspects. "Platform refresh 2013" and "rejuvenate" were the only
>>> ones that came to my little mind. Maybe I should have asked around more
>>> for
>>> better ideas. In my defense I mentioned the name "pr2013" as a suggestion
>>> for the branch in my 2013/04/09 mail on the XCode4 topic and nobody
>>> complained or had a better idea then.
>>>
>>
>> You are right with that lot of changes "rejuvenate" is quite precise (now
>> I just start wondering what rejuvenate02 is going to contain)
>>
>
> With the two-digit extension we'll have enough room to rejuvenate our
> Office many more times ;-)
>
> As to a concrete rejuvenate02 branch there are no concrete plans, only
> some general ideas:
> - Maybe now that the branch rejuvenate01 replaced stlport4 by a standard
> compliant STL from a binary perspective a new branch rejuvenate02 could be
> the followup for the related cleanup in the main codebase? Since this can
> mostly be automated I'll probably do it r01 though.
> - A rejuvenate03 branch could use all the C++11 features that are already
> now commonly available on our platform's compilers to clean up our codebase
> - A rejuvenate04 branch could go to full C++11 and improve speed using
> rvalue semantics and auto-types could help to make some areas much cleaner
>
> But what's in a name anyway. I just want to keep us the options open, but
> I don't like to concretely plan such stuff years ahead. Such concrete
> long-term plans would only limit the flexibility and close options that
> could benefit the project.
>

you caught me out here...I was actually trying to make a joke, I highly
respect the work you are doing, it is an example to all of us.

having said that it is still nice to see you have visions for the
future...and building systems seems to be on another track :-)


>
>  I have one technical question, how come you can change so easily to STL,
>> when it took LO many volunteers to do it, or did I misunderstand
>> something ?
>>
>
> Because of the license incompatibility I have no idea what they did and so
> I don't know why it took so much effort. Maybe they also converted some
> other ancient OOo data structures to STL?
>

I dont know either, I just read soo much about how much they invested.

>
> Or maybe they did the changes needed individually? I prefer to isolate the
> individual transition concerns (using my STL-wrappers and their
> STLPORT4-emulation), do the main transition (e.g. from hash_map to
> unordered_map) automatically and then drop the STL-wrappers altogether. If
> we have volunteers who like to boost their committer statistics we could to
> the main transition manually and per source file though ;-)
>

Yours seems to be the smarter way....if we  work smart we can do more than
a bunch on "just programmers" !!

thx. for the explanation. I will try to configure the branch saturday for
ubuntu 12.04...do you want me to commit changes directly or do you prefer
patch files ?

rgds
jan I.




>
> Herbert
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<de...@openoffice.apache.org>
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>

Re: New branch rejuvenate01

Posted by Herbert Duerr <hd...@apache.org>.
Sorry for the late answer, we had a public holiday yesterday:

>> [...]
>> I agree, but since a lot of this stuff had co-dependencies (e.g. 64bit JRE
>> ->  64bit UNO ->  XCode4 ->  clang ->  allows C++11 ->  no-stlport4 and XCode4
>> ->  newer SDK) it wasn't easy to come up with a name that covered the
>> different aspects. "Platform refresh 2013" and "rejuvenate" were the only
>> ones that came to my little mind. Maybe I should have asked around more for
>> better ideas. In my defense I mentioned the name "pr2013" as a suggestion
>> for the branch in my 2013/04/09 mail on the XCode4 topic and nobody
>> complained or had a better idea then.
>
> You are right with that lot of changes "rejuvenate" is quite precise (now
> I just start wondering what rejuvenate02 is going to contain)

With the two-digit extension we'll have enough room to rejuvenate our 
Office many more times ;-)

As to a concrete rejuvenate02 branch there are no concrete plans, only 
some general ideas:
- Maybe now that the branch rejuvenate01 replaced stlport4 by a standard 
compliant STL from a binary perspective a new branch rejuvenate02 could 
be the followup for the related cleanup in the main codebase? Since this 
can mostly be automated I'll probably do it r01 though.
- A rejuvenate03 branch could use all the C++11 features that are 
already now commonly available on our platform's compilers to clean up 
our codebase
- A rejuvenate04 branch could go to full C++11 and improve speed using 
rvalue semantics and auto-types could help to make some areas much cleaner

But what's in a name anyway. I just want to keep us the options open, 
but I don't like to concretely plan such stuff years ahead. Such 
concrete long-term plans would only limit the flexibility and close 
options that could benefit the project.

> I have one technical question, how come you can change so easily to STL,
> when it took LO many volunteers to do it, or did I misunderstand something ?

Because of the license incompatibility I have no idea what they did and 
so I don't know why it took so much effort. Maybe they also converted 
some other ancient OOo data structures to STL?

Or maybe they did the changes needed individually? I prefer to isolate 
the individual transition concerns (using my STL-wrappers and their 
STLPORT4-emulation), do the main transition (e.g. from hash_map to 
unordered_map) automatically and then drop the STL-wrappers altogether. 
If we have volunteers who like to boost their committer statistics we 
could to the main transition manually and per source file though ;-)

Herbert

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org


Re: New branch rejuvenate01

Posted by janI <ja...@apache.org>.
On 8 May 2013 21:20, Herbert Dürr <hd...@apache.org> wrote:

> On 2013/05/08 8:25 PM, janI wrote:
>
>> On 8 May 2013 20:16, Herbert Dürr <hd...@apache.org> wrote:
>>
>>> I'd like to point to the new branch named "rejuvenate01" for advancing
>>> AOO's platform support. The main focus is the upgrade of our codebase.
>>> E.g.
>>> the MacOSX platform support had nearly stagnated since 2007 and thus even
>>> getting the build requirements right on a current Mac was becoming very
>>> very difficult and with the rejuvenation it should not only work out of
>>> the
>>> box, but make leaps ahead.
>>>
>>>
>> This is very interesting....may I come with one small suggestion...I do
>> understand your choice of branch name, but it would be nice if the name
>> reflected the work being done...that makes it easier to identify and later
>> to find (if needed) once reintegrated.
>>
>
> I agree, but since a lot of this stuff had co-dependencies (e.g. 64bit JRE
> -> 64bit UNO -> XCode4 -> clang -> allows C++11 -> no-stlport4 and XCode4
> -> newer SDK) it wasn't easy to come up with a name that covered the
> different aspects. "Platform refresh 2013" and "rejuvenate" were the only
> ones that came to my little mind. Maybe I should have asked around more for
> better ideas. In my defense I mentioned the name "pr2013" as a suggestion
> for the branch in my 2013/04/09 mail on the XCode4 topic and nobody
> complained or had a better idea then.
>
> You are right with that lot of changes "rejuvenate" is quite precise (now
I just start wondering what rejuvenate02 is going to contain)

I have one technical question, how come you can change so easily to STL,
when it took LO many volunteers to do it, or did I misunderstand something ?


>
>  If you need help with testing on ubuntu 12.04 I will be happy to assist.
>>
>
> Thanks! I'm afraid the configure scripts for this target platform are not
> yet fully in shape for direct building and testing... but as far as I know
> you that doesn't scare you away in the least :-)
>

I will do "svn co" and have a look in the weekend, when you are finished
overflowing my cvs mail box :-)

I really look forward to dive into your work, it is the most interesting
happening (for me), while I have been around.

I assume your target is 4.1 ?

have a nice evening.
jan I.

>
> Herbert
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<de...@openoffice.apache.org>
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>

Re: New branch rejuvenate01

Posted by Herbert Dürr <hd...@apache.org>.
On 2013/05/08 8:25 PM, janI wrote:
> On 8 May 2013 20:16, Herbert Dürr <hd...@apache.org> wrote:
>> I'd like to point to the new branch named "rejuvenate01" for advancing
>> AOO's platform support. The main focus is the upgrade of our codebase. E.g.
>> the MacOSX platform support had nearly stagnated since 2007 and thus even
>> getting the build requirements right on a current Mac was becoming very
>> very difficult and with the rejuvenation it should not only work out of the
>> box, but make leaps ahead.
>>
>
> This is very interesting....may I come with one small suggestion...I do
> understand your choice of branch name, but it would be nice if the name
> reflected the work being done...that makes it easier to identify and later
> to find (if needed) once reintegrated.

I agree, but since a lot of this stuff had co-dependencies (e.g. 64bit 
JRE -> 64bit UNO -> XCode4 -> clang -> allows C++11 -> no-stlport4 and 
XCode4 -> newer SDK) it wasn't easy to come up with a name that covered 
the different aspects. "Platform refresh 2013" and "rejuvenate" were the 
only ones that came to my little mind. Maybe I should have asked around 
more for better ideas. In my defense I mentioned the name "pr2013" as a 
suggestion for the branch in my 2013/04/09 mail on the XCode4 topic and 
nobody complained or had a better idea then.

> If you need help with testing on ubuntu 12.04 I will be happy to assist.

Thanks! I'm afraid the configure scripts for this target platform are 
not yet fully in shape for direct building and testing... but as far as 
I know you that doesn't scare you away in the least :-)

Herbert

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org


Re: New branch rejuvenate01

Posted by janI <ja...@apache.org>.
On 8 May 2013 20:16, Herbert Dürr <hd...@apache.org> wrote:

> Hi,
>
> I'd like to point to the new branch named "rejuvenate01" for advancing
> AOO's platform support. The main focus is the upgrade of our codebase. E.g.
> the MacOSX platform support had nearly stagnated since 2007 and thus even
> getting the build requirements right on a current Mac was becoming very
> very difficult and with the rejuvenation it should not only work out of the
> box, but make leaps ahead.
>

This is very interesting....may I come with one small suggestion...I do
understand your choice of branch name, but it would be nice if the name
reflected the work being done...that makes it easier to identify and later
to find (if needed) once reintegrated.

If you need help with testing on ubuntu 12.04 I will be happy to assist.

rgds
jan I.

>
> Other platforms will soon benefit from this work too as it will allow us
> to use the platform's native STLs. This means that we'll be able to use the
> platforms C++ libraries instead of having to provide our own. It also makes
> debugging easier because debuggers tend to understand the native STL
> containers.
>
> Improved support for other compilers is good because it because the look
> from a different angle benefits the code quality. Clang has already found
> some interesting bugs.
>
> There are still rough edges in the new branch, especially in the configure
> scripts. To build it with XCode4 you currently have to set the build
> environment variables CC and CXX manually e.g.
>         export CC="`xcrun -f clang` -arch x86_64"
>         export CXX="`xcrun -f clang++` -arch x86_64"
> then run the configure and the build steps as usual. Please set the
>         --without-stlport
> to benefit from the libc++ support.
>
> This will get you a 64bit build of AOO for MacOSX. If you don't want to
> build it yourself but want to play around with it you could try [1]
>   [1] http://people.apache.org/~hdu/**AOO_Mac64_rejuv.dmg<http://people.apache.org/~hdu/AOO_Mac64_rejuv.dmg>
> Please note that this is only compatible with MacOSX >= 10.7 because that
> is the oldest SDK still provided with the latest XCode4.
>
> Other noteworthy things are that the branch still uses wrappers around the
> STL to emulate stlport4 and to let the compiler find compatibility issues.
> This approach also allows to keep the diff to trunk minimal for now which
> makes reviewing easier. Once we decide we can drop these wrappers then the
> replacement of all stlport4 includes by their TR1 counterparts (such as
> boost/tr1 or the powerful libc++ library) will be mechanical and aided by
> compiler diagnostics.
>
> Have fun!
> Herbert
>
> On 2013/05/08 5:39 PM, hdu@apache.org wrote:
>
>> Author: hdu
>> Date: Wed May  8 15:39:18 2013
>> New Revision: 1480326
>>
>> URL: http://svn.apache.org/r1480326
>> Log:
>> Create branch rejuvenate01 for a platform refresh
>>
>> - support for XCode4 and its SDKs
>> - support for the Clang compiler
>> - support for 64bit Mac AOO
>> - support for a TR1 compatible STL
>> - prepare to drop stlport for the platform's native STLs
>> - replace functionality deprecated in XCode4's SDKs (OSX>=10.7)
>> - support for building with C++11 mode enabled
>> - support for 64bit-only OSX JREs
>>
>> Added:
>>      openoffice/branches/**rejuvenate01/   (props changed)
>>        - copied from r1480321, openoffice/trunk/
>>
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<de...@openoffice.apache.org>
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>

New branch rejuvenate01

Posted by Herbert Dürr <hd...@apache.org>.
Hi,

I'd like to point to the new branch named "rejuvenate01" for advancing 
AOO's platform support. The main focus is the upgrade of our codebase. 
E.g. the MacOSX platform support had nearly stagnated since 2007 and 
thus even getting the build requirements right on a current Mac was 
becoming very very difficult and with the rejuvenation it should not 
only work out of the box, but make leaps ahead.

Other platforms will soon benefit from this work too as it will allow us 
to use the platform's native STLs. This means that we'll be able to use 
the platforms C++ libraries instead of having to provide our own. It 
also makes debugging easier because debuggers tend to understand the 
native STL containers.

Improved support for other compilers is good because it because the look 
from a different angle benefits the code quality. Clang has already 
found some interesting bugs.

There are still rough edges in the new branch, especially in the 
configure scripts. To build it with XCode4 you currently have to set the 
build environment variables CC and CXX manually e.g.
	export CC="`xcrun -f clang` -arch x86_64"
	export CXX="`xcrun -f clang++` -arch x86_64"
then run the configure and the build steps as usual. Please set the
	--without-stlport
to benefit from the libc++ support.

This will get you a 64bit build of AOO for MacOSX. If you don't want to 
build it yourself but want to play around with it you could try [1]
   [1] http://people.apache.org/~hdu/AOO_Mac64_rejuv.dmg
Please note that this is only compatible with MacOSX >= 10.7 because 
that is the oldest SDK still provided with the latest XCode4.

Other noteworthy things are that the branch still uses wrappers around 
the STL to emulate stlport4 and to let the compiler find compatibility 
issues. This approach also allows to keep the diff to trunk minimal for 
now which makes reviewing easier. Once we decide we can drop these 
wrappers then the replacement of all stlport4 includes by their TR1 
counterparts (such as boost/tr1 or the powerful libc++ library) will be 
mechanical and aided by compiler diagnostics.

Have fun!
Herbert

On 2013/05/08 5:39 PM, hdu@apache.org wrote:
> Author: hdu
> Date: Wed May  8 15:39:18 2013
> New Revision: 1480326
>
> URL: http://svn.apache.org/r1480326
> Log:
> Create branch rejuvenate01 for a platform refresh
>
> - support for XCode4 and its SDKs
> - support for the Clang compiler
> - support for 64bit Mac AOO
> - support for a TR1 compatible STL
> - prepare to drop stlport for the platform's native STLs
> - replace functionality deprecated in XCode4's SDKs (OSX>=10.7)
> - support for building with C++11 mode enabled
> - support for 64bit-only OSX JREs
>
> Added:
>      openoffice/branches/rejuvenate01/   (props changed)
>        - copied from r1480321, openoffice/trunk/


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org