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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
