You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Ariel Constenla-Haile <ar...@apache.org> on 2011/11/25 23:34:10 UTC
gnumake4 integration (was: Re: [Code] strategy for "child works
spaces")
Hi Pedro, *
On Fri, Nov 25, 2011 at 01:59:38PM -0800, Pedro Giffuni wrote:
> Hi;
>
> It looks like the IP Clearance stuff is under
> control so I would like to move completely to
> a development branch if you guys create it.
>
> I also suspect the FreeBSD port will need
> adjustments for the new gnumake stuff.
I have finished building on Fedora 16 64 bits, and fixing some issues.
I started building on WinXP (a VM, so it takes 5 hrs).
I'm not sure if the gnumake4 integration should be moved to a feature
branch. It is highly probable that it won't introduce any regression on
the core functionality, as most changes are made to Makefiles, and in
the cases where the source code was, it only had to do with fixing the
exported symbols, among other little changes; there are no core new
features, it is only the build system.
IMO everybody will benefit from its integration in the trunk, so I'd
vote for integrating this into trunk.
Of course, it is highly probable that our builds will brake, but it can
be fixed soon, while people is building.
On the other hand, having this in a feature branch will mean more work
with merging the trunk changesets (I already had to do this with the
cppunit removal, which by the way would have been more simple and clean
with the gnumake4 changes).
What do you guys think?
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: gnumake4 integration (was: Re: [Code] strategy for "child works
spaces")
Posted by Michael Stahl <ms...@openoffice.org>.
On 17/12/11 06:27, Ariel Constenla-Haile wrote:
> This way we can use branches/gbuild to create
> further feature branches for gbuild conversion that can not be done on
> trunk directly (here I can imagine the desktop module, for example).
errm, yes, converting the desktop module on master (not on a branch)
turned out to be quite a disaster at LO, so... branches are good :)
Re: gnumake4 integration (was: Re: [Code] strategy for "child works spaces")
Posted by Pedro Giffuni <pf...@apache.org>.
--- Sab 17/12/11, Ariel Constenla-Haile <ar...@apache.org> ha scritto:
...
> Data: Sabato 17 dicembre 2011, 00:27
> Hi Pedro,
>
> On Fri, Dec 16, 2011 at 08:10:55PM -0800, Pedro Giffuni
> wrote:
> > > I'm going to create a feature branch, named
> gbuild (I won't
> > > follow the apache-id naming schema, because this
> was not
> > > my work, nor am I going to be the only one
> committing code
> > > to it).
> >
> > And as I said I'll gladly move there and check the
> FreeBSD
> > required changes.
> >
> > > I'll apply the set of patches here
> > > http://people.apache.org/~arielch/gbuild-13-12-2011/
> > > except
> > > http://people.apache.org/~arielch/gbuild-13-12-2011/9999-gbuild-convert-lingucomponent.patch
> > > that didn't get very well on Windows.
> > >
> >
> > FWIW,
> >
> > I noticed there is this change on the gnumake4
> branch:
> >
> > vcl2gnumake: #i116588# move vcl to gbuild (step 1,
> linux)
> > http://hg.services.openoffice.org/cws/gnumake4/rev/373f4b04c6b8
> >
> > but it's not on your list, maybe I missed it.
>
> this is rather old, and integrated into OOO340:
> http://hg.services.openoffice.org/OOO340/rev/373f4b04c6b8
>
> That cws was fully integrated:
> http://hg.services.openoffice.org/OOO340/rev/18597186a506
>
> > > Question: shall I copy the whole trunk on the
> branch or
> > > only trunk/main?
> > >
> >
> > main is enough.
>
> I'm still uncertain about the layout. I do not want to use
> my apache-id,
> this is not my work (well, I converted some modules to
> gbuild, but it's
> the main work from Mathias Bauer, Michael Stahl, et. al. -
> that info is
> kept in the commit messages), and I'm not the only one to
> commit code in
> that branch (I don't do MacOS, FreeBDS, and my Win
> knowledge is rather
> poor, so this has to be a team work).
>
> May be I can use:
>
> branches/gbuild/gbuild1
>
Or branches/cws-integration/gnumake4
It doesnt really matter, we will remove it when the code
is integrated. ;)
Pedro.
Re: gnumake4 integration (was: Re: [Code] strategy for "child works
spaces")
Posted by Ariel Constenla-Haile <ar...@apache.org>.
Hi Pedro,
On Fri, Dec 16, 2011 at 08:10:55PM -0800, Pedro Giffuni wrote:
> > I'm going to create a feature branch, named gbuild (I won't
> > follow the apache-id naming schema, because this was not
> > my work, nor am I going to be the only one committing code
> > to it).
>
> And as I said I'll gladly move there and check the FreeBSD
> required changes.
>
> > I'll apply the set of patches here
> > http://people.apache.org/~arielch/gbuild-13-12-2011/
> > except
> > http://people.apache.org/~arielch/gbuild-13-12-2011/9999-gbuild-convert-lingucomponent.patch
> > that didn't get very well on Windows.
> >
>
> FWIW,
>
> I noticed there is this change on the gnumake4 branch:
>
> vcl2gnumake: #i116588# move vcl to gbuild (step 1, linux)
> http://hg.services.openoffice.org/cws/gnumake4/rev/373f4b04c6b8
>
> but it's not on your list, maybe I missed it.
this is rather old, and integrated into OOO340:
http://hg.services.openoffice.org/OOO340/rev/373f4b04c6b8
That cws was fully integrated:
http://hg.services.openoffice.org/OOO340/rev/18597186a506
> > Question: shall I copy the whole trunk on the branch or
> > only trunk/main?
> >
>
> main is enough.
I'm still uncertain about the layout. I do not want to use my apache-id,
this is not my work (well, I converted some modules to gbuild, but it's
the main work from Mathias Bauer, Michael Stahl, et. al. - that info is
kept in the commit messages), and I'm not the only one to commit code in
that branch (I don't do MacOS, FreeBDS, and my Win knowledge is rather
poor, so this has to be a team work).
May be I can use:
branches/gbuild/gbuild1
gbuild being like the id. This way we can use branches/gbuild to create
further feature branches for gbuild conversion that can not be done on
trunk directly (here I can imagine the desktop module, for example).
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
RE: gnumake4 integration (was: Re: [Code] strategy for "child works spaces")
Posted by "Dennis E. Hamilton" <de...@acm.org>.
It doesn't matter too much how much you copy into a branch, apart from it
creating larger working copy. But you don't need to check out the entire
working copy of the branch if you don't want. You might need it to do builds
though. Ask Armin.
SVN uses a copy-on-write technique, so only the files you change in the branch
take up much space on the server. (And if they are modified on the trunk, you
won't get the new one but a copy of the old one will still appear on the
branch, as I understand it. I've no idea whether linking can be used to keep
those parts synchronized instead.)
-----Original Message-----
From: Ariel Constenla-Haile [mailto:arielch@apache.org]
Sent: Friday, December 16, 2011 05:05
To: ooo-dev@incubator.apache.org
Subject: Re: gnumake4 integration (was: Re: [Code] strategy for "child works
spaces")
Hi Eric,
On Fri, Dec 16, 2011 at 01:04:15PM +0100, eric b wrote:
> >Question: shall I copy the whole trunk on the branch or only
> >trunk/main?
> >
>
> Very good question :-)
>
> In fact, I don't know how to create a new branch with svn. Is there
> a wiki page explaining that ?
I don't use svn myself (I use git-svn), but I've found
http://svnbook.red-bean.com/en/1.7/svn.branchmerge.using.html#svn.branchmerge.using.create
the command will be:
$ svn copy \
https://svn-master.apache.org/repos/asf/incubator/ooo/trunk/main \
https://svn-master.apache.org/repos/asf/incubator/ooo/branches/gbuild
If I only copy trunk/main
I see Armin copied the whole trunk, but in this case may be I can omit
the extras and ext_sources subrepos.
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: gnumake4 integration
Posted by Armin Le Grand <Ar...@me.com>.
Hi Eric,
On 16.12.2011 14:05, Ariel Constenla-Haile wrote:
> Hi Eric,
>
> On Fri, Dec 16, 2011 at 01:04:15PM +0100, eric b wrote:
>>> Question: shall I copy the whole trunk on the branch or only
>>> trunk/main?
>>>
>>
>> Very good question :-)
>>
>> In fact, I don't know how to create a new branch with svn. Is there
>> a wiki page explaining that ?
>
> I don't use svn myself (I use git-svn), but I've found
> http://svnbook.red-bean.com/en/1.7/svn.branchmerge.using.html#svn.branchmerge.using.create
>
> the command will be:
>
> $ svn copy \
> https://svn-master.apache.org/repos/asf/incubator/ooo/trunk/main \
> https://svn-master.apache.org/repos/asf/incubator/ooo/branches/gbuild
I have already started to use branches, I used
https://svn-master.apache.org/repos/asf/incubator/ooo/branches/alg/svnreplacement
for example, thus putting a username between branches and the name of
the branch. I did that since I also have an aw080 branch there. That
way, the branches will not get too crowded and noone needs to ask the
list whom that branch xyz belongs.
Just my 2 cents...
> If I only copy trunk/main
>
> I see Armin copied the whole trunk, but in this case may be I can omit
> the extras and ext_sources subrepos.
>
>
> Regards
Sincerely,
Armin
--
ALG
Re: gnumake4 integration (was: Re: [Code] strategy for "child works spaces")
Posted by Jürgen Schmidt <jo...@googlemail.com>.
Am Freitag, 16. Dezember 2011 schrieb Ariel Constenla-Haile <
arielch@apache.org>:
> Hi Eric,
>
> On Fri, Dec 16, 2011 at 01:04:15PM +0100, eric b wrote:
>> >Question: shall I copy the whole trunk on the branch or only
>> >trunk/main?
>> >
>>
>> Very good question :-)
>>
>> In fact, I don't know how to create a new branch with svn. Is there
>> a wiki page explaining that ?
>
> I don't use svn myself (I use git-svn), but I've found
>
http://svnbook.red-bean.com/en/1.7/svn.branchmerge.using.html#svn.branchmerge.using.create
>
> the command will be:
>
> $ svn copy \
> https://svn-master.apache.org/repos/asf/incubator/ooo/trunk/main \
> https://svn-master.apache.org/repos/asf/incubator/ooo/branches/gbuild
>
> If I only copy trunk/main
>
> I see Armin copied the whole trunk, but in this case may be I can omit
> the extras and ext_sources subrepos.
>
>
i would suggest to copy trunk completely to be consistent and to have
everything in place. As Dennis pointed out it's not a big overhead and only
changed files need space.
And the extras directories with the translation contains makefiles as well.
They have to be converted also over time ;-)
Juergen
> Regards
> --
> Ariel Constenla-Haile
> La Plata, Argentina
>
Re: gnumake4 integration (was: Re: [Code] strategy for "child works
spaces")
Posted by Ariel Constenla-Haile <ar...@apache.org>.
Hi Eric,
On Fri, Dec 16, 2011 at 01:04:15PM +0100, eric b wrote:
> >Question: shall I copy the whole trunk on the branch or only
> >trunk/main?
> >
>
> Very good question :-)
>
> In fact, I don't know how to create a new branch with svn. Is there
> a wiki page explaining that ?
I don't use svn myself (I use git-svn), but I've found
http://svnbook.red-bean.com/en/1.7/svn.branchmerge.using.html#svn.branchmerge.using.create
the command will be:
$ svn copy \
https://svn-master.apache.org/repos/asf/incubator/ooo/trunk/main \
https://svn-master.apache.org/repos/asf/incubator/ooo/branches/gbuild
If I only copy trunk/main
I see Armin copied the whole trunk, but in this case may be I can omit
the extras and ext_sources subrepos.
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: gnumake4 integration (was: Re: [Code] strategy for "child works spaces")
Posted by eric b <er...@free.fr>.
Hello Ariel,
Le 16 déc. 11 à 12:31, Ariel Constenla-Haile a écrit :
> Hi there,
>
> On Sat, Nov 26, 2011 at 08:33:47AM +0100, eric b wrote:
>>
>> Please use a feature branch
>
> I'm going to create a feature branch, named gbuild (I won't follow
> the apache-id naming schema, because this was not my work, nor am I
> going to be the only one committing code to it).
>
Ok, good idea !
> I'll apply the set of patches here http://people.apache.org/
> ~arielch/gbuild-13-12-2011/ except
> http://people.apache.org/~arielch/gbuild-13-12-2011/9999-gbuild-
> convert-lingucomponent.patch
> that didn't get very well on Windows.
>
Ok
> Question: shall I copy the whole trunk on the branch or only trunk/
> main?
>
Very good question :-)
In fact, I don't know how to create a new branch with svn. Is there a
wiki page explaining that ? In the old OOo times, I remember we used
cws_create, but should be one hidden svn command imho.
Regards,
Eric
--
qɔᴉɹə
Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page
L'association EducOOo : http://www.educoo.org
Blog : http://eric.bachard.org/news
Re: gnumake4 integration (was: Re: [Code] strategy for "child works spaces")
Posted by Pedro Giffuni <pf...@apache.org>.
Hi Ariel;
--- Ven 16/12/11, Ariel Constenla-Haile <ar...@apache.org> ha scritto:
> Hi there,
>
> I'm going to create a feature branch, named gbuild (I won't
> follow the apache-id naming schema, because this was not
> my work, nor am I going to be the only one committing code
> to it).
And as I said I'll gladly move there and check the FreeBSD
required changes.
> I'll apply the set of patches here
> http://people.apache.org/~arielch/gbuild-13-12-2011/
> except
> http://people.apache.org/~arielch/gbuild-13-12-2011/9999-gbuild-convert-lingucomponent.patch
> that didn't get very well on Windows.
>
FWIW,
I noticed there is this change on the gnumake4 branch:
vcl2gnumake: #i116588# move vcl to gbuild (step 1, linux)
http://hg.services.openoffice.org/cws/gnumake4/rev/373f4b04c6b8
but it's not on your list, maybe I missed it.
> Question: shall I copy the whole trunk on the branch or
> only trunk/main?
>
main is enough.
cheers,
Pedro.
Re: gnumake4 integration (was: Re: [Code] strategy for "child works
spaces")
Posted by Ariel Constenla-Haile <ar...@apache.org>.
Hi there,
On Sat, Nov 26, 2011 at 08:33:47AM +0100, eric b wrote:
> >>It looks like the IP Clearance stuff is under control so I would
> >>like to move completely to a development branch if you guys
> >>create it.
> >>
> >>I also suspect the FreeBSD port will need adjustments for the
> >>new gnumake stuff.
> >
> >I have finished building on Fedora 16 64 bits, and fixing some
> >issues. I started building on WinXP (a VM, so it takes 5 hrs).
> >
> >I'm not sure if the gnumake4 integration should be moved to a
> >feature branch.
>
>
> Please use a feature branch
I'm going to create a feature branch, named gbuild (I won't follow the
apache-id naming schema, because this was not my work, nor am I going to
be the only one committing code to it).
I'll apply the set of patches here
http://people.apache.org/~arielch/gbuild-13-12-2011/
except
http://people.apache.org/~arielch/gbuild-13-12-2011/9999-gbuild-convert-lingucomponent.patch
that didn't get very well on Windows.
Question: shall I copy the whole trunk on the branch or only trunk/main?
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: gnumake4 integration (was: Re: [Code] strategy for "child works spaces")
Posted by Pedro Giffuni <pf...@apache.org>.
Hello guys;
Maho and I have been battling with an issue related to
the linking order on the vcl module for the FreeBSD
port. A quick look on the gnumake4 CWS, in particular
http://hg.services.openoffice.org/hg/cws/gnumake4/file/b3086537b169/vcl/Library_vcl.mk
makes me think it is fixed there.
I think the best way to get it tested is to commit it
but if this is not acceptable for any reason please at
least make the patch available.
Pedro.
--- On Sat, 11/26/11, eric b <er...@free.fr> wrote:
...
>
> > It is highly probable that it won't introduce any
> regression on the core functionality,
>
>
> Any important change needs some tests. This is one
> important change.
>
>
>
>
> > IMO everybody will benefit from its integration in the
> trunk, so I'd vote for integrating this into trunk.
>
> [.. cut ...]
>
>
> > What do you guys think?
> >
>
> Used with zilllion of OpenOffice.org builds, on every OS, I
> have seen a lot of issues, and replace dmake IMHO worth to
> create a branch and verify nothing is wrong.
>
> Anyway, I'll follow what people say.
>
>
> Regards,
> Eric
>
> --qɔᴉɹə
> Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page
> L'association EducOOo : http://www.educoo.org
> Blog : http://eric.bachard.org/news
>
>
>
>
>
>
Re: gnumake4 integration (was: Re: [Code] strategy for "child works spaces")
Posted by eric b <er...@free.fr>.
Hi Ariel,
Le 25 nov. 11 à 23:34, Ariel Constenla-Haile a écrit :
> Hi Pedro, *
>
> On Fri, Nov 25, 2011 at 01:59:38PM -0800, Pedro Giffuni wrote:
>> Hi;
>>
>> It looks like the IP Clearance stuff is under control so I would
>> like to move completely to a development branch if you guys create
>> it.
>>
>> I also suspect the FreeBSD port will need adjustments for the new
>> gnumake stuff.
>
> I have finished building on Fedora 16 64 bits, and fixing some
> issues. I started building on WinXP (a VM, so it takes 5 hrs).
>
> I'm not sure if the gnumake4 integration should be moved to a
> feature branch.
Please use a feature branch : it is always possible to forgot some
parts, making the final set apparently working but unusable and the
end, and the problem difficult to track and being solved.
> It is highly probable that it won't introduce any regression on the
> core functionality,
Any important change needs some tests. This is one important change.
> IMO everybody will benefit from its integration in the trunk, so
> I'd vote for integrating this into trunk.
[.. cut ...]
> What do you guys think?
>
Used with zilllion of OpenOffice.org builds, on every OS, I have seen
a lot of issues, and replace dmake IMHO worth to create a branch and
verify nothing is wrong.
Anyway, I'll follow what people say.
Regards,
Eric
--
qɔᴉɹə
Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page
L'association EducOOo : http://www.educoo.org
Blog : http://eric.bachard.org/news
Re: gnumake4 integration
Posted by Herbert Duerr <hd...@apache.org>.
On 25.11.2011 23:39, Gavin McDonald wrote:
>> [...]
>> I have finished building on Fedora 16 64 bits, and fixing some issues.
>> I started building on WinXP (a VM, so it takes 5 hrs).
>
> Sorry to hijack, where are the requirements and build instructions for
> building
> on XP (and Win 7 too if possible.)
http://wiki.services.openoffice.org/wiki/Documentation/Building_Guide/Building_on_Windows#software_requirements
Herbert
Re: gnumake4 integration (was: Re: [Code] strategy for "child works
spaces")
Posted by Ariel Constenla-Haile <ar...@apache.org>.
Hello Gavin,
On Sat, Nov 26, 2011 at 08:39:20AM +1000, Gavin McDonald wrote:
> > I have finished building on Fedora 16 64 bits, and fixing some issues.
> > I started building on WinXP (a VM, so it takes 5 hrs).
>
> Sorry to hijack, where are the requirements and build instructions for
> building
> on XP (and Win 7 too if possible.)
you can find information on the Building Guide
http://wiki.services.openoffice.org/wiki/Documentation/Building_Guide/Building_on_Windows
It needs some updates about:
* ATL, Mathias said it is possible to get ATL if you install the Driver
SDK
* a newer DirectX SDK works, IIRC Andre added support for the latest one
Instructions about Getting the Source are outdated
http://wiki.services.openoffice.org/wiki/Documentation/Building_Guide/Getting_the_source
Apache OpenOffice works with SVN (though I guess most of us use git-svn).
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
RE: gnumake4 integration (was: Re: [Code] strategy for "child works spaces")
Posted by Gavin McDonald <ga...@16degrees.com.au>.
> -----Original Message-----
> From: Ariel Constenla-Haile [mailto:arielch@apache.org]
> Sent: Saturday, 26 November 2011 8:34 AM
> To: ooo-dev@incubator.apache.org
> Subject: gnumake4 integration (was: Re: [Code] strategy for "child works
> spaces")
>
> Hi Pedro, *
>
> On Fri, Nov 25, 2011 at 01:59:38PM -0800, Pedro Giffuni wrote:
> > Hi;
> >
> > It looks like the IP Clearance stuff is under control so I would like
> > to move completely to a development branch if you guys create it.
> >
> > I also suspect the FreeBSD port will need adjustments for the new
> > gnumake stuff.
>
> I have finished building on Fedora 16 64 bits, and fixing some issues.
> I started building on WinXP (a VM, so it takes 5 hrs).
Sorry to hijack, where are the requirements and build instructions for
building
on XP (and Win 7 too if possible.)
Thanks
Gav...
>
> I'm not sure if the gnumake4 integration should be moved to a feature
> branch. It is highly probable that it won't introduce any regression on
the
> core functionality, as most changes are made to Makefiles, and in the
cases
> where the source code was, it only had to do with fixing the exported
> symbols, among other little changes; there are no core new features, it is
> only the build system.
>
> IMO everybody will benefit from its integration in the trunk, so I'd vote
for
> integrating this into trunk.
> Of course, it is highly probable that our builds will brake, but it can be
fixed
> soon, while people is building.
>
> On the other hand, having this in a feature branch will mean more work
with
> merging the trunk changesets (I already had to do this with the cppunit
> removal, which by the way would have been more simple and clean with the
> gnumake4 changes).
>
> What do you guys think?
>
> Regards
> --
> Ariel Constenla-Haile
> La Plata, Argentina
Re: gnumake4 integration (was: Re: [Code] strategy for "child works spaces")
Posted by Pedro Giffuni <pf...@apache.org>.
+1 from me
I am pretty sure this wont interfere with the IP Clearance
that is left and even there, getting us less dependent on
Dmake is good.
Pedro.
--- On Fri, 11/25/11, Ariel Constenla-Haile <ar...@apache.org> wrote:
...
> Hi Pedro, *
>
> On Fri, Nov 25, 2011 at 01:59:38PM -0800, Pedro Giffuni
> wrote:
> > Hi;
> >
> > It looks like the IP Clearance stuff is under
> > control so I would like to move completely to
> > a development branch if you guys create it.
> >
> > I also suspect the FreeBSD port will need
> > adjustments for the new gnumake stuff.
>
> I have finished building on Fedora 16 64 bits, and fixing
> some issues.
> I started building on WinXP (a VM, so it takes 5 hrs).
>
> I'm not sure if the gnumake4 integration should be moved to
> a feature
> branch. It is highly probable that it won't introduce any
> regression on
> the core functionality, as most changes are made to
> Makefiles, and in
> the cases where the source code was, it only had to do with
> fixing the
> exported symbols, among other little changes; there are no
> core new
> features, it is only the build system.
>
> IMO everybody will benefit from its integration in the
> trunk, so I'd
> vote for integrating this into trunk.
> Of course, it is highly probable that our builds will
> brake, but it can
> be fixed soon, while people is building.
>
> On the other hand, having this in a feature branch will
> mean more work
> with merging the trunk changesets (I already had to do this
> with the
> cppunit removal, which by the way would have been more
> simple and clean
> with the gnumake4 changes).
>
> What do you guys think?
>
> Regards
> --
> Ariel Constenla-Haile
> La Plata, Argentina
>