Created attachment 18789 [details]
Patch against solenv from vq04

Forgot the ;) smilie in my first sentence in this issue. Wasn't meant unfriendly. 
:)

looks like your scripting...

.

Hi Volker,

one question before we integrate all this changes as Prio 1. Could you create an
installation set before src680m59 with cygwin and tcsh or is this a new error
for you? 

Ingo,

a few days ago I attempted to build instsetoo_native with W32-tcsh, and had 
the same results.

I have (handy) a successfully compiled copy of SRC680_m59 with W32-tcsh, in 
case any testing/log/whatever is desired.

is -> rodarvus: Have you ever built "instsetoo_native" with W32-tcsh
successfully? In this case I would like to see the log file. But I would also
like to see the logfile from an "instsetoo_native" that was not successfully
built with  W32-tcsh (located in
instsetoo_native/<platform>/<product>/logging/language). 
 

Hi Ingo,

> one question before we integrate all this changes as Prio 1. Could you create an
> installation set before src680m59 with cygwin and tcsh or is this a new error
> for you? 

Before I only build instsetoo (it was the default), m59 switched the default to
instsetoo_native. The patch is not yet (everywhere) properly conditioned for
WITH_SHELL=tcsh, it's *not* ready for integration.

It is not even finished, see:
> ERROR: Could not register all components!

I got a hint from Joerg on IRC, for reference:
---
<JoergB> vq: i36413 is likely to be a PATH-munging issue. The special thing
         about libldapbe is that it is linked to DLLs that are not also in
         solver/bin. The LDAP DLLs are in the mozilla ...runtime.zip and
         need to be loadable in the location where that zip is unpacked.
<JoergB> vq: Can you set up the PATH in use when regcomp is run and then try
         a depends on ldapbe2.
---
and will try that later. 

But that is not everything, the en-US build looks _nearly_ ready, but the
de build, that directly follows has many missing file errors.

P.S.: Why is the build continuing after the:
dmake:  Error code 255, while making 'openoffice_en-US' ? Can you fix that?

> is -> rodarvus: Have you ever built "instsetoo_native" with W32-tcsh
> successfully? In this case I would like to see the log file. But I would also
> like to see the logfile from an "instsetoo_native" that was not successfully
> built with  W32-tcsh (located in
> instsetoo_native/<platform>/<product>/logging/language). 

No, as with vq, I haven't ever built instsetoo_antive with W32-tcsh 
successfully. (also I always used instsetoo, as it was the default)

I tried to build instsetoo_native on SRC680_m58 once, but it failed. I'm 
pretty it failed in the same way as with SRC680_m59, but I can't *guarantee* 
that, as I don't have a copy of SRC680_m58 handy anymore :/

I'll attach a copy of the build log, and a copy of the build output (both for 
SRC680_m59) in a few minutes.

Created attachment 18810 [details]
Compressed output of (cd instsetoo_native ; build)

Created attachment 18811 [details]
Compressed build log for SRC680_m59 with W32-tcsh

is -> rodarvus: Thank you for the logfiles. The systems is not recognized
correctly as a Windows system.

Hi Voker,

the problem with the registration of the ldapbe library is really caused by
libraries of the mozruntime.zip, that have to be extracted in the path.

>But that is not everything, the en-US build looks _nearly_ ready, but the
>de build, that directly follows has many missing file errors.

That the en-US build looks _nearly_ ready is great. We can try to integrate your
changes asap.
The missing files errors are not so dramatic. If the files are really missing,
they have to be delivered. If you want to ignore this and default to the english
files, you can set the environment variable DEFAULT_TO_ENGLISH_FOR_PACKING.

>P.S.: Why is the build continuing after the:
>dmake:  Error code 255, while making 'openoffice_en-US' ? Can you fix that?

Well, this is a known issue. I will do my very best.

Created attachment 18841 [details]
Updated preliminary patch

With the previous patch and

(from Microsoft Visual Studio .NET 2003/Common7/Tools/Deployment/MsiRedist/)
instmsia.exe
instmsiw.exe

(from installer SDK)(This is wrong, the whole dir has to be in the path)
msiinfo.exe
msidb.exe
msitran.exe

