incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Rist <andrew.r...@oracle.com>
Subject Re: [CODE] gmake and AOO build system
Date Tue, 09 Oct 2012 22:34:50 GMT

On 10/9/2012 4:27 AM, Andre Fischer wrote:
> On 01.10.2012 06:16, Andrew Rist wrote:
>> I'll checkin the code this week - was trying to get a working env 
>> with he branch, and was having the usual issues.
>
> Thanks.
>
>> Don't know how far we're taking this , but would be nice to leave the 
>> build cleaner and more stable...
>
> I finally got to checking out the buildsys branch and building it. 
> Before I describe the problems that I have I would like to ask if you 
> have made changes beyond adapting the license headers?
At his point I have done nothing beyond applying the patches and 
updating headers.
>
> I am still trying to figure out what has been changed and why. The 
> commit messages of the two larger commits (1394326 and 1394707) state 
> that both contain changes from CWSs ause130, ause131, gnumake4 and 
> sd2gbuild:
>
>     ause130: #i117218# change .idl handling to gnu make
>     ause131: #i117685# own copy target for globlmn.hrc
>     gnumake4: add support for zip and jar files
>     sd2gbuild: migrated module sd to gbuild
>     gnumake4: #i117340#: CustomTarget: replace broken multi-repo support
>
> Why are there two commits?
My first checkin did not identify all the files changed during the git 
apply actions.  the second checkin was an attempt to rectify that.
As I write this I am realizing that I did not add all of the new files 
delivered in the patches.  I will look at this in a bit.
>
> Now to my build problems (I am building on Windows 7):
>
> 1. I can not run main/bootstrap without manually sourcing the solar 
> environment (winenv.set.sh).
>
> 2. Build breaks in udkapi.  For some reason the udkapi/prj/build.lst 
> has been stripped to just building udkapi/prj.  That directory does 
> not contain a makefile, therefore the build breaks.   Also, 
> udkapi/prj/d.lst has been stripped empty.  That would mean that all 
> IDL files in udkapi are not accessible anymore.  I don't see how that 
> could work.
>
> re 1: This should be easy to fix.
>
> re 2: This looks like a serious problem.  Without understanding the 
> goal of these changes, it is hard to come up with a fix.
Let me add the files and then try again...

A.
>
>
> -Andre
>
>>
>> A
>>
>> Sent from my iThingie
>>
>> On Sep 30, 2012, at 11:08 AM, Pedro Giffuni <pfg@apache.org> wrote:
>>
>>> Hi Ariel;
>>>
>>>
>>> ----- Original Message -----
>>>> From: Ariel Constenla-Haile <arielch@apache.org>
>>>
>>>> Hi Pedro,
>>>>
>>>> On Sun, Sep 30, 2012 at 09:07:03AM -0700, Pedro Giffuni wrote:
>>>>> There is currently nothing here, in fact trunk is more up to date.
>>>>> Can I start committing stuff or should Andrew do it?
>>>> IMHO only Andrew, as Oracle representative, can commit the patches. 
>>>> The
>>>> idea is to ensure that patches are granted by Oracle without the 
>>>> need to
>>>> ask for another software grant for this particular cws. I guess this
>>>> should be the procedure people should follow if interested in getting
>>>> cws code granted by Oracle; the other way is to ask for a software 
>>>> grant
>>>> on every file in the cws, but I guess that this won't scale (Oracle 
>>>> will
>>>> have to redo the same amount of work they did for the original 
>>>> software
>>>> grant).
>>> OK, I can wait.
>>>
>>>> Concerning this particular case, once Andrew commits the patches, 
>>>> there
>>>> should be some agreement on what to do: IMHO, the first thing 
>>>> should be
>>>> to ensure that the code builds in Windows, Linux and MacOSX (that cws
>>>> didn't originally take into account OS2 nor FreeBSD), otherwise 
>>>> there is
>>>> the chance that changes made for OS2/FreeBSD/Solaris/etc end up 
>>>> breaking
>>>> something that was actually working in the cws; and it may be then 
>>>> hard
>>>> to guess where and why it got broken (just like the boost/stlport 
>>>> case).
>>> I expect the only files that I have to touch are FreeBSD specific so 
>>> that
>>> probably won't be the case here. In any case I would expect the branch
>>> won't be merged into trunk until any issue with the FreeBSD and/or
>>>   Linux/Mac Windows ports are fixed.
>>>
>>> cheers,
>>>
>>> Pedro.
>


Mime
View raw message