targeting and assigning

Agreed. However, which Mozilla do you intend to support? I have tried
to rearrange mozab driver code a bit to suit Mozilla 1.3, but it still
doesn't work. If someone familiar with Mozilla AB, please speak up. ;-)

BTW, we can also foresee an option to link against system Mozilla
runtime unless significative changes were to be necessary in Mozilla
side for OOo mozab driver to work.

Thanks.

> However, which Mozilla do you intend to support?

whatever is best ... :) Currently, it's 1.0.x, mostly because nobody
dealt deeper with later versions. The point is that as long as we ship
own components, it doesn't really matter, because in the AB area (at
least in the parts we're using) hasn't been much of a change between
1.0.x and 1.3b so far.

> BTW, we can also foresee an option to link against system Mozilla
> runtime unless significative changes were to be necessary in Mozilla
> side for OOo mozab driver to work.

Unfortunately, currently there are such requirements (the profile
locking issue in Mozilla, for instance - our own tarballs are patched
so that they don't lock the accessed profile, and OTOH allow to access
a locked profile).
But you're right, the possibility to use a pre-installed Mozilla is
also a requirement, though I think there isn't an issue for this, yet.

Hi,

How about the following:

1. add a configure switch for building address book support or not
   (defaulting to "on" but possible to turn off)

2. our source adds a "mozilla" module  that includes the required mozilla  patch, makefile.mk, prj/build.lst, prj/d.lst, and an EMPTY download directory.

3. When the configure switch to disable the moz addressbook is *not* used (i.e the address book is enabled), then the mozilla/download directory is tested for existence of the proper mozilla source version tar.gz or zip file and a error is output if it is not present

4. we have a separate link to the proper mozilla-src archive just like we have for gpc pieces, that a user can download and add if they want.

That way no binaries are needed, and we don't have to download the same mozilla src archive again and again, and no patches from vendors would be needed to disable the addressbook since a simpe configure switch is all that is needed.

This seems to me the correct way to do this because it results in shrinking the OOo source tarball while allowing us to separately host the proper mozilla src version and control when it gets changed (if necessary).


I think any other way will result in lots of mozilla build bug reports and problems with people not wanting to use old mozilla source (even if it produces abi compatible addressbook components!).

My 2 cents,

Kevin

p.s. BTW mozilla 1.0 source needs some gcc 3 specific patches for ppc linux to work (vtable offset fixes and ...) so we should be able to hold platform specific patches for building mozilla 1.0 from source in our own "mozilla" module.

I agree with Kevin's assesment. gcc-3 Mozilla builds on IRIX also need
some patchs, so a mozilla-arch-patch type dir is needed. Also, some
way of having arch specific Mozilla configurations is needed.

This is a welcome move! :-)

Hi, 
 
Adding myself as CC to this issue. 
 
Kevin 
  

@Kevin:
> 4. we have a separate link to the proper mozilla-src archive just
> like we have for gpc pieces, that a user can download and add if
> they want.

Do I understand this right that you suggest to host the mozilla source
tarball somewhere at OOo, instead of allowing people to use their own
Mozilla source version?

@Nick:
> Also, some way of having arch specific Mozilla configurations is
> needed.

Sorry, can you please explain in more detail what you need?


Additionally, what would you both prefer: building Mozilla during
building OOo, or a separate step to build Mozilla, and then e.g. let
some env variable point to the output dir?
Kevin, from your suggestion I assume the former (though I fear it will
be much harder to achieve, because it would mean some kind of merging
of both (complex) build environments).

Thanks to all of you for the feedback and participation, this is
really appreciated!

Hi,

Yes, I am suggesting that official mozilla-1.0 src tarball (if that is what the latest OOo patch for mozilla needs) be kept at OOo but just not part of CVS co ( a separate download only if the builder wants it).

Then if the configure switch to disable moz addressbook is not provided, the configure script checks to make sure you have downloaded that tarball and placed it correctly in the mozilla/download directory and if not provides an  informative menu about how to do that url and where to put it, or instructions on how to disable building the addressbook (ie. the right configure switch). (ala gpc right now)

Then the OOo mozilla/makefile.mk does the basic external build with patch application, and configure and make and build (see any of freetype, berkeleydb, icu, etc, etc for examples of how to do this).

What I meant by port specific patches in that OO's mozilla/ directory would allow platform specific application of a second patch (one of rppc linux, one of rs390, etc) in a similar way.

That way instead of having tons of binaries, we instead have a few machine specific patches, and the main OO patch along with a separately downloaded mozilla-1.0 archive.

If the abi ever changes and mozilla-1.0 src is not enough, we can update both the mozilla source downloaded tarball and the official mozilla patch to accomodate it.

Otherwise we will be gihting a losing battle to try to make your OOo mozilla patches apply to each and every update of mozilla released (including betas).

Anyway, that is my idea.

Hope this helps,

Kevin

 

Sorry for the repost but the browser I was using seems to forget to wrap 
anythign making my post very very hard to read.

So I am adding hard retruns to this copy.



Hi,

Yes, I am suggesting that official mozilla-1.0 src tarball (if that is what the 
latest OOo patch for mozilla needs) be kept at OOo but just not part of 
CVS co ( a separate download only if the builder wants it).

Then if the configure switch to disable moz addressbook is not provided, 
the configure script checks to make sure you have downloaded that 
tarball and placed it correctly in the mozilla/download directory and if 
not provides an  informative menu about how to do that url and where 
to put it, or instructions on how to disable building the addressbook 
(ie. the right configure switch). (ala gpc right now)

Then the OOo mozilla/makefile.mk does the basic external build with patch 
application, and configure and make and build (see any of freetype, 
berkeleydb, icu, etc, etc for examples of how to do this).

What I meant by port specific patches in that OO's mozilla/ directory 
would allow platform specific application of a second patch (one 
for ppc linux, one for s390, etc) in a similar way.


That way instead of having tons of binaries, we instead have a few
machine specific patches, and the main OO patch along with a 
separately downloaded mozilla-1.0 archive.

If the abi ever changes and mozilla-1.0 src is not enough, we can 
update both the mozilla source downloaded tarball and the 
official mozilla patch to accomodate it.

Otherwise we will be fighting a losing battle to try to make your 
OOo mozilla patches apply to each and every update of 
mozilla released (including betas).

Anyway, that is my idea.

Hope this helps,

Kevin

> Anyway, that is my idea.

Thanks :). I am not yet sure if it is feasible to build Mozilla from
within OOo, because both build environments are rather complex. But I
admittedly don't have any experience with the projects you mentioned ....

Hi,

As long as all the build needs to be done is:

 unpacked
patched
configure (with options)
make 

then it can be pretty easily be built inside the OOo build environment using the solenv/inc/tg_ext.mk

This is the only process I sue to build mozilla from source right now (lots of configure options! - but).  So this should work pretty easily for unix style boxes.

I have no idea how complex the mozilla build is under MacOSX and WIN so perhaps this will be a bit of an issue if they require something more strange.

Perhaps, we could strip the mozilla source archive down to just the specific components we need to make things easier?


BTW: Iam no stickler for this.  I would be happy with a configure switch pointed to the properly patched and prebuilt mozilla source as an alternative !

Kevin

Kevin wrote:

> What I meant by port specific patches in that OO's mozilla/ directory 
> would allow platform specific application of a second patch (one 
> for ppc linux, one for s390, etc) in a similar way.

We went down this road briefly in the Debian packages when we needed a
patch to be applicable for powerpc only.  I wouldn't recommend it -
you can usually write the patch in a conditional way instead, using
some sort of #ifdef type of architecture test.  

Arch-specific patches are much harder to maintain because 

- the patch is not applied to other developers' source, so they do not
see the arch-specific code unless they actually make the effort to
read the patch by hand.  This reduces the number of eyeballs looking
at the code.

- the port maintainers have a bigger maintainence burden, becuase 
patches that are broken by by modifications to the original source
will only be noticed by people building on their architecture.

- changes by developers who do not work on that architecture can break
things without them realising it (they never build the patched version
of the source)

I appreciate that with conditional patches, the arch-specific code is
still not examined by the compiler, but at least the patches are
always applied and the source file is the same for all architectures.

mass re-assign of address book integration issues

Hi,

Can anyone give us an update on this issue?

Is anyone actually working on ...

- getting any required addressbook patches accepted into Mozilla
   so that we can drop our need for a Mozilla patch and upgrade to
   the latest version of Mozilla 1.4.

- changing the build to take a configure based switch to enable
   and disable competely the build and delivery of the addressbook pieces

- changing the build in connectivity to take a configure generated path
   to a current (but not colocated)  Mozilla source distribution and building the 
  required mozilla runtime and components on the fly 

- possibly extracting just the addressbook related code and components
  from the huge Mozilla source tree and incorporating them into out own
  build tree as source.

Or any other possibilities?

Thanks,

Kevin

Kevin, now that 1.1 is near to leaving the house, we can focus
2.0-problems such as this one here.

Within the AB-Integration "sub project of DBA", I'd give this one here
a relatively high priority. I hope we will see movement here in the
not-too-distant future (which at first means discussion about possible
ways), but please give us some time (the responsibility for the
abintegration has been shifted, thus this re-assignment here).

(ehm - except you volunteer to take this one - with the great
expertise you have with OOo's build environment, this would be a great
help! SCNR :))

for the records:

Michael Meeks recently supplied a patch which could also be a starting
point for this one here: see issue 17187.
To my current understanding (Michael didn't come back on this, yet),
it only allows to compile OOo with some Mozilla installation which is
already present in the system. As a goodie, it also allows compiling
with Mozilla versions greater than 1.0.
Unfortunately, it doesn't care for the runtime of OOo at the moment.

re assign to wind.
Hi, wind, please do this with berry, who is more familiar with
staroffice building environment.  

I am following Kevin's idea.

>2. our source adds a "mozilla" module  that includes the >required
mozilla  patch, makefile.mk, prj/build.lst, >prj/d.lst, and an EMPTY
download directory.
By way of make lest changes to OO build tree,I use old moz dir.
I make a download directory in moz,put a mozilla-source-1.0.tar.gz
there.Then I make a makefile.mk to untar the source,apply the
patchs,then call gnumake to compiler Mozilla.It almost do its work
now.I am trying to improve it.

Wind, thanks for caring for this!

I think the following suggestion from Kevin

>- changing the build to take a configure based switch to enable
>  and disable competely the build and delivery of the addressbook
>  pieces

is also a goo idea. When somebody wants to build OOo withou any
support for the MozAB integration, this should also be possible - in
this case we would need to skip building Mozilla, and skip building
and packaging the driver.
I don't know the experience with OOo's configure :), but the patch
which mmeeks supplied in issue 17187 may be worth a look to see how
such things are done (I myself learned some things from it :).

@Kevin:
> getting any required addressbook patches accepted into Mozilla
> so that we can drop our need for a Mozilla patch and upgrade to
> the latest version of Mozilla 1.4.

There are currently two blockers for using a Mozilla without patch:
- issue 6883 - a problem with Mozilla's asynchronous LDAP code, which,
  in an unpatched form, doesn't like to be called from within OOo
- the profile locking issue: Mozilla locks it's profile, so a second
  process cannot access it simultaneously, not even readonly.

There are also some other outstanding patches which are not integrated
into 1.4 (which we will care for), but these two are the major issues,
which have not been solved, yet.

@Frank

>>- changing the build to take a configure based switch to enable
>>  and disable competely the build and delivery of the addressbook
>>  pieces

>is also a goo idea.
Yes,I do think so.I have read it.If have time I will try it.

Created attachment 8402 [details]
use to patch config_office and add a option ENABLE_BUILD_MOZILLA

Created attachment 8403 [details]
use at moz dir,make dmake know how to build moz/zipped if BUILD_MOZILLA setted

Created attachment 8404 [details]
unzip to moz dir,download mozilla-source-1.0.tar.gz to moz/download,now you can build mozab with oo

notice to the attachment:
  1.use config.patch at $SRC_ROOT,zipped.patch at $SRC_ROOT/moz
  2.work with tcsh,not test with 4nt in Win32 env.
  3.after build,/moz/zipped/$(OS)$(COM)$(CPU)*.zip will be updated.
  4.connectivity/source/drivers/mozab/makefile.mk need a patch.Because