copied into solver/.../bin/ I get:
...
Parsing directives
(e:/w1/SRC680_m59/instsetoo_native/wntmsci10.pro/OpenOffice/d13,748,487 bytes in
629 files\\solver\\6                                                           
                   
Total files:            629                                      
Bytes before:    13,748,487
Bytes after:      3,229,283
After/Before:            23.49% compression
Time:                    13.13 seconds ( 0 hr  0 min 13.13 sec)
Throughput:            1022.95 Kb/second

... creating log file log_SRC680__en-US.log 
... cleaning the output tree ...
... removing directory /cygdrive/c/DOKUME~1/q/LOKALE~1/Temp/instsetunpack_135 ...
... checking log file
e:/w1/SRC680_m59/instsetoo_native/wntmsci10.pro/OpenOffice/logging/en-US/log_SRC680__en-US.log

*********************************************************************
ERROR: The following errors occured in packaging process:

ERROR: Could not execute msidb.exe!
ERROR: Could not execute msiinfo.exe!
ERROR: Could not copy
e:/w1/SRC680_m59/instsetoo_native/wntmsci10.pro/OpenOffice/idt_files/en-US/en-US/openofficeorg1959_en-US.msi
to
e:/w1/SRC680_m59/instsetoo_native/wntmsci10.pro/OpenOffice/install/en-US_inprogress/openofficeorg1959_en-US.msi
ERROR: Could not rename
e:/w1/SRC680_m59/instsetoo_native/wntmsci10.pro/OpenOffice/install/en-US_inprogress/openofficeorg1959_en-US.msi
to
e:/w1/SRC680_m59/instsetoo_native/wntmsci10.pro/OpenOffice/install/en-US_inprogress/openofficeorg1959.msi
*********************************************************************
... creating log file log_SRC680__en-US.log 
Tue Nov  2 09:11:28 2004 (08:07 min.)
Packager finished: dmake openoffice_en-US

_nearly_ ;)

Created attachment 18894 [details]
Working, but not cleaned-up yet.

With the previous (still uncleaned) patch I get:

... creating log file log_SRC680__en-US.log 
... cleaning the output tree ...
... removing directory /cygdrive/c/WINNT/TEMP/instsetunpack_22 ...
... checking log file
e:/w1/SRC680_m59/instsetoo_native/wntmsci10.pro/OpenOffice/logging/en-US/log_SRC680__en-US.log

***********************************************************
Successful packaging process!
***********************************************************

:)

vq->is: Where are "hash{'Name'}" and friends set? They sometimes contain
backslashes, like in \registry\schema\org\openoffice\Inet.xcs despite
the setting of "$installer::globals::separator"? If this is "right" from
the beginning I can remove some of the s/\//\\/g;

Err, I meant: s/\\/\//g;

rodarvus->vq: this patch works semi-perfectly for me. (but I'm already able to 
create the installer successfully :) )

on my copy of SRC680_m60, the patch fails for solenv/bin/guw.pl, because I 
don't have the line with JAVA_HOME here. If I manually add CLASSPATH to the 
end of the list, the build still fails. The build only works if I add (again, 
manually) JAVA_HOME to the list of translated variables.

Is this variable JAVA_HOME is already defined (by default) on your copy of 
SRC680_m60 solenv/bin/guw.pl ?

Anyway, good work. I was eager to see the native installer working on w32-
tcsh :)

vq->rodarvus:
> Is this variable JAVA_HOME is already defined (by default) on your copy of
> SRC680_m60 solenv/bin/guw.pl ?

Yes, I'm working on vq04, there are already some changes in that cws for
different problems. I'll see that I find some time to clean-up the patch soon.

BTW, thanks for testing :)

vq->is: Forget my question about the backslashes, I totally missed the
convert_slash_to_backslash call.

The following patch is IMHO ready to go, please have a look. If OK I'll commit
to vq04 and set it "Ready for QA".

Created attachment 18908 [details]
Patch for solenv

