Re: about macxjoin1153 cws

eric.bachard wrote:

> Hi Pavel,
>
> First, I want to explain "why" I have some strange "commits" : because 
> we're several to build on Max OSX, it is important to propose *first* 
> all builders the complete donated code, and choose *after* which part 
> has to be used or deleted.I simply refuse to decide alone in this case.
>
> Of course, even if all this code will be integrated, OOo will always 
> looks like OOo. ;-)
>
>
> Pavel JanĂ­k a ĂŠcrit :
>
>>    > berkeleydb (libdb_java not built)
>>
>> this change is:
>>
>> .IF "$(OS)"=="MACOSX"
>> OUT2LIB+=$(BUILD_DIR)$/.libs$/libdb*.jnilib
>> .ENDIF
>>
>> but we use different code in 2.0:
>>
>> .IF "$(OS)"=="MACOSX"
>> OUT2LIB+=$(BUILD_DIR)$/.libs$/libdb_java*jnilib
>> .ENDIF  # "$(OS)"=="MACOSX"
>>
>> Can you please use the same code?
>
>
> Yes, you're right, this is more clean to use the same for both 1.1.x 
> and 2.0.

FWIW, this does not match the patches proposed in IZ 30381.  I am 
building m57 with the four bottom patches for this issue. 

Also, I was able to build m57 with a rather large set of patches and it 
works!  Most of the patches come from macxjoin1153.

>
>
>>    > desktop (mozwrapper and nswrapper) ,
>> module desktop contains mozwrapper also in 2.0. Should it be adapted 
>> there
>> too?
>
>
> I think so. I just wasn't present last week. This will be done too as 
> soon as possible.
>
What is the IZ for this?  I will try to build with this patch on m57.

>>    > dlcompat (fixed for 10.2 build)
>>
>> module dlcompat's build.lst contains this change:
>>
>> Index: prj/build.lst
>> ===================================================================
>> RCS file: /cvs/external/dlcompat/prj/build.lst,v
>> retrieving revision 1.1
>> retrieving revision 1.1.10.1
>> diff -u -r1.1 -r1.1.10.1
>> --- prj/build.lst       22 Mar 2004 15:39:02 -0000      1.1
>> +++ prj/build.lst       3 Jul 2005 15:01:19 -0000       1.1.10.1
>> @@ -1,3 +1,3 @@
>> -dc     dlcompat        :       soltools NULL
>> +dc     dlcompat        :       soltools dlcompat NULL
>>  dc     dlcompat                usr1    -       all     dc_mkout NULL
>>  dc     dlcompat      nmake     -       all     dc_dlcompat NULL
>>
>> It makes dlcompat depending on itself which is nonsense. What is the
>> purpose of this fix? Reopening #i51507#.
>
>
> P. Luby's commit is not complete here. Some other part, probably 
> located in external, is still missing.
> IMHO : I propose to delete this change
>
>
As I said earlier, this is recursive and should stop the build.  This 
either needs a very good explanation from Patrick or be reversed.


>>    > sc (fixes for Hindu and Kannada)
>>
>> Hmm, he change here is:
>>
>> +
>> +# Indic resources are too big for the resource compiler
>> +RES_HINDI :=
>> +RES_KANNADA :=
>>
>> in makefile.mk. This is probably trying to fix #i33228#. See this issues
>
>
> Yes. I had no issue about this, believing it was Neo or something like 
> that only. Thank you
>
So this can be deleted for an OOo build, but probably needs to be there 
for a Neo/J build?

>> for more details and the reasoning for not fixing this and the 
>> workaround
>> that already is in the source. We do not need to pollute code with 
>> another
>> workaround.
>
>
>
> Ok for delete this too.
>
>
>>    > shell (the mailer can open documents with exotic filenames)
>>
>> The changes here are adding
>>
>> ... && !defined USE_JAVA
>>
>> to #if defined MACOSX. Why? Look at rev. 1.2.24.1.14.2 of cmdmailmsg.cxx
>> where pluby did this:
>>
>> -#if defined MACOSX && ! defined USE_JAVA
>> +#if 0 // defined MACOSX
>>
>> Why you reverted it back to
>>
>> -#if 0 // defined MACOSX
>> +#if defined MACOSX && !defined USE_JAVA
>>
>> in revision 1.2.24.1.14.3?
>
>
> Maybe I've made a mistake ?  I'll have a closer look.
>
Again, I could try to build m57 with this "fix".  However, this may be 
what broke the installation.  Of course, I will try this after the 
berkelydb fix build.

>>    > svtools (?)
>>
>> Yes, there is no change in module svtools.
>
>
> I have found nothing. Maybe someone can complete ?
>
> Thank you Pavel for all your comments, this is very helpfull for me.
>
I think there were patches against the 1.1.4 code that have been 
incorporated after its release.
At the present time, there are no patches needed from this project's files.

James McKenzie