we use nmake to build mozilla before,
    a)mozilla does not support nmake after 1.0
    b)use nmake need more evirement and need mozilla source unpack to
a driver's root directory such as d:\mozilla.
    c)different between useing nmake and make is only effect 3 libs'
name and link modal.mozreg and nsreg from dynamic to
static,embed_base_s    to baseembed_s.

Created attachment 8405 [details]
patch connectivity/source/drivers/mozab/makefile.mk to work in win32 with mozilla libs build with make

Wind, I did not yet try your patch yourself (is anybody who is on cc
here interested in doing so to provide feedback? :), but nevertheless
have some comments/ideas/questions :)

(I am cc'ing Martin Hollmichel - mh@openoffice.org - here, because I
want us to benefit from his expertise regarding the build processes.
Hi Martin :)

- Since 4NT is the required shell for building on Win32, we have to
support this. Do you have a chance to do these tests, and/or what
problems do you expect/encounter?

- The config.patch looks for mozilla-source-1.0.tar.gz in
"moz/download", but where is it extracted and fianlly built? Do I
understand this correctly that it still has to be done manually?
I am not clear about the procedure after your patch is applied. Can
you please explain this in more detail?

- I do not yet understand the need for the patch in connectivity.
Since we are still building with Mozilla 1.0, why do we have problems
with nmake as opposed to make? 1.0 is always built with nmake, and
this is also what we always used, didn't we? Do you suggest that the
Mozilla we are no building *after* your patch is using make?
Can you please explain this in more detail (perhaps it's only me, but
I don't get it :)

One more thing:

> use nmake need more evirement and need mozilla source unpack to
> a driver's root directory such as d:\mozilla.

I remember I built Mozilla 1.0 in g:\src\mozilla, which worked pretty
well - are you sure that this restriction holds?

Hmmm, maybe I'm a bit dense, but looking at the patches I think that
using "--enable-build-mozab" doesn't build the libraries
automatically, but requires that you, *BEFORE* starting the OOo
build, build the mozilla libraries.

The scripts:
  moz.LINUX.sh,
  moz.SOLARIS.sh
or
  moz.WNT.sh
only create the archives.

Did you by chance forgot to include
  moz/makefile.mk ?

Where is mozilla build?

vq->fs: You said:
>One more thing:
>
>> use nmake need more evirement and need mozilla source unpack to
>> a driver's root directory such as d:\mozilla.
>
>I remember I built Mozilla 1.0 in g:\src\mozilla, which worked pretty
>well - are you sure that this restriction holds?
You're obviously refering to some more complete moz build
instructions. Which and where?

One more for Frank:
>- Since 4NT is the required shell for building on Win32, we have to
>support this. Do you have a chance to do these tests, and/or what
>problems do you expect/encounter?
I guess that "moz.WNT.sh" just doesn't work with 4nt, but moz.WNT.btm
should be easy enough.

       Volker

Hmmm, maybe I'm a bit dense, but looking at the patches I think that
using "--enable-build-mozab" doesn't build the libraries
automatically, but requires that you, *BEFORE* starting the OOo
build, build the mozilla libraries.

The scripts:
  moz.LINUX.sh,
  moz.SOLARIS.sh
or
  moz.WNT.sh
only create the archives and are never called. ?!

Did you by chance forgot to include
  moz/makefile.mk ?

Where is mozilla build?

vq->fs: You said:
>One more thing:
>
>> use nmake need more evirement and need mozilla source unpack to
>> a driver's root directory such as d:\mozilla.
>
>I remember I built Mozilla 1.0 in g:\src\mozilla, which worked pretty
>well - are you sure that this restriction holds?
You're obviously refering to some more complete moz build
instructions. Which and where?

One more for Frank:
>- Since 4NT is the required shell for building on Win32, we have to
>support this. Do you have a chance to do these tests, and/or what
>problems do you expect/encounter?
I guess that "moz.WNT.sh" just doesn't work with 4nt, but moz.WNT.btm
should be easy enough.

       Volker

fs->vq:
>> I remember I built Mozilla 1.0 in g:\src\mozilla, which worked
>> pretty well - are you sure that this restriction holds?
> You're obviously refering to some more complete moz build
> instructions. Which and where?

http://www.mozilla.org/build/win32-nmake.html#ss2.2
It talks about setting MOZ_SRC to e.g. d:\mozilla_source, and MOZ_SRC
always points to where the "mozilla" folder resides.
I never questioned this, and it worked :)

> I guess that "moz.WNT.sh" just doesn't work with 4nt, but
> moz.WNT.btm should be easy enough
Indeed.

When introducing yet another script (at the latest), I have a little
headache with the duplication of codes.
Thinking about it, it may be worth the effort of having a perl script
which does the packaging, since this only needs some
platform-dependent lists of libraries (perhaps even this can be
generalized, not sure), instead of duplicating the whole packager
script for every platform.
Wind, what do you think about perl? :)

Created attachment 8559 [details]
forgot moz/makefile.mk in previous file

->Volker Quetschke
>I guess that "moz.WNT.sh" just doesn't work with 4nt, but
>moz.WNT.btm should be easy enough.
Build mozilla need bash,so I use a bash shell script.It worked.And I
find that we are moving from 4nt to tcsh?If it worked in both this,why
not choose it?
-> Frank Schoenheit
about nmake
If we use nmake we have  to get :
   cygwin,wintools,cvs,perl5 fro win32,zip for win32; 
 have to set:
   set MOZ_BITS=32
   set MOZ_DEBUG=
   set MOZ_NT=
   set MOZ_SRC=
   set MOZ_TOOLS=
   set OS_TARGET=WINNT
   set WINOS=%OS_TARGET%
   set PATH=%PATH%;%MOZ_TOOLS%\bin;c:\cygwin\bin
   set _MSC_VER=1100
   set DISABLE_TESTS=
   set MOZ_DISABLE_JAR_PACKAGING=1
and it is not clear how to build with vc7.
But if we build with make,we just have to get:
    cygwin,wintools
   just set:
     moz_tools,path
and  "The nmake build instructions are still available for developers
using older branches such as the Mozilla 1.0 branch."
  So I choose make.
  We have to make a little change to mozab/makefile.mk because    the
some libs build in deferent way.
 >mozreg and nsreg from dynamic to static,embed_base_s  rename to
baseembed_s.

Hi wind,

I cleaned up your patch a bit, but it's nearly the same as before.

Because it took me a while to figure out how to build and create the
mozilla *.zip files here is a (hopefully) complete recipie:

1. Install Netscape wintools
    <http://www.mozilla.org/build/win32-nmake.html#s2>
2. Make sure that MOZ_TOOLS is set in your OOo build environment.
3. copy the files from moz2.zip (will follow as attachment)
   into moz/
4. apply moz.diff (will follow as attachment) to moz/
5. copy mozilla-source-1.0.tar.gz into moz/download/

Now remove the old mozilla *.zip in moz/zipped,
cd into moz and build.

Ok, works for me with MSVC6. But I have two points:

* Using moz.<os>.sh is not a good choice, it's easy to do what these
  scripts do in a makefile. (Propably moz/zipped/makefile.mk)
  I can work on this, but only when we find a solution for the next
  point.

* regxpcom throws a "unknown software exeption" popup window, because
  there is an assertion:
-- snip --
###!!! ASSERTION: Component Manager being held past XPCOM shutdown.:
'cnt == 0', file nsXPComInit.cpp, line 595
-- snip --
  This is mozilla bug 78861
   <http://bugzilla.mozilla.org/show_bug.cgi?id=78861>
  From that bug description I guess it is not a fatal error, and one
  could ignore it, but unfortunately it stopps the build and the
  popup is waiting for a click.

  It is very easy to disable the assertion by removing the
        NS_WARN_IF_FALSE(cnt == 0, "Component Manager being held past
XPCOM shutdown.");
  line in misc/build/mozilla/xpcom/build/nsXPComInit.cpp.
  (something for our empty mozilla-source-1.0.patch file)

Comments? Is disabling the warning ok? If yes, I'll prepare a patch.

A comment on 4NT: It's easy to build the *.zip files also in a W32-4nt
environment, as long as we do the creating of the *.zip in a dmake
makefile. The cygwin tools are needed for 4nt builds anyway, so
this (with some small corrections) will also work in W32-4nt.

Created attachment 8715 [details]
Additional files for moz/

Created attachment 8716 [details]
Patch for moz/

Volker, I did not yet read in detail, just one comment:
> regxpcom throws a "unknown software exeption" popup window, because
>   there is an assertion:

- I from time to time work with Mozilla in a debug version, and my
personal experience is that it's sometimes infested with assertions,
and thus the assumption that they can be ignored isn't too bad :)

- we could set an environment variable XPCOM_DEBUG_BREAK to "warn",
which should disable the message boxes for assertions. This variable
controls the behaviour of Mozilla's warning/assertion behaviour, as
you can see in mozilla/xpcom/glue/nsDebug.cpp

Thanks Frank!

So add this to my recipe above:

2.5 set XPCOM_DEBUG_BREAK to warn

Created attachment 8759 [details]
This is our patch file.

1.I use --disable-debug,so we does not need set XPCOM_DEBUG_BREAK or
patch mozilla.Sorry I forgot it too.
2.
>Using moz.<os>.sh is not a good choice.
Yes,I do think so.I am not  familiar with dmake,so I use a shell.If
you can make it,Volker,it is a great thing.
3.I wonder that whether we can checkin <a 
href="ftp://ftp.mozilla.org/pub/mozilla/source/wintools.zip">ftp://ftp.mozilla.org/pub/mozilla/source/wintools.zip</a>
 into our cvs.If "wintools.zip" is there,we can set moz_tools and
install Netscape wintools in our makefile.

Hi wind,

>2.
>>Using moz.<os>.sh is not a good choice.
>Yes,I do think so.I am not  familiar with dmake,so I use a shell.If
>you can make it,Volker,it is a great thing.
Yes, I will do, but first I'll try to get it build with .NET, and
change the moz/makefile.mk accordingly.

>3.I wonder that whether we can checkin
> <href="ftp://ftp.mozilla.org/pub/mozilla/source/wintools.zip>
>into our cvs.If "wintools.zip" is there,we can set moz_tools and
>install Netscape wintools in our makefile.
I don't think we need that. I guess, we wont check in
mozilla-source-1.0.tar.gz. The person who wants to build the
moz libraries (on windows) has to get the mozilla sources and the
wintools.zip and set up the wintools.
configure can check that, when --enable-build-mozab is used, the
wintools are installed and the MOZ_TOOLS and XPCOM_DEBUG_BREAK
are set. We could even add a --with-moz-wintools switch that
takes an argument to set the MOZ_TOOLS variable.

Hi,Volker
We don't need set XPCOM_DEBUG_BREAK.You can see my
mozilla-source-1.0.patch.It create a .mozconfig file in the mozilla
src dir,and add +ac_add_options --disable-debug.

Hi,
I tried to build moz with .NET, but I'm stuck in
  mozilla/xpcom/base

The call
  ../../dist/bin/xpidl.exe -m header -w -I ../../dist/idl -I. -o
xpidlgen/nsIConsoleService nsIConsoleService.idl
fails with an exception in xpidl.exe.

I enabled the debuging again and found that the call to function:
    IDL_tree_to_IDL(state->tree, state->ns, state->file,
                    IDLF_OUTPUT_NO_NEWLINES |
                    IDLF_OUTPUT_NO_QUALIFY_IDENTS |
                    IDLF_OUTPUT_PROPERTIES);
in line 84 of mozilla/xpcom/typelib/xpidl/xpidl_util.c fails.
Unfortunately this function is part of moztools\bin\libIDL-0.6.dll,
a precompiled binary without debugging info.

Ideas ?

see http://www.mozilla.org/build/win32.html

When building with MSVC++ 7, you must install VC7 built versions of 
the glib & libIDL libraries. You can find the prebuilt VC7 versions 
of these libraries at 
ftp://ftp.mozilla.org/pub/mozilla/libraries/win32/ .

Thanks wind!

> see http://www.mozilla.org/build/win32.html

I had the wrong url,
  <http://www.mozilla.org/build/win32-nmake.html#s2>
seems obsolete :-(

But from the GLIB_PREFIX and LIBIDL_PREFIX variables doesn't
work for mozilla 1.0, I grepped the sources for them, but didn't
find them.

So for .NET I took
  vc7-glib-1.2.10-bin.zip
  vc7-libIDL-0.6.8-bin.zip
and copied them over my moztools directory.

With these new files and the following makefile.mk the moz module
build to the end.

This new makefile also works for MSVC 6, but still only works in
W32-tcsh or linux/solaris. I will make it w32-4nt aware soon.

Created attachment 8905 [details]
New moz/makefile.mk

>I will make it w32-4nt aware soon.
Cheers.Maybe we can mark this issue *fixed* soon.:)

Hi Wind,

the following moz/makefile.mk works for W32-4nt and W32-tcsh. I should
work for normal unix systems.

I removed the *.zip generating part from this makefile, I think this
should be done in moz/zipped/. What do you think?

Can you test?

Created attachment 9025 [details]
Newer moz/makefile.mk

>I think this should be done in moz/zipped/
I think we had better to generate the *.zip in moz/ not in
/moz/zipped.Because I prefer to leave zipped  *zipped*.

I will have a test.
But I guest it will not pass if I using vc6,because I can not find a
env name ATL_INCLUDE.Does you only support .net?

Hi Wind,

> But I guest it will not pass if I using vc6,because I can not find a
> env name ATL_INCLUDE.Does you only support .net?

It will work, because I tested it with MSVC 6 ;-)