is -> vq: sounds great. I will test is asap. Unfortunately I still have some
problems with configure in win/tcsh :-(
The path of the inet.xcs is already defined in scp2. You find in file_ooo.scp:

File gid_File_Oo_Inet_Xcs
    TXT_FILE_BODY;
    Styles = (PACKED);
    Dir = gid_Dir_Share_Registry_Schema_Org_Openoffice;
    Name = "/registry/schema/org/openoffice/Inet.xcs";
End

In scp2 only the slash can be used.

Could you install the OpenOffice.org installation set with the Windows Installer
without problems?

is -> vq: I just checked your patch: it looks great. I can say, that I cannot
see a problem to integrate it in our master code (perhaps there is one problem
(point 3)). There are only some very small changes:

1. globals.pm

+               $pathseparator = "\:"; # ????

The pathseparator is the shell specific separator in the PATH environment
variable. ":" is okay for win-tcsh -> no question marks needed :-)

2. servicesfiles.pm

                my $infoline = "Setting CLASSPATH to $ENV{'CLASSPATH'}\n";
@@ -535,6 +537,7 @@
                if ( $ENV{'PATH'} ) { $oldpath = $ENV{'PATH'}; }
                else { $oldpath = "\."; }
                my $newpath = $path . $installer::globals::pathseparator . $oldpath;
+#              my $newpath = $path . ":" . $oldpath;
                $ENV{'PATH'} = $newpath;

We do not need to add this comment line.  $installer::globals::pathseparator is
the correct pathseparator.
                
3. msiglobal.pm (this is problematic!!!)

-       my $systemcall = $msidb . " -f " . $idtdirbase . " -d " . $msifilename .
" -c " . "-i \*";
+       my $systemcall = $msidb . " -f " . $idtdirbase . " -d " . $msifilename .
" -c " . "-i \\*";

Using "\*" I only masked the "*" (which is probably not necessary). The correct
syntax is (find this in the log file):

Systemcall: msidb.exe -f d:\idt_files\de -d d:\idt_files\de\staroffice8_de.msi
-c -i *

Therefore it seems to be an error to quote the backslash with "\\*"

Hi Ingo!

> Unfortunately I still have some problems with configure in win/tcsh :-(
Tell me, maybe I can help.

> is -> vq: I just checked your patch: it looks great. I can say, that I cannot
> see a problem to integrate it in our master code (perhaps there is one problem
> (point 3)). There are only some very small changes:
Obviously I forgot to remove some of my debug comments, I'll remove 1. + 2.
before committing.

Point 3:
> Using "\*" I only masked the "*" (which is probably not necessary). The
> correct syntax is (find this in the log file):
> Systemcall: msidb.exe -f d:\idt_files\de -d d:\idt_files\de\staroffice8_de.msi
> -c -i *
>
> Therefore it seems to be an error to quote the backslash with "\\*"
No, the problem here is that system($cmd) invokes a shell to expand $cmd,
if it sees a shell metacharacters, therefore I really need
 "msidb.exe ... -c -i \*".
with the \ in $cmd to prevent the globbing. If ActiveState Perl is not
conforming to <http://www.perldoc.com/perl5.8.4/pod/func/system.html> we have
to work around that, but that's easy enough :).

Hi Volker,

well, I solved many problems until now with the configure script. But when I
start bootstrap (which is the final step :-) ) I see, that many variables are
not set correctly (LIB for example). Besides my C preprocessor now fails the
sanity check. But I think this is not your problem. We have to find an easier
way inhouse, to create a win-tcsh environment (then I can test this platform
much easier in the future :-) ).
Are you sure, that your changes of point 3 ("msidb.exe ... -c -i \*") will not
disturb the builds in a 4NT shell? Perhaps you should leave the old systemcall
of "msidb.exe" as it is, and include your new msidb call into your if-block.

Created attachment 18954 [details]
Final patch for solenv

> Are you sure, that your changes of point 3 ("msidb.exe ... -c -i \*") will not
> disturb the builds in a 4NT shell?
I asked ause to test on 4nt/ActiveState Perl if it honors the shellmetas.
No, it doesn't.

Fixed in the last patch, I committed it to vq04.

@is,hjs: I verified that W32-tcsh (en) builds with it, please verify for other
platforms and if possible fasttrack the cws.

The patch looks good -> verified
is->ause: Please integrate into cws vq04

Found in m62.