ATL_INCLUDE is a macro set in solenv/inc/wnt.mk

> I think we had better to generate the *.zip in moz/ not in
> /moz/zipped.Because I prefer to leave zipped  *zipped*.
OK, but I'm leaving for a vacation on Sunday, and I have very
little time right now. So this can take a while.

Volker

Volker
Have a good journey.
Don't warry,I will try to do it.
Wind

>It will work, because I tested it with MSVC 6 ;-)
Sure.It is.

>It will work, because I tested it with MSVC 6 ;-)
Sure.It dos.

Created attachment 9682 [details]
updated

hjs->vq: i had a look at "moz/makefile.mk". the extemsive usage of
$(shell ...) might result in funny returns if the windows build ever
gets multiprocess enabled. $(shell ...) captures stdout, which in this
case might be more than expected. using a shell script which does the
converting and sets the variables in the same shell ( scrip.sh &&
gnumake ) might be a better alternative.

*** Issue 16802 has been marked as a duplicate of this issue. ***

The following moz/makefile.mk was proposed by ause and slightly
modified by myself. It works with W32-tcsh, is *should* also work
for W32-4nt. It uses moz.WNT.sh for tcsh and 4nt.

As GUI is UNX for linux and solaris moz.UNX.sh is used in those cases.

I don't know if this is correct, I even never checked if the produced
$(OS)$(COM)$(CPU)*.zip files work, but I know that moz.SOLARIS.sh
is never called.

Created attachment 10051 [details]
Newest moz/makefile.mk

I created a CWS for this change:
name:     mozooo
based on: SRX645 m19

I suppose some people might want to have this in 1.1.1, so I chose a
SRX645 version for the moment. If we don't get an approval for 1.1.1,
then we might move to SRC680.

Frank, is it OK that I put my changes into this cws,

with:

external/mozilla/     a directory to put the moz source archive into.
                     (Maybe we have to put the sources there due to
                      issue 21196, but ATM let the user put them
                      there.)

moz/makefile.mk       Latest version, but using external/mozilla/
moz/moz.UNX.sh        from winds moz.zip
moz/moz.WNT.sh        from winds moz.zip
moz/mozilla-source-1.0.patch    from winds moz.zip

Plus apply moz.diff

I'm a bit reluctant to apply:
  patch-config.diff       I would like to clean it up a bit before
                          applying it.
  patch-dba.diff          I didn't use it up to now, I only build
                          the *.zips but didn't test them ;-)

The changes mentioned above seem save to me.

to Volker
->As GUI is UNX for linux and solaris moz.UNX.sh is used in those cases.
How about use $(OS) to replace $(GUI)?
->The following moz/makefile.mk was proposed by ause and 
->slightly modified by myself. It works with W32-tcsh, is 
->should* also work for W32-4nt.
I don't know "!:=" work.
I seam that lastest PSDK will break mozilla build,so I set
PATH,INCLUDE and LIB to original value before installs PSDK.Does
"PATH!:=??" and "LIB!:=??" do the same thing?

to wind:
> How about use $(OS) to replace $(GUI)?
OK, this is better.

>>The following moz/makefile.mk was proposed by ause and 
>>slightly modified by myself. It works with W32-tcsh, is 
>>should* also work for W32-4nt.
>I don't know "!:=" work.
The ":=" only means evalutate the right hand site when setting the
macro and not (every time) when using it. And the aditional "!"
prevents dmake from complaining that the macro was already set. 

>I seam that lastest PSDK will break mozilla build,so I set
>PATH,INCLUDE and LIB to original value before installs PSDK.Does
>"PATH!:=??" and "LIB!:=??" do the same thing?
Yes, setting the macro and using the .EXPORT is the same as
a "setenv XXX yyy"

I used the PSDK from february 2003, and it worked. Do they (MS) again
have a new one?

Volker, sorry for the delay in responding.

In general, I don't mind you checking in what you suggested to check
in. Wind, what's your opinion?

One thing: Correct me if I'm wrong, but external/mozilla doesn't yet
exist, does it? I'd need to check with Martin how to handle this. In
theory, we do not need to create it (since the user is required to
download the source tarball, and put it there), but perhaps we want to
create an empty project. Don't know the conventions here.

> I'm a bit reluctant to apply:
> patch-config.diff       I would like to clean it up a bit before
>                         applying it.
Can't say anything about this, but if can agree with Wind on this, go
ahead :).
I'm going to add config_office to the CWS.

> patch-dba.diff          I didn't use it up to now, I only build
>                         the *.zips but didn't test them ;-)
I think Wind can do :)

Hi Frank!

> One thing: Correct me if I'm wrong, but external/mozilla doesn't yet
> exist, does it? I'd need to check with Martin how to handle this. In
> theory, we do not need to create it (since the user is required to
> download the source tarball, and put it there), but perhaps we want
> to create an empty project. Don't know the conventions here.

We don't need an extra project, just a new dir in project external.
We already did this with external/dbghelp and external/msvcp70 for
some dlls the user has to supply. The directories are empty, they
only contain a README telling the user what to put here and where to
get it.

If we create a external/mozilla,how can we make moz/makefile.mk to use it?
Or do we need move all moz/ to external/mozilla?

Hi wind!

> If we create a external/mozilla,how can we make moz/makefile.mk to
> use it?

I just tried, we cannot :-( There is too much magic in tg_ext.mk, as
hardcoded paths containing "download".

We should just keep the source archive in moz/download/ This is the
easiest way.

Urk - this duplicates work in #21922# which is pending commit to
ooo111fix1 which we've been using for some time.

Our patch is a really simple binary hack: --disable-mozilla
configure-time switch.

The configure changes are committed as part of a batch of similar
'system' options in #21920#.

Looking at your configure change - this is I think complimentary; your
changes allow mozilla to be built from source; mine allows the mozilla
code to be disabled.

I hope that's ok.

Created attachment 11326 [details]
one tarball include all necessary files for remove the need for pre-compiled Mozilla tarballs from OOo build environment

updated moz/makefile.mk to make it can use moz.SOLARIS.sh
updated moz.SOLARIS.sh to make it work
updated config.patch

Notes to build mozilla on solaris:
I installed:
1.GNU fileutils
2.GNU patch
3.pkg-config-0.12.0
4.glib-1.2.10
5.gtk+-1.2.10
(gtk+ need
6.atk-1.0.0
7.pango-1.0.0 
8.tiff v3.5.7
8.jpeg-6b
)
9.libpng 1.2.5
10.libIDL 0.6.8

Build mozilla 1.0 need glib > 1.2 and gtk+>1.2,but you can't use
glib-2.0 and gtk+-2.0.Because they remove glib-config and gtk-config
scripts which are needed by mozilla configure script.

Created attachment 11355 [details]
fix one line error in last tarball

I checked in nearly all from Winds latest patch, on the mozooo branch, to start
getting some feedback. I did not check in moz.SOLARIS.sh, since it seems not to
be used at the moment. Somebody please correct me if I am wrong.

From reading all the above, it seems there's only one (minor) open question:
There was a suggestion to replace $(OS) with $(GUI). Is this still necessary?
Should we do it?

I'd like to release this for testing, especially for the porters (some of the
people whose feedback I am interested in most are on the cc list her).

Thus: Wind, Volker: Now that this has been checked in: If somebody wants to try
this, is there anything to care for? Can s/he just check out the CWS, and go
ahead, and everything is fine? Or do you both know of any open pitfalls?

If I understand the changes in config_office correctly, it's sufficient to place
the mozilla-source-1.0.tar.gz into the download directory, and then start
configure - after this, and everything should work like a charm - is this correct?

Wind, do you mind creating a small (HTML) documentation about what needs to be
done by somebody who wants to use this? Preferrably some step-by-step description?
Once the fixes here made it into the master, I would like to publish such a
documentation somewhere on the dba or tools site, and I think you are most
competent to write it :).
(Additionally, it would allow me to test this without reading through all the
stuff above while trying to understand what the heck you did :) - sorry, I am
not yet familar enough with the OOo build environment)

Created attachment 12331 [details]
a small faq doc

"setenv BUILD_MOZAB=TURE"  in faqs_11424.html should be "setenv BUILD_MOZAB
TURE" in tcsh. 

Hi Frank, can you tell me which projects/directories are changed by
cws_srx645_mozooo compared to a cws_srx645_ooo(something).

I'm on a very slow connection ATM and it's easier for me to checkout
only necessary directories.

Volker

Created attachment 12373 [details]
patch file for the mozooo CWS with all changes applied

I attached the result of a "cvs diff -uN -rCWS_SRX645_MOZOOO_ANCHOR
-rcws_srx645_mozooo" for the three projects config_office, connectivity, moz.
This should be all necessary changes. I hope downloading this is faster than
doing an CVS update :)

Wind, thanks for the document - looks pretty straigh-forward, and I think we can
later on put a version of this online at dba.openoffice.org. I'll give this a
try at the weekend :)

porters:
I unfortunately do not know how to map the login names in the cc list to real
names, but IIRC, some of you reading here are porters :). Is anybody of you
interested in giving
http://www.openoffice.org/nonav/issues/showattachment.cgi/12373/cws_mozooo.zip a
try, and tells us how it worked for your platform? This is your chance for
giving feedback *before* the change done herein is integrated ...

is it possible to commit all the stuff to external/moz now. Do you need commit
access for external ?

since the FAQ mentiones "pkg-config-0.12.0", has anyone yet checked that this
doesn't conflict with the "hand tailored" "pkg-config" supplied in the module
"pkgconfig" (SRC680)?
this module was introduced by Phillipp Lohmann (pl@openoffice.org) to ease the
build of gtk/glib for crashreporter in SO environment.

> is it possible to commit all the stuff to external/moz now. Do you need commit
> access for external ?

I already checked it in, on the branch cws_srx645_mozooo.

finally I managed to get an OpenOffice.org/Mozilla build environment coexist
with my StarOffice build env .... (well, kind of)

After this, I tried this out, and it *nearly* worked :).

Wind, one thing I mainly wonder about: In moz/zipped/makefile.mk, there *no*
build is done if BUIILD_MOZAB is TRUE. However, this implies that the zip files
(which were just created after building Mozilla) are *not* extracted, thus,
*nothing* gets delivered into the environment
(..\solver\645\$(OS)$(COM)$(CPU)\*). For instance, no mozruntime.zip gets
deliver - which would result in an improper installation set later on.
So I think that even in case of BUILD_MOZAB being TRUE, we need to do the normal
build in moz/zippped.

Other things which I stumbled upon:
- When the build environment for Mozilla is improperly set (e.g. if you did not
set MOZ_BITS or one of the other necessary env variables), then this can only be
noticed when building moz. It would be nice to have at least some warnings in
the configure script. Something like: If BUILD_MOZAB is TRUE, but MOZ_BITS or
the like are *missing*, then configure should issue a warning.
A more sophisticated solution would be to let configure set all these variables
automatically (which should be possible in most cases).

- What the configure script should *definately* set is the MOZ_SRC variable.
Since it must point to moz/wntmsci9.pro/misc/build (or something like this), we
cannot expect the developers to automatically know this. Instead, the configure
script should set this variable, depending on the SRC_ROOT.

Could you please care for these things, Wind? Thanks :)

Hi,Frank
>So I think that even in case of BUILD_MOZAB being TRUE, 
>we need to do the normal build in moz/zippped.
If BUILD_MOZAB is true, the moz/moz.$(os).sh script will put all files where
they should be, then pack them to moz/zipped . So we don't need unzip
moz/zipped/*.zip one more time.
>MOZ_BITS &  MOZ_SRC
If you want to build mozilla 1.0 using nmake.exe from Microsoft's VC. You must
set MOZ_BITS and MOZ_SRC. But namke will not be supported by newer mozilla build
env. So I use gnumake here. It is the reason why I need a patch to connectivity.
Then the only thing the developers must know is that he/she must get install a
copy of moztools and add $moztools$/bin to PATH (must before $(CYGWIN)/bin). I
will add this to my faqs.

> If BUILD_MOZAB is true, the moz/moz.$(os).sh script will put all files where
> they should be, then pack them to moz/zipped . So we don't need unzip
> moz/zipped/*.zip one more time.

Uh. So the shell script itself copies the resulting files into the output tree?
Seems I was confused by the following: I deleted mozruntime.zip from
wntmsci9.pro/bin, and did a build, and nothing happened - I would have expected
mozruntime to be rebuilt.
Okay, this is a little bit unorthodox, but maybe possible. Ause, what's your
opinion on this?

> If you want to build mozilla 1.0 using nmake.exe from Microsoft's VC. You must
> set MOZ_BITS and MOZ_SRC. But namke will not be supported by newer mozilla
> build env. So I use gnumake here. It is the reason why I need a patch to
> connectivity.

I remember I got some errors about these env variables not being set, but now
that I tried it again, I cannot reproduce this. Strange. Maybe it was a problem
with my mixed SO/OOo build environments (which I separated a little bit better now).
Okay, so let's assume these variables were my fault :).

But, this brings up another point :). This it must also be possible to use the
pre-built tarballs (remember that Hamburg RE will shoot me if this isn't the
case :), we should make the change in connectivity dependent on the BUILD_MOZAB
variable. I.e., if BUILD_MOZAB is TRUE, we should link with embed_base_s.lib,
and else, we should do it the old way and link with baseembed_s.lib.
If we don't do this, then the build here in Hamburg will probably break, since
embed_base_s.lib does not exist when the pre-built tarballs are used. Is this
correct?
Alternatively, we should also build the tarballs with gnumake, and check them
in, so that connectivity *always* can link with embed_base_s.lib.

> I will add this to my faqs.

You may want to check in this FAQ somewhere on dba (at some temporary place), to
prevent adding new attachments here while the document evolves.

just talked with Ause about the copying of the zip files into the local output
tree (moz/wntmsci9.pro etc.). According to Ause, this is no problem, since it's
the usual behaviour in external modules. As long as we can trigger the copy of
the zip files (which we *can* by deleting the CREATETARBALL flag file), this is
okay.

So the only thing which is left from my point of view is the question for the
*embed* library name, which currently is different depending on whether
BUILD_MOZAB is TRUE or FALSE, while the makefile in connectivity does not yet
seem to honor this.

>So the shell script itself copies the resulting files into the output tree?
No. It copys the needed files from mozilla to moz/xxx/inc,
moz/$(OS)$(COM)$(CPU)/$(someplace) and moz/xxx/lib then packs them to
moz/zipped/xxxinc.zip moz/zipped/xxxrintime.zip moz/zipped/xxxlib.zip. And copy
moz/zipped/xxxruntime.zip to moz/$(OS)$(COM)$(CPU)/bin/mozruntime.zip.
So there must be some thing wrong if you can't find mozruntime.zip in
wntmsci9.pro/bin.

>Alternatively, we should also build the tarballs with gnumake, and check them
>in, so that connectivity *always* can link with embed_base_s.lib.
Yes. They are there, moz/zipped/xxx.zip. So every one can build mozilla
pre-build tarball if he/she has setupped build environment for this issue. 

>So the only thing which is left from my point of view is the question for the
>*embed* library name

I guess we use gnumake to build all mozilla tarball from now on. We can check in
our changes to connectivity the same time when we check in mozilla tarballs.

> So there must be some thing wrong if you can't find mozruntime.zip in
> wntmsci9.pro/bin.

Well, I think if I delete *only* the mozruntime.zip from the local output tree,
then it will *not* be rebuilt. I have to *manually* remove the CREATETARBALL
file in wntmsci9.pro/misc, in order to get everything re-packaged. This is what
confused me here.
However, according to Ause, this is the usual behaviour for such external
projects - I simply didn't know this, sorry.

> I guess we use gnumake to build all mozilla tarball from now on. We can check
> in our changes to connectivity the same time when we check in mozilla
> tarballs.
Makes sense.

Nobody of the porters here willing to give it a try for his platform?

linux/sparc port is interested but...personally I would rather just wait for it
to arrive in cws_src680_ooo20031216 or whatever follows if it is too late for
that one. If there is a problem with porting it would be easier where everyone
is working on the same thing. If you have used $(OS)$(COM)$(CPU) it should be OK
and I already know i can build the mozilla sources up to 1.5b on linux/sparc.
But others may feel different, it seems a lot of people are "reading the mail" ;)
-jim

I finally found a few minutes and tried cws_srx645_mozooo. It nearly
worked for me ;-) I found the following patch to the mozilla-source-1.0.patch
file necessary:

+++ moz/mozilla-source-1.0.patch	25 Jan 2004 06:06:01 -0000
@@ -4334,7 +4334,7 @@
 @@ -0,0 +1,8 @@
 +ac_add_options --disable-tests
 +ac_add_options --disable-xprint
-+ac_add_options --without-zlib
++ac_add_options --without-system-zlib
 +ac_add_options --enable-ldap
 +ac_add_options --disable-debug
 +ac_add_options --enable-optimize

A typo, I guess, but as my cygwin environment has a zlib configure got confused.

And secondly I doubt that anyone with $(OS) != WNT ever build project moz
from that branch. makefile.mk calls .\moz.$(OS).sh, but there is no OS with
$OS = UNX. We have:
   $OS             = "SOLARIS";
   $OS             = "NETBSD";
   $OS             = "FREEBSD";
   $OS             = "LINUX";
   $OS             = "TRU64";
   $OS             = "IRIX";
   $OS             = "WNT";
   $OS             = "MACOSX";
   $OS             = "AIX";

in set_soenv.in, but no UNX.

The build completed, but a funny thing is that new zip archives for
WNTMSCIinc.zip and WNTMSCIlib.zip were created, but WNTMSCIruntime.zip
is still the old version. This is propably because of the read-only setting
of the file in cvs.

This brings us to another problem, why is mozilla build and the script
tries to build the three *.zip archives when they are already there?  

First: Ignore my sentence about WNTMSCIruntime.zip beeing read-only, it's not.
I don't know the reason yet.

Second: I found another problem for WNT. Mozillas configure chokes in SYSTEM_ZLIB
set to "NO" by winenv.*. This fixes that problem:

+++ moz/makefile.mk	26 Jan 2004 01:53:12 -0000
@@ -85,6 +85,11 @@
 BUILD_ACTION=$(GNUMAKE)
 BUILD_FLAGS= -f client.mk build
 
+# Unset SYSTEM_ZLIB, otherwise configure of mozilla gets confused
+# and --without-system-zlib gets ignored.
+SYSTEM_ZLIB=
+.EXPORT : SYSTEM_ZLIB
+
 .IF "$(GUI)"=="UNX"
 .IF "$(COMNAME)"=="sunpro5"
 .IF "$(BUILD_TOOLS)$/cc"=="$(shell +-which cc)"

With this two changes I build moz/ successful with W32-tcsh-MSVC and
W32-tcsh-NET2002.

I asked LXR and SYSTEM_ZLIB is only used in comparison to "YES", that
means we can as well define it to "no" instead of "NO" in
config_office/configure. Mozillas configure should be happy with
the lowercase "no". We could skip my moz/makefile.mk patch then.
(I didn't test this, but I just had the idea this might work)

vq->ause: Would the SYSTEM_ZLIB change be OK with you?

vq->fs: May I commit my changes to your cws_srx645_mozooo? (After I tested them
        successfully.)

> And secondly I doubt that anyone with $(OS) != WNT ever build project moz
> from that branch. makefile.mk calls .\moz.$(OS).sh, but there is no OS with
> $OS = UNX.

you're right ....
fs->ause: what would be the right define (as opposed to $(OS)) to capture the
UNX? IMO, it should be the UNX from the output tree name (unxsol*, unxlngi*,
wnt*) - do we have a define for this in the build env?

> This brings us to another problem, why is mozilla build and the script
> tries to build the three *.zip archives when they are already there?

Hmm. I am somewhat unhappy with building into the "zipped" directory (instead of
into the local output tree only), anyway ...
Perhaps, instead of building these three files, we could only place the files
which they normally would create (e.g. all the includes, the libs, and
mozruntime.zip) directly in the output tree, and never bother with the files in
the "zipped" directory at all. Would this be reasonable?

> vq->fs: May I commit my changes to your cws_srx645_mozooo? (After I tested
> them successfully.)

sure, if master-of-the-build-env Ause approves them ...

>I asked LXR and SYSTEM_ZLIB is only used in comparison to "YES", that
>means we can as well define it to "no" instead of "NO" in
>config_office/configure. Mozillas configure should be happy with
>the lowercase "no". We could skip my moz/makefile.mk patch then.
>(I didn't test this, but I just had the idea this might work)
>
>vq->ause: Would the SYSTEM_ZLIB change be OK with you?
i'm not that happy messing with the case of "YES" and "no". why is "SYSTEM_ZLIB"
set to "NO" at all? couldn't we just unset it?

>> And secondly I doubt that anyone with $(OS) != WNT ever build project moz
>> from that branch. makefile.mk calls .\moz.$(OS).sh, but there is no OS with
>> $OS = UNX.
>
>you're right ....
>fs->ause: what would be the right define (as opposed to $(OS)) to capture the
>UNX? IMO, it should be the UNX from the output tree name (unxsol*, unxlngi*,
>wnt*) - do we have a define for this in the build env?
you may try "$(GUI)"=="UNX".

>> This brings us to another problem, why is mozilla build and the script
>> tries to build the three *.zip archives when they are already there?
>
>Hmm. I am somewhat unhappy with building into the "zipped" directory (instead of
>into the local output tree only), anyway ...
never build into a "source" directory. there _are_ reasons why there are output
trees which contain the platform name.

>Perhaps, instead of building these three files, we could only place the files
>which they normally would create (e.g. all the includes, the libs, and
>mozruntime.zip) directly in the output tree, and never bother with the files in
t>he "zipped" directory at all. Would this be reasonable?
that's what all other "external" modules do. why zip them when they are unzipped
again just one second later?

> i'm not that happy messing with the case of "YES" and "no". why is "SYSTEM_ZLIB"
> set to "NO" at all? couldn't we just unset it?
Yes, that's fine with me and the mozilla configure ;-) I'll prepare the
config_office patch this evening and commit to cws_srx645_mozooo.
( I guess this was an aproval ;) )

>> i'm not that happy messing with the case of "YES" and "no". why is
>> "SYSTEM_ZLIB" set to "NO" at all? couldn't we just unset it?
> Yes, that's fine with me and the mozilla configure ;-) I'll prepare the
> config_office patch this evening and commit to cws_srx645_mozooo.
I cannot do this, in the config_office module of cws_srx645_mozooo SYSTEM_ZLIB
does not yet exist, it is new in ...fix2. This means once the ...mozooo
branch gets merged it will break. Two choices:

1. Merge config_office from mws_srx645 once ..fix2 is integrated and apply the
following patch.

2. Apply the following patch to ..fix3 and hope it gets integrated to the
master before ...mozooo is merged.

Patch:
+++ config_office/configure.in	27 Jan 2004 02:15:57 -0000
@@ -1353,7 +1353,7 @@
         [AC_MSG_RESULT(found)], [AC_MSG_ERROR(zlib not found. install zlib)])
 else
     AC_MSG_RESULT([internal])
-    SYSTEM_ZLIB=NO
+    SYSTEM_ZLIB=""
 fi
 AC_SUBST(SYSTEM_ZLIB)
 

Committed the change to moz/mozilla-source-1.0.patch.

fs->vq: I could resync the mozooo-CWS to a more recent milestone which contains
the SYSTEM_ZLIB changes. Then, I suggest committing your change to config_office
on the mozooo-branch - no matter which CWS is to be integrated last (fix2 or
ooo), it needs to be resynced to the latest master then, anyway. This will
certainly lead to a conflict, which can be resolved when it happens (which is
still before integration).
In the unfortunate case that fix2 and ooo are integrated at the same time, the
conflict can also be resolved at integration time.

What do you think?

> never build into a "source" directory. there _are_ reasons why there are output
> trees which contain the platform name

fs->wind: when you're back from chinese new year :), could you please care for
this and change the build process so that we do not build the unneeded zip files
into the source directories?

vq->fs: Yes, please resync.

Wind->hjs
>why zip them when they are unzipped again just one second later?
They are not unzipped later. They are zipped and put to zipped directory so you
can build OOo/SO with mozilla addressbook support without making a full build of
mozilla. 
Wind->fs
>change the build process so that we do not build the unneeded zip files
>into the source directories?
If we do not build the zip files, we have to build mozilla every time we want to
build OOo/SO with mozilla addressbook support. 
If we zip them to output tree, then if we clean the output tree, we have to
build mozilla once more.
Is it OK?

> If we do not build the zip files, we have to build mozilla every time we want
> to build OOo/SO with mozilla addressbook support.

No, I don't think so. We have the following possible scenarios:
1. Don't want to buid Mozilla at all (e.g. Hamburg release engineering for SO)
   => don't use the "--enable_build_mozab" switch at all
   => the zip files (which are present because we checked them in) are build as
      before

2. build OOo and Mozilla the first time
   => use "--enable_build_mozab"
   - building "moz" would /not/ create the zip files, but only the resulting
     headers, libs, and mozruntime.zip

3. build OOo a second time
   => use "--enable_build_mozab"
   - building "moz" should recognize that nothing changed, which can be done
     using a flag file such as CREATETARBALL, and /not/ build Mozilla again

Isn't this how it already works today?

In any case, I think the zip files are only needed for scenario 1., and we can
assume that if somebody wants to use scenario 1., then the latest and up-to-date
zip files are already present (e.g. because we check them in).
This way, there would no need to explicitly create the zip files during build -
would it?

> If we zip them to output tree, then if we clean the output tree, we have to
> build mozilla once more.
> Is it OK?

I think this would be perfectly OK. You always need to "rebuilding a project"
when you clean your output tree. Since "building" Mozilla is part of "rebuilding
the project moz", I would expect this behavior :)

Created attachment 12790 [details]
Files that we copy from mozilla

>Created an attachment (id=12790)
>Files that we copy from mozilla
format is OpenOffice SpreadSheet.
There are five sheets in it, include all files we copy from mozilla build tree.

I'm going to resync mozooo to SRX645 m27 *now* ....

resync done - mozooo is now based in SRX645 m27

change subcomponent to 'none'

Created attachment 12868 [details]
Using a makefile: extractfiles.mk to copy files from mozilla build tree instead of using shell scripts

Created attachment 12869 [details]
Using a makefile: extractfiles.mk to copy files from mozilla build tree instead of using shell scripts

I had created a makefile (extractfiles.mk) to copy files from mozilla build
tree. We never need moz.$(OS).sh now. This time it will never build
$(OS)$(COM)$(CPU)*.zip into zipped when you set BUILD_MOZAB=TRUE and build moz
project. It will just copy all the necessery files to where they should be. 
  As an optional,you can use "dmake zip" to build $(OS)$(COM)$(CPU)*.zip, they
will be put to $(out)$/zipped.

Wind, this sounds great. Where do we need to put the extractfiles.mk? Is it to
replace moz/makefile.mk?

>Where do we need to put the extractfiles.mk?
Side by makefile.mk .
It includes long file lists so I used a new file . In makefile.mk, I use
.INCLUDE to load it.

wind->hjs
>has anyone yet checked that this
>doesn't conflict with the "hand tailored" "pkg-config" supplied in the module
>"pkgconfig" (SRC680)?
There are no conflict now.
mozilla configure alway checks the version of the pkg-config. It need version
0.7.0 or newer. So it will not use pl's version. Instead, it will use
gtk-config,glib-config ...... If you install the right version of the packages
needed by mozilla, these files will be there.
And pl had remove pkg-config. See
http://www.openoffice.org/source/browse/external/gtk/pkgconfig/Attic/pkg-config.pl
#i22713# upgrade to gtk-2.2, cleanup

wind->hjs
>has anyone yet checked that this
>doesn't conflict with the "hand tailored" "pkg-config" supplied in the module
>"pkgconfig" (SRC680)?
There are no conflict now.
mozilla configure alway checks the version of the pkg-config. It need version
0.7.0 or newer. So it will not use pl's version. Instead, it will use
gtk-config,glib-config ...... If you install the right version of the packages
needed by mozilla, these files will be there.
And pl had removed pkg-config. See
http://www.openoffice.org/source/browse/external/gtk/pkgconfig/Attic/pkg-config.pl
#i22713# upgrade to gtk-2.2, cleanup

Migrate to a new account for security reasons.

Hi,Frank
    I have checked in my last changes for i11424. I have tested them on
following environments:
    a. 4nt & vc6  srx645
    b. 4nt & vc7 src680
    c. tcsh & vc6 src680 src645
    d. linux & gcc src645
    e. solaris & forte 6u1 src680
   
    It will not create the zipped files by default. We can use "dmake zip" to
create the zipped files after we build mozilla. And they will be put to
$(OUT)$/zipped$/.

Created attachment 13066 [details]
patch file for the mozooo CWS with all changes applied

Comments to attachment Wed Feb 11 20:35:00 -0800 2004: moz_ooo.zip
  1. Using a makefile: extractfiles.mk to copy files from mozilla build tree
instead of using shell scripts named moz.$(OS).sh. It is included in makefile.mk. 
  2. Does not create the not needed zipped files. If you need it, you can use
"dmake zip" to create them. They are put to $(OUT)/zipped.
  3. Modify connectivity/source/drivers/mozab/makefile.mk to make it workable
with both the old mozab tarballs or the new files we build from mozilla source
in moz project. 

This pretty much looks as if we are through with this, which is great - Thanks Wind!

Martin, do we want to have this in one of the ooo11fix* workspaces, so it will
be part of some 1.1.x?

Wind, I resynced the mozooo CWS to SRC680 m30, and tried to build it in the SO
environment. I did not yet try in the OOo env.
Unfortunately, the moz module doesn't compile in the SO env: It stops with the
error message:

dmake:  extractfiles.mk:  line 140:  Error -- cygpath: No such file or directory

Could you please have a look at this?

forgot to mention:
unxlngi5.pro compiles fine, the problem occurs on wntmsci8

cygpath is included in cygwin.
I used it to convert dos format path to posix format to use $(GNUCOPY) to copy
folders. Since there is not a cygpath in SO env. I will try to find another way
to copy them in 4nt env.

> cygpath is included in cygwin.
> I used it to convert dos format path to posix format to use $(GNUCOPY) to copy
> folders. Since there is not a cygpath in SO env. I will try to find another way
> to copy them in 4nt env.

Hi, I still don't have full network access, so I cannot check that what I'm
going to say now is fully valid, but we need bash from cygwin now to build
mozilla even in W32-4nt. Therefore the fail just shows that cygpath is missing
in the SO environment. How about asking ause about his opinion to add
cygpath to the SO environment.

@ause: What do you think?

Just a comment to ease the implementation of cygpath into to SO
environment: cygpath.exe is a native W32 program, it'doesn't depend
on a cygwin dll, so you can just copy the newest cygpath executable
to your SO environment without the need to check/update the rest
of the used cygwin tools.

Created attachment 13887 [details]
updated files

wind->vp
  I had got a way. I used "copy /QS". It does the same thing "$(GNUCOPY) -r"
does. You can checkout the last extractfiles.mk with tag cws_src645_mozooo or
get it from the last zip file I had attached.

Wind, I checked out your latest changes and build them in an SO environment,
which worked fine. I did not yet test in an OOo environment - currently I am
struggling with the fact that the setup.exe resulting from the SO build silently
terminated without any error message :(

I had checked the installsets. We losed a lots of files, a normal installset is
about 100M, but there are only 84M in mozooo's.
Maybe you need rebuild it.

already did that - I removed the complete output trees and rebuilt from scratch
(at least all projects which are part of the CWS) - no result :(

i noticed on an other CWS that i lost a lot of indirect dependencies after
resyncing. this may explain the reduced size ;-)
especially check for the big apps (sw680mi.dll, sd... etc.). even better, check
the errorlog in your "instsetoo" output tree.

in opposite to me, Wind also had the idea to look into the logfile, and pointed
out that nearly our complete "common" output tree was missing. I corrected this
and rebuilt, and it seems that everything's running fine now.
I still have to do some test in the OOo environment (to see if everything there
survived the resync), and plan to get rid of this issue then :)

What is the status of this issue now?

Since mozab04 has been integrated, and thus we're based on Mozilla 1.7
components now, I am going to resync mozoo to 680m46. Wind, I would then like to
ask you to check whether this still works (which I suppose it does).

Besides this, our RE suggested to work on some of the dependencies, especially
on Linux, e.g. gtk. Instead of assuming/requesting that they're present in the
system, they could be checked into "external", and used from there, as it's been
done with other projects.
Ause, please correct me if my interpretation was wrong. Of course you may also
speak up (and detail) if it was right :).

After added a new module libIDL and made a little changes to moz and pkgconfig I
had successly build mozilla using a fresh suse 7.1.
I need a legal approval to integrate libIDL V0.8.0 in our build process.

Because of limited resource for OOo2.0, it was decided to shift this tasks to
the next milestone. If somebody will be found, who can implement this until
OOo2.0, then this tasks will be re-targeted.

I personally found this bug very important, because it cans save unbelievable
amount of space on all mirrors. Removing moz/zipped/* can give as ~30MB in
source tarball and also can help to clean-up the tree from binaries!

Unfortunately, i do not know Mozilla code well enough to work on this.

> Unfortunately, i do not know Mozilla code well enough to work on this.

You do not need to know Mozilla code :)
My understanding of the current state of the bug (unfortunately Wind is on sick
leave right now): It builds when the patches attached here are applied, but has
some additional pre-requisites as stated in
http://www.openoffice.org/nonav/issues/showattachment.cgi/12331/faqs_11424.html.

Our release engineering suggested to remove those dependencies, by including the
respective packages in the "external" module. We're already doing something
similar for other projects in OOo. The main problem here might be that we seem
to have different versions: For instance, there's already a GTK version in our
tree, but the version as currently required in
http://www.openoffice.org/nonav/issues/showattachment.cgi/12331/faqs_11424.html.
I think the next task would be to check whether this can be changed.

side note: I found the Mozilla build environment pretty simple, when I used it
the first time (long ago). Honestly, it's much less trouble to build Mozilla
than to build OpenOffice.org :)

please do not add new prerequisites to the module "external". use the project
"external" instead to create a new module.

there are in general two ways to solve the problem of the dependencies:
- try to setup the configure options to minimize the build to the required parts.
if this is not sufficient
- supply the required packages as tarballs (see other modules in the project
"external").

anyway, introducing a dependency which results in requiring two different
versions of one package isn't an option.

also be aware that for OOo it's a common way to build against installed packages
(take prerequisites from the system).

> please do not add new prerequisites to the module "external". use the project
> "external" instead to create a new module.
Can we just use system libraries for OOo for the moz build and let configure
check if all prerequisits are met? (For OOo only, enabled by a switch.)

If yes I'm willing to spend some work on this.

fs,wind: Can I use your mozooo cws?

Wind->Volker
Yes. You can use mozooo. But I suggest you do't use it. Since I do't know when
it can be integrated.

For whom may concern...
For FreeBSD, there aren't runtimes, so we build everytime
in the ports framework.

For 1.7b I use cws_srx645_mozooo, dated at 2004/Oct/16
cws_srx645_mozooo.20041016.tar.gz
however, it doesn't work for 1.1.x series, so I also have
another tar ball; namely checked out at 2004/Feb/03
cws_srx645_mozooo.20040203.tar.gz (adding missing moz/prj/build.lst)
ftp://ftp.freebsd.org/pub/FreeBSD/ports/local-distfiles/maho/openoffice.org/

See
http://www.freebsd.org/cgi/cvsweb.cgi/ports/editors/openoffice-1.1-devel/files/moz-patch
for details...

is it correct? what is the current situation of this issue?
thanks for all,

Wind->maho 
For 1.7b you had better use the current file. I had checked in a little patch to
strip components before zip them.
For 1.1.x
If dated at 2004/02/03 does not work, you can try date 2004/3/17.

cmc->vq: I have patches to use system-mozilla and configure tests to check for
prerequisites at http://people.redhat.com/caolanm/SRC680_m61/ (the systemmozilla
set of patches). They work fine, and you can go ahead and commit them (to a new
workspace I recommend) if you are interested. The thing is that the prerequiste
for xmlsecurity is the existance of a public PK11_GetCertFromPrivateKey in
libnss3 which is available in mozilla cvs, but not in a release yet I think. The
config_office patch at
http://people.redhat.com/caolanm/SRC680_m61/noworkspace.iNONE-systemmozilla.config_office.patch
explains this if the symbol is not available. 

With the integration of rene's openldap patches some minor modifications may
have to be made to them.

vq->cmc: I would prefer to include the possibility to build the mozilla 
libraries additionally. I haven't looked at your patches, I guess I can
steal some configure checks from them ;) but I don't want to play with
the system stuff because I'm working mainly on Windows.

My plan is to check the requirements to build mozilla with configure when
--enable-build-mozab is used and check the existence of the precompiled
moz/zipped/*.zip files for the current os. This way we can immediately
ommit the prebuild libraries and point the builder to a webpage with
the precompiled libraries if he really wants to use them.

Wind did all the work, but I really like to push to get this finished and
integrated.

P.S.: The branch name cws_srx645_mozooo for a 680er cws is a bit confusing ;)

hmm, reading all this, it sounds as if we could combine cmc's patches with the
ones from Wind, to get a good version which builds Mozilla during OOo build, if
all pre-requisites are met.
To me, this sounds like a good first result to integrate ... Any volunteers?
Volker? :)

A next step could be (not sure whether it makes sense) to put some
pre-requisites into our tree, as we already do for some GTK version. This would
allow building even if the system doesn't fulfill all requirements. Don't know
if this makese sense, however - I'd be interested in the opinions of you guys
who you know the build system like the back of your hand.

In any case, we could separate those steps, so we can integrate the work done so
far much faster.

> To me, this sounds like a good first result to integrate ... Any volunteers?
> Volker? :)
Yep. Can you add me to the members of the mozooo cws?

> A next step could be (not sure whether it makes sense) to put some
> pre-requisites into our tree, as we already do for some GTK version. This would
> allow building even if the system doesn't fulfill all requirements. Don't know
> if this makese sense, however - I'd be interested in the opinions of you guys
> who you know the build system like the back of your hand.
Is this necessary? You, I mean hamburg environment, can keep using the prebuild
libraries, but they could be removed from the OOo sources and build on demand.

> Yep. Can you add me to the members of the mozooo cws?
Thanks & Done.

> Is this necessary? You, I mean hamburg environment, can keep using the prebuild
> libraries, but they could be removed from the OOo sources and build on demand.

I cannot really judge this. I would *suppose* that it's desirable to have a
really self-contained source tree, which doesn't have strict requirements like
"you need <product> version x.y.z". Yet, I know that there are different
opinions :), which is perfectly okay.

Short status on building moz on W32.

Requirements:
* Get and install wintools, see here:
   <http://www.mozilla.org/build/win32.html#config>

  Note: Don't set the PATH variable.

* Get and install VC71 (.NET2003) built versions of the glib & libIDL
  libraries <ftp://ftp.mozilla.org/pub/mozilla.org/mozilla/libraries/win32/>.
  You need vc71-glib-1.2.10-bin.zip and vc71-libIDL-0.6.8-bin.zip.
  Do not copy them over your existing moztools directory; instead, pick a
  separate location. It is perfectly ok to unpack them into the moztools
  directory by keeping the vc71 directory.

  Note: Don't set the PATH variable.

* Get the mozilla 1.7b sources from here:
<http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.7b/src/mozilla-source-1.7b-source.tar.gz>
and copy them into $SRC_ROOT/moz/download/

(The following part should be handled by configure, I'll come to this later)
* Set the following environment variables (with my values as an example):
   BUILD_MOZAB=TRUE
   MOZ_TOOLS=c:\moztools
   GLIB_PREFIX=c:\moztools\vc71
   LIBIDL_PREFIX=c:\moztools\vc71

* Just build.

I tested with W32-tcsh, can someone please check W32-4nt?

I could try with W32-4nt on my private machine, but:
- it will take a while 'till I have time for this (2 weeks or so)
- this machine already has a Mozilla and a OOo build environment, so it's not really
  clean in a sense which might be needed here.

Given that W32-4nt is rotten, anyway (for example, install sets don't build due
to a lot of wrong path notations, which I didn't submit, yet), it seems that not
much people are really using this setup, so it might be okay to go on without a
W32-4nt check for the moment.

Hi,Volker
  I just had a look at your changes to moz. It should work I think in 4nt. But
My suggestion is:
  1. Introduce a new environment variable : MOZILLA_DISTFILE_DIR, it should
point to a folder which contains all the necessary packages:
   mozilla-source-1.7b-source.tar.gz,vc71-glib-1.2.10-bin.zip and
vc71-libIDL-0.6.8-bin.zip,wintools.zip
  2. copy mozilla-source-1.7b-source.tar.gz to moz/download in moz/makefile.mk
  3. unzip all other three zip files to a temp dir and add them to PATH durring
build.

BTW:You can Introduce an OOO_DISTFILE_DIR environment variable and let
developers put all third party files (such as gpc.xx.zip,dbghlp.dll) there and
auto use them in our makefiles. 
We can go even further to use wget to fetch the needed files while building as
freebsd build system and garnome build system does.

Hi,Frank
  Could you please add module gtk to cws mozooo, so that I can add libIDL to it.
To build mozilla in a unix like environment, we had all necessary libraries
built but libIDL. So I would like to add it to our source tree.

> We can go even further to use wget to fetch the needed files while building as
> freebsd build system and garnome build system does.

Oh, I like this idea! Everytime I'm going to pull a new source, I forget the
externals in the first run, which makes configure break ...

> Could you please add module gtk to cws mozooo

Done.

Hi Wind,Frank
> I just had a look at your changes to moz. It should work I think in 4nt. But
> My suggestion is:
> 1. Introduce a new environment variable : MOZILLA_DISTFILE_DIR, it should
> point to a folder which contains all the necessary packages:
> mozilla-source-1.7b-source.tar.gz,vc71-glib-1.2.10-bin.zip and
> vc71-libIDL-0.6.8-bin.zip,wintools.zip
I like that idea.

> 2. copy mozilla-source-1.7b-source.tar.gz to moz/download in moz/makefile.mk
I don't like copying the 39MB around, but why not.

> 3. unzip all other three zip files to a temp dir and add them to PATH durring
> build.
Sounds like a job for configure.

> BTW:You can Introduce an OOO_DISTFILE_DIR environment variable and let
> developers put all third party files (such as gpc.xx.zip,dbghlp.dll) there and
> auto use them in our makefiles. 
> We can go even further to use wget to fetch the needed files while building as
> freebsd build system and garnome build system does.
Nice idea, but can we do this in a different CWS? I'd like to get this
integrated ASAP.

> -- Additional comments from windly Mon Nov 29  --
> Hi,Frank
> Could you please add module gtk to cws mozooo, so that I can add libIDL to
> it. To build mozilla in a unix like environment, we had all necessary
> libraries built but libIDL. So I would like to add it to our source tree.
Nah, this won't fly, because the gtk module is SO only.

Actually to fasttrack this I'd like to do the following, if --with-build-mozab
is given configure checks for
  mozilla-source-1.7b-source.tar.gz  - for all OS
  vc71-glib-1.2.10-bin.zip, vc71-libIDL-0.6.8-bin.zip, wintools.zip - for W32
in moz/download/

If found: Prepare the W32 build environment / Check the *NIX requirements.

This can be done in the next few days.

Hi,Volker
>Nah, this won't fly, because the gtk module is SO only.
I can see it at http://www.openoffice.org/source/browse/external/gtk/
Are you sure it is SO only?

Hi Wind,

yes, because it is not tagged for OpenOffice, just check
$ cvs co -c

>> 3. unzip all other three zip files to a temp dir and add them to PATH durring
>> build.
>Sounds like a job for configure.
I suggest do this in moz/makefile.mk, so that module moz is self contain. It
will in both OO or SO environment (which does not use config_office any more). 
But it is necessary to check whether the files are exist.
> BTW:You can Introduce an OOO_DISTFILE_DIR environment variable and let
> developers put all third party files (such as gpc.xx.zip,dbghlp.dll) there and
> auto use them in our makefiles. 
> We can go even further to use wget to fetch the needed files while building as
> freebsd build system and garnome build system does.
And I suggest we do these in makefile too. We can add a new makefile
(tg_fetch.mk for example) to solenv/inc, modules which need fetch files can set
a filename and a major location and some mirror sites we can use to fetch the
files then include our tg_fetch.mk. We can also improve tg_ext.mk to use files
from OO_DISTFILE_DIR or fetch them from given url if they are not found in
modules/download.
To fetch all files before build,  we can add a "fetch_all" rule to to
OOoSourceRoot/makefile.mk. A fetch_all rule should be add to tg_fetch.mk to
fetch all file to OO_DISTFILE_DIR.
After all these done, developers can build OOo in this way:
1. checkout source tree
2. configure with --check-files-exist=false
3. dmake fetch_all
4. dmake

> I suggest do this in moz/makefile.mk, so that module moz is self contain. It
> will in both OO or SO environment (which does not use config_office any more). 
> But it is necessary to check whether the files are exist.
That's exactly what I realized after I clicked the commit button ;). 100% agreed.

And I also agree to your other arguments about the fetch_all, but please in a
seperate CWS. After your work to get this module working we should get this
integrated as fast as possible. I hope I find the time to work on this in the
next days.

I'll resync to m63 now.

Hi Wind,

I just added a few checks to configure for the requirements.
ATM I'm only checking for GTK 2.0. Is GTK 1.2.0 also still OK?

>Is GTK 1.2.0 also still OK?
Yes. I just add --with-mozilla-version and --with-mozilla-toolkit to configure.in.
If --with-mozilla-toolkit=xlib then gtk 1.2 and libIDL <= 0.6.8 are used while
build mozilla. If --with-mozilla-toolkit=gtk2 then gtk2 and libIDL >= 0.8 are
needed to build mozilla. --with-mozilla-toolkit is setted to gtk2 by default. 
As many other platform need addtional patch to build mozilla,so developers can
choose an buildable mozilla version and set --with-mozilla-version to use
another mozilla tarball. For example if one have a mozilla-source-1.7.3.tar.gz
in moz/download and have generate a mozilla-source-1.7.3.patch in moz/ he can
then configure with --with-mozilla-version=1.7.3

>> Is GTK 1.2.0 also still OK?
> Yes. I just add --with-mozilla-version and --with-mozilla-toolkit to
> configure.in.
> If --with-mozilla-toolkit=xlib then gtk 1.2 and libIDL <= 0.6.8 are used while
> build mozilla. If --with-mozilla-toolkit=gtk2 then gtk2 and libIDL >= 0.8 are
> needed to build mozilla. --with-mozilla-toolkit is setted to gtk2 by default.
Yep, I saw that. I'll add the gtk 1.2 check for the non-gtk2 part.
 
> As many other platform need addtional patch to build mozilla,so developers
> can choose an buildable mozilla version and set --with-mozilla-version to
> use another mozilla tarball. For example if one have a
> mozilla-source-1.7.3.tar.gz in moz/download and have generate a
> mozilla-source-1.7.3.patch in moz/ he can then configure with
> --with-mozilla-version=1.7.3
Yes, I already implemented a check if the source archive exists, maybe I should
also check if there is a corresponding patch.

Can you check if the configure checks (so far) work on your system?

>
>Yes, I already implemented a check if the source archive exists, maybe I should
>also check if there is a corresponding patch.
>
Actually I want to split the big mozilla patch to some meaningful and OS special
 patchs.  But tg_ext.mk does not support this.

>Can you check if the configure checks (so far) work on your system?
>
Yes, it works.  I had checked it on linux and 4NT.

Created attachment 20832 [details]
Patch to enable automatic installation/use of wintools for W32

The previous patch (just checked in) automatically unpacks/installs
the needed Netscape wintools and the .NET2003 glib & libIDL libraries.

The check for these files is already in config_office.

I tested that it works with W32-tcsh, can someone please test with W32-4NT?

P.S.: I'm going to resync to m66 soon ...

fs->vq: It seems you resynced to m68 - but is it possible that something went
wrong there?

If I diff between anchor and branch tag, then it seems that on the mozooo
branch, a lot of the stuff related to wdevenv (whatever this is) is
re-introduced which originally had been removed in m68.

For instance, look at
  cvs diff -r1.62 -r1.63 configure
You'll see that the variable WDEVENV_PATH is removed from |ac_subst_vars| in
this diff.

Now do a 
  cvs diff -rCWS_SRX645_MOZOOO_ANCHOR -rcws_srx645_mozooo
You'll see that this variable is *introduced* in this diff - which is bad, since
the ANCHOR is 1.63.

That means as soon as mozooo is integrated, the change 1.62->1.63 is reverted -
which probably was not your intent?

same for the changes 1.61->1.62 in configure - all those changes are reverted on
the mozooo-branch, too.
I'll attach a patch which fixes this (but can't check in until at least monday).

Created attachment 20921 [details]
fix resync errors?

tried to apply this to my m65, wntmsci8, 4nt, cygwin. Did a configure with
"--enable-build-mozab", placed the source tar.gz in download, plus the 3
zipfiles which are needed for building Mozilla.

- when you issue a "build" in moz, then it starts building in moz/zippped.
  Shouldn't it build directly in moz? (I tried to make moz_zipped depend on
  moz_mkout in moz/prj/build.lst, but build.pl complains then ...)
  I can work around this by doing a dmake directly in moz, but I suppose
  this is not the way it's intended to be?

- all zips are properly extracted, but when it comes to building Mozilla,
  the configure step fails with
checking whether the C compiler (e:\apps\micros~1.net\vc7\bin\cl.exe  ) works... no
configure: error: installation or configuration problem: C compiler cannot
create executables.
dmake:  Error code 129, while making '.\wntmsci8\misc\build\so_configured_ooo_mozab'
  :(

Hi Frank,

sorry, I simply didn't recreate the configure file. A simple
 $ cd config_office && autoconf
is all that is needed. I'll do that and commit the changes to configure.

(My build script does these things for me and merging the
 config_office/configure file does not make sense. Sorry for the confusion,
I just forgot it.)

> tried to apply this to my m65, wntmsci8, 4nt, cygwin. Did a configure with
> "--enable-build-mozab", placed the source tar.gz in download, plus the 3
> zipfiles which are needed for building Mozilla.
wntmsci8? .NET2002 will not work for SRC680 and the two extra libraries
(libIDL and glib) are vc71 (.NET2003) libraries, I would expect problems.

> - when you issue a "build" in moz, then it starts building in moz/zippped.
>   Shouldn't it build directly in moz?
It does here:
---snip---
build -- version: 1.127

/cygdrive/e/w1/SRC680_m63/moz
mkout -- version: 1.3
------------------------------
Making: ./wntmsci10.pro/misc/ooo_mozab.dpc
dmake subdmake=true  -f makefile.mk  depend=t ALLDPC
------------------------------
No Dependencies
-------------
/bin/rm -f -r ./wntmsci10.pro/misc/build >& /dev/null
/bin/touch.exe ./wntmsci10.pro/misc/remove_build.flag
unzip ./download/wintools.zip -d ./wntmsci10.pro/misc/build/moztoolsunpack
Archive:  ./download/wintools.zip
   creating: ./wntmsci10.pro/misc/build/moztoolsunpack/buildtools/ 
...
---snap---

>  (I tried to make moz_zipped depend on
>   moz_mkout in moz/prj/build.lst, but build.pl complains then ...)
>   I can work around this by doing a dmake directly in moz, but I suppose
>   this is not the way it's intended to be?
No, it is not, but I cannot reproduce :(

> - all zips are properly extracted, but when it comes to building Mozilla,
>   the configure step fails with checking whether the C compiler
> (e:\apps\micros~1.net\vc7\bin\cl.exe  ) works... no
> configure: error: installation or configuration problem: C compiler cannot
> create executables.
> dmake:  Error code 129, while making
> '.\wntmsci8\misc\build\so_configured_ooo_mozab'

Hmm, works here:
checking whether the C compiler
(/cygdrive/c/PROGRA~1/MICROS~1.NET/Vc7/bin/cl.exe  ) works... yes 

Maybe your cygwin installation lacks some files that are needed from
the mozilla configure. Can you check the config.log for the real error?

OK, I dug out my old 4nt and tried to build moz. ... Please update config_office/
and moz/ to the newest version. With the current version I can build moz with
W32-tcsh and W32-4nt.

(I also fixed an inconsistency between $ENABLE_BUILD_MOZAB and $BUILD_MOZAB.)

> wntmsci8? .NET2002 will not work for SRC680 and the two extra libraries
> (libIDL and glib) are vc71 (.NET2003) libraries, I would expect problems

Hmm, maybe. Unfortunately .net 2002 is the only Windows compiler I have at my
private machine, and I'm not willing to buy .net 2003. Since Mozilla itself
compiles fine with 2002 (on the very same system, which also should answer the
question about cygwin), I had the hope to get it going. Anyway.

I'm going to use your latest patches, though now that you tried 4NT yourself, it
may not be that urgent anymore - I just wanted to respond to your "can someone
please test with W32-4NT?" :)

still cannot build moz :(
The configure step for building Mozilla claims that the compiler cannot create
executables. config.log contains
  e:\apps\micros~1.net\vc7\bin\cl.exe: not found
Same result if I do a "./configure" in moz/wntmsci8/misc/build/mozilla
If I manually change the environment variable "cc" from
  e:\apps\micros~1.net\vc7\bin\cl.exe
to
  /cygdrive/e/apps/micros~1.net/vc7/bin/cl.exe
then it finds the compiler, but cannot link the executable because LIB is not
set, and thus LIBC.lib is not found.

Not sure whether this is worth following up with. Since it works on your
machine, Volker, with .net 2003, and .net 2002 is not supported anymore, we can
probably stop this here ...

Sorry for the delay. I had just spend a long time to download a newer cygwin. I
had used cygwin 1.3 for a long time,it works fine. But config_office need cygwin
1.5. :(
With the last config_office and makefile in cws mozooo, I can build mozilla with
W32-4nt. My compiler is .net 2003.

I just did a final minor cleanup and a resync to m69.

What about closing this issue and marking the mozooo cws "Ready for QA"?

Nothing is changed unless "--enable-build-mozab" is used so it is save to
integrate this CWS anyway, but we should verify that with --enable-build-mozab
everything still works.

Once this CWS gets integrated we will also need some documentation, but for
now I'd say we should get it integrated.  

for the record: Volker found out that changing the makefile.mk to contain
  CC:=cl.exe
  CXX:=cl.exe
(instead of the current versions, which contain complete paths) fixes the build
problem I encountered, and suggested this as fix.

With this, I'd also vote for closing this issue as FIXED, and passing the CWS to
QA. Thanks a lot to everybody who contributed to this monster issue :), I'm glad
we finally got there! Especially: Volker, Wind, thanks a lot!

Regarding QA: Is anybody of you guys on the cc'list willing to give this a try
on Linux? We need an independent success report on Linux, before the CWS will
pass QA. Volunteers?

He guys, please use "dmake patch" and "dmake create_patch" when creating/changing
patches.

I fixed that for the 1.7b patch and Rene's 1.7.5 patch.

(But the 1.7.5 patch doesn't work for W32 even though I already fixed three
obvious omissions from the 1.7b patch)

P.S.: If you want to have unidiff patches you have to change 'diff -rc ..'
to 'diff -ru ..' in tg_ext.mk.

The mozilla-source-1.7.5.patch I just committed successfully build for me
with W32.

I had just add --disable-postscript and --disable-freetype2 to moz/makefile.mk
and then successfully built mozilla from mozilla 1.7.5 in my linux box.
				

vq->wind,fs: What do you think about making 1.7.5 the default choice when
--with-mozilla-version=x.y.z is not given and also renaming --enable-build-mozab
to --enable-build-mozilla (that's what we're doing)?

And then integrate and close this CWS/issue.

>What do you think about making 1.7.5 the default choice when
>--with-mozilla-version=x.y.z
I had just successfully built connectivity with the tarball delivered from 1.7.5.
So there is no problem to move to mozilla 1.7.5.
>renaming --enable-build-mozab
>to --enable-build-mozilla (that's what we're doing)?
No problem.

And can we remove the freetype2 and postscript related code from the patch for
1.7.5? I  mean if is only a build problem then I had resolve by
--disable-postscript and --disable-freetype2.

->vq: sounds good to me (I don't think that the bugs they introduced in 1.7.5
will affect us :)

OK, I changed the default version to 1.7.5 and changed the name of the switch
to --enable-build-mozilla.

I can successfully build on the following platforms:

- GNU/Linux on x86 with gcc-3.4.1 and visibility+enum patches
- Windows with .NET2003
- GNU/Linux on AMD64 with gcc-3.4.1 and visibility+enum patches

CWS mozooo and therefore this issue doesn't depend on issue 17187. That is a
seperate effort -> removed from dependency list.

vq->fs: How about setting this issue to Resolved/Fixed and marking mozooo
"Ready for QA"?

I'm in for it.

Since this issue affects primarily the build process, I suggest that somebody
familar with this process verifies the issue/patch. Pavel, since you did
successfull builds on that many platforms, how about you? :)

Wind, would you be able to provide install sets for this CWS, so we can pass
them to MSC, to verify the functionality?

resyncing to m72

build confirmed with
FreeBSD 5.3/i386 + gcc 3.4.1 visibility fix and enum patch

Building installset

fs: I still have to confirm the build work on Solaris/SPARC, but have no time
for it now ;-(

But other system works.
I have one small issue on MacOS X, but we can do that later.

The project moz itself compiles fine on Solaris/SPARC with

$ CC -V
CC: Sun C++ 5.5 2003/03/12

reopening.

On Solaris/SPARC, include files are not delivered. Deliver tells me:

        ./unxsols4.pro/lib/libplc4.so && cp -f
./unxsols4.pro/misc/build/mozilla/dist/lib/libplds4.so \
        ./unxsols4.pro/lib/libplds4.so && cp -f
./unxsols4.pro/misc/build/mozilla/dist/lib/libnss3.so \
        ./unxsols4.pro/lib/libnss3.so && cp -f
./unxsols4.pro/misc/build/mozilla/dist/lib/libssl3.so \
        ./unxsols4.pro/lib/libssl3.so && cp -f
./unxsols4.pro/misc/build/mozilla/dist/lib/libsmime3.so \
        ./unxsols4.pro/lib/libsmime3.so && \
        echo >& /dev/null
chmod -R 775 ./unxsols4.pro/lib
touch ./unxsols4.pro/misc/build/so_moz_lib_files
/home/oo/BuildDir/ooo_SRC680_m73_src/moz/zipped
------------------------------
Making: ../unxsols4.pro/misc/moz_unzip.dpc
dmake subdmake=true  -f makefile.mk product="full" depend=t ALLDPC
------------------------------
No Dependencies
-------------
Does not need build mozab zipped!
deliver -- version: 1.78
COPY: build.lst ->
/home/oo/BuildDir/ooo_SRC680_m73_src/solver/680/unxsols4.pro/inc/moz/build.lst
COPY: ../unxsols4.pro/inc/ldap/ldap-standard.h ->
/home/oo/BuildDir/ooo_SRC680_m73_src/solver/680/unxsols4.pro/inc/mozilla/ldap/ldap-standard
COPY: ../unxsols4.pro/lib/libnspr4.so ->
/home/oo/BuildDir/ooo_SRC680_m73_src/solver/680/unxsols4.pro/lib/libnspr4.so
COPY: ../unxsols4.pro/lib/libplc4.so ->
/home/oo/BuildDir/ooo_SRC680_m73_src/solver/680/unxsols4.pro/lib/libplc4.so
COPY: ../unxsols4.pro/lib/libplds4.so ->
/home/oo/BuildDir/ooo_SRC680_m73_src/solver/680/unxsols4.pro/lib/libplds4.so
COPY: ../unxsols4.pro/lib/libxpcom.so ->
/home/oo/BuildDir/ooo_SRC680_m73_src/solver/680/unxsols4.pro/lib/libxpcom.so
COPY: ../unxsols4.pro/lib/libxpcom_compat.so ->
/home/oo/BuildDir/ooo_SRC680_m73_src/solver/680/unxsols4.pro/lib/libxpcom_compat.so
COPY: ../unxsols4.pro/lib/libnss3.so ->
/home/oo/BuildDir/ooo_SRC680_m73_src/solver/680/unxsols4.pro/lib/libnss3.so
COPY: ../unxsols4.pro/lib/libssl3.so ->
/home/oo/BuildDir/ooo_SRC680_m73_src/solver/680/unxsols4.pro/lib/libssl3.so
COPY: ../unxsols4.pro/lib/libsoftokn3.so ->
/home/oo/BuildDir/ooo_SRC680_m73_src/solver/680/unxsols4.pro/lib/libsoftokn3.so
COPY: ../unxsols4.pro/lib/libsmime3.so ->
/home/oo/BuildDir/ooo_SRC680_m73_src/solver/680/unxsols4.pro/lib/libsmime3.so
COPY: ../unxsols4.pro/lib/libmozjs.so ->
/home/oo/BuildDir/ooo_SRC680_m73_src/solver/680/unxsols4.pro/lib/libmozjs.so
COPY: ../unxsols4.pro/lib/libmozz.so ->
/home/oo/BuildDir/ooo_SRC680_m73_src/solver/680/unxsols4.pro/lib/libmozz.so
COPY: ../unxsols4.pro/lib/libmsgbaseutil.so ->
/home/oo/BuildDir/ooo_SRC680_m73_src/solver/680/unxsols4.pro/lib/libmsgbaseutil.so
COPY: ../unxsols4.pro/lib/libldap50.so ->
/home/oo/BuildDir/ooo_SRC680_m73_src/solver/680/unxsols4.pro/lib/libldap50.so
COPY: ../unxsols4.pro/lib/libprldap50.so ->
/home/oo/BuildDir/ooo_SRC680_m73_src/solver/680/unxsols4.pro/lib/libprldap50.so
COPY: ../unxsols4.pro/lib/libfreebl_hybrid_3.so ->
/home/oo/BuildDir/ooo_SRC680_m73_src/solver/680/unxsols4.pro/lib/libfreebl_hybrid_3.so
COPY: ../unxsols4.pro/lib/libembed_base_s.a ->
/home/oo/BuildDir/ooo_SRC680_m73_src/solver/680/unxsols4.pro/lib/libembed_base_s.a
COPY: ../unxsols4.pro/lib/libmozreg_s.a ->
/home/oo/BuildDir/ooo_SRC680_m73_src/solver/680/unxsols4.pro/lib/libmozreg_s.a
COPY: ../unxsols4.pro/lib/liblber50.a ->
/home/oo/BuildDir/ooo_SRC680_m73_src/solver/680/unxsols4.pro/lib/liblber50.a
COPY: ../unxsols4.pro/bin/mozruntime.zip ->
/home/oo/BuildDir/ooo_SRC680_m73_src/solver/680/unxsols4.pro/bin/mozruntime.zip
Statistics:
Files copied: 21
Files unchanged/not matching: 1938

The problem in in extractfiles.mk. This change fixed it for me:

--- extractfiles.mk~    2005-01-22 20:37:22.087747000 +0100
+++ extractfiles.mk     2005-01-22 20:37:22.088190000 +0100
@@ -284,8 +284,8 @@
        +$(COPY) /QSZ $(PUBLIC_PATH)* $(INCLUDE_DIR)
 .ELSE
 .IF "$(OS)"=="SOLARIS"
-       +$(GNUCOPY) -pr $(INCLUDE_PATH)* $(INCLUDE_DIR)
-       +$(GNUCOPY) -pr $(PUBLIC_PATH)* $(INCLUDE_DIR)
+       +$(GNUCOPY) -prL $(INCLUDE_PATH)* $(INCLUDE_DIR)
+       +$(GNUCOPY) -prL $(PUBLIC_PATH)* $(INCLUDE_DIR)
 .ELSE
        +$(GNUCOPY) -prL $(INCLUDE_PATH)* $(INCLUDE_DIR)
        +$(GNUCOPY) -prL $(PUBLIC_PATH)* $(INCLUDE_DIR)

This was the fastest change, correct would be to delete .IF etc...

GNU copy (which GNUCOPY is designed to be) always supports -L. I'd suggest not
handling links like this. Just copy them and then deliver. Better than depending
on cp's handlink of links.

With this small change OOo m73 compiled completely.

The gnucp included in so build env does not support -L option, that is why I add
a switch to distinguish solaris and none solaris. 
And have a look of your log, I find thses lines
    COPY: ../unxsols4.pro/inc/ldap/ldap-standard.h ->
    Files unchanged/not matching: 1938
It tails that all include had copied to unxsols4.pro/inc. 

To you know,deliver and extractfile.mk are different things. extractfile.mk copy
all files from unxsols4.pro/misc/build/mozilla/dist/include to unxsols4.pro/inc.
Deliver then copy them to solver.
To verify extractfile.mk's work, you can now:
  1. remove your patch from extractfile.mk
  2. rm -rf unxsols4.pro/inc/*
  3. dmake zip > build.log
  4. verify these are two lines in your build.log
gnucp -pr ./unxsols4.pro/misc/build/mozilla/dist/include/* ./unxsols4.pro/inc
gnucp -pr ./unxsols4.pro/misc/build/mozilla/dist/public/* ./unxsols4.pro/inc
  5. verify there are all mozilla include file in unxsols4.pro/inc, in my build is:
     ls unxsols4.pro/inc/ |wc
     131     131    1126

I probably see the problem now 8)

I have just removed all my changes from moz module and did a clean build. I see
lines like you said, but:

$ pwd
/home/oo/BuildDir/ooo_SRC680_m73_src/moz
$ ls -l unxsols4.pro/inc/nspr/nspr.h 
lrwxrwxrwx    1 oo       other          36 Jan 24 22:06
unxsols4.pro/inc/nspr/nspr.h -> ../../../nsprpub/pr/include/./nspr.h
$ cat unxsols4.pro/inc/nspr/nspr.h 
cat: unxsols4.pro/inc/nspr/nspr.h: No such file or directory
$ 

Thus

$ deliver -check|grep nspr
MKDIR:
/home/oo/BuildDir/ooo_SRC680_m73_src/solver/680/unxsols4.pro/inc/mozilla/ldap-nspr
MKDIR: /home/oo/BuildDir/ooo_SRC680_m73_src/solver/680/unxsols4.pro/inc/mozilla/nspr
MKDIR:
/home/oo/BuildDir/ooo_SRC680_m73_src/solver/680/unxsols4.pro/inc/mozilla/nspr/obsolete
MKDIR:
/home/oo/BuildDir/ooo_SRC680_m73_src/solver/680/unxsols4.pro/inc/mozilla/nspr/private
MKDIR:
/home/oo/BuildDir/ooo_SRC680_m73_src/solver/680/unxsols4.pro/inc/mozilla/nsprefm
COPY: ../unxsols4.pro/lib/libnspr4.so ->
/home/oo/BuildDir/ooo_SRC680_m73_src/solver/680/unxsols4.pro/lib/libnspr4.so
$ 

My GNUCOPY is:

$ $GNUCOPY --version
cp (coreutils) 4.5.4

--help contains:

  -L, --dereference            always follow symbolic links

With my patch:

$ pwd
/home/oo/BuildDir/ooo_SRC680_m73_src/moz
$ ls -l unxsols4.pro/inc/nspr/nspr.h 
-rwxrwxr-x    1 oo       other        2276 Jun 20  2000 unxsols4.pro/inc/nspr/nspr.h

Maybe links can cause harm for zip?

Hi,Frank
Do you have any idea on the versions of gnucp?

I find a walkthrough:
We try -L first, if it failed then we skip -L. Look like this:

+$(GNUCOPY) -prL $(INCLUDE_PATH)* $(INCLUDE_DIR) || $(GNUCOPY) -pr
$(INCLUDE_PATH)* $(INCLUDE_DIR)
+$(GNUCOPY) -prL $(PUBLIC_PATH)* $(INCLUDE_DIR) || $(GNUCOPY) -pr
$(PUBLIC_PATH)* $(INCLUDE_DIR)

I had tested it in so build env, it works.
Hi,pjanik
Could you please verify does this work for you?

Not really - ause?

windly: it works, but I'm against such solution because ti only hides the real
problem, depends on the cp version used etc. I'd like to hear ause' opinion.

the version of GNU cp currently found in SO solaris environment is 3.16 (we
might need some update ;-))

anyway i'm afraid SO environment isn't ready to do complete mozilla build
without some additonal tweaking. main issues identified already are too old
tooling and finding prerequisites (tweaked pkg-config to find a shared
"installation" of gtk etc.).

as SO build is, AFAIK, expected to stay with the precompiled binaries, this
isn't a stopper for this CWS. for now we just have to make sure that this
process still works.

regarding the "-L" option of GNU cp i would expect that not too much versions of
cp are around that do not support this switch (it's at least supported in 4.0.35
 which is from 2000).

hjs: but anyway: you have to produce the .zip files in youe environment at least
once. Or you'll use different version/patches like the rest of the community
will use?

I think we should leave only -Lpr version there and fix Sun env.

building it once is no problem in a manually tweaked SO environment. but this
doesn't fit for regular builds.
i'm currently working on fixing/updateing the SO environment without breaking
old versions.

Created attachment 21978 [details]
patches for building moz on IRIX with MIPSpro 7.4

I forgot to add some comments for that patch. It is basically what I needed to
do to get moz to build with MIPSpro 7.4 on IRIX. In the time I started and when
I submitted a cvs up changed the moz_ooo cws so I had to redo some things.
Anyway let me know if it is incomplete. I updated the mozilla-source-1.7b.patch
by doing a dmake create_patch inside OOo/moz.

cheers,
scott rankin

A polite reminder: Can we please set this issue to fixed? Are there different
problems than that the GNU cp in hamburg for solaris comes from the last
stone age? As ause said, this will sometimes be fixed and the Sun builds use
the precompiled libraries anyway. So IMHO we're good to go to QA the mozooo CWS.

@Scott: Sorry, no disrespect for you and your work, but checking/verifying
new patches against moz/ will be much easier once this monster CWS is
integrated into the master. We should try to get it in soon!

I agree. I suggest
- checking in Pavel's fix, so that this works on Solaris/SPARC. For SO RE, the L
switch
  should not be a problem for the moment
- waiting with the IRIX patches until this CWS is integrated. As Volker said,
this doesn't
  devalue Scott's patch, it's just that we should try to get rid of this
two-year-old issue,
  without continuously extending its scope.
  Scott, I'll be happy to work with you on a new issue getting your patches into the
  master, once this beast here made it (though I hope that <hint>people like Wind,
  Volker and Pavel will also help</hint>, to compensate my poor build environment
  knowledge :)

My patch was already committed so I think we can mark this as fixed.
You can count with me for additional testing.

fixed, then

mozooo is "ready for QA now"

- several people built this CWS for OOo on several platforms
- MSC built this CWS for OOo on Linux, works like a charm (also without losing
  functionality :)
- me built this thing for SO on all 4 platforms relevant for SO - still working :)
=> VERIFIED

Thanks for this incredible work to all involved people, in particular Wind,
Volker, and Pavel!

close