Re: [Win32] tmp issue & NSI (was: Re: [Demexp-dev] Succesful compilation of DemExp under Win32/Cygwin)

[GISQUET Christophe]

Good evening,

On Fri, 4 Mar 2005, David MENTRE wrote:
> Ok, I think I have properly fixed the bug using OCaml platform indepent
> Filename.temp_file (in demexp--cduce--0.3 branch):

Confirmed (no error). Here's the log from the initialization:
==
Autotests compiled.
  perf autotests...done
  norm autotests...done
  pref autotests...done
  browser autotests...done
==

>  set, the value of the environment variable TMPDIR is used
>  instead. Under Windows, the name of the temporary directory is the
>           ---------------------------------------------------------
>  value of the environment variable TEMP, or C:\temp by default.
>  -------------------------------------------------------------

As the file gets deleted once it is no more of any use, I can but accept 
this as a fact. Anyway, it works, so as a good user, I wouldn't question 
it either.

> Moreover, I have modified the Makefile so that client building no longer
> needs CDuce. That should allow you the build the client of the
> demexp--cduce--0.3 branch without installing Cduce (and all its

Which I guess are the following:
==
ocamlfind: Package `cduce' not found
ocamlfind: Package `pxp-engine' not found
ocamlfind: Package `pxp-lex-utf8' not found
ocamlfind: Package `pcre' not found
ocamlfind: Package `netstring' not found
ocamlfind: Package `netclient' not found
ocamlfind: Package `ulex' not found
==

> dependencies). And there is a new make target 'client' that builds both
> native code and bytecode versions of the client.

Worked flawlessly:

$ size lablgtk2-clnt/demexp-lablgtk2-client.{bc,exe}
   text    data     bss     dec     hex filename
 321540   78192   13584  413316   64e84 lablgtk2-clnt/demexp-lablgtk2-client.bc
1079604  777396   11264 1868264  1c81e8 lablgtk2-clnt/demexp-lablgtk2-client.exe

> If you have time to build a new version, let me know if it works under
> Win32.

It does. Package updated with those (unstripped) binaries (no need to keep 
the older ones). By the way, I noticed a much improved load time / 
responsiveness (no further poking around), probably due to better network 
handling.

> Regarding NSI config files, I would like to integrate them in current
> source tree once they're stabilized. If you have suggestions on how to
> do that properly (and even a patch!), I would be glad to hear them.

The scripts were written in like 30 minutes to get an installer out 
quickly, so I'm by no mean an expert. In fact, compared to the original 
version, much has been cut off, in particular the language handling.

But please go ahead, I guess they can serve as a basis to start from. 
Basically, what this script describes is:
- strings in use for display at some install step
- registry keys for uninstall (and other things, but they better stay in a 
config file as the registry is anyway windows-only [gconf being an 
unneeded dependancy IMHO])
- add files to installer and set their install path
- set the uninstall information (registry keys, folders and files to 
delete)

For patches, I thought of adding a new target to the Makefile, but, as for 
the script, there are too many hardcoded pathes:
1) the script needs to be at the root of a GTK distrib folder (bin, lib, 
etc) for the config and library files to be included to the installer
2) the client must be in ../lablgtk2-clnt

1) could be somehow tweaked so that the Makefile produces the proper path 
using pkg-config, but then the pathes returned (/target) may not satisfy 
the NSIS installer builder (which expects them in the shape "C:\...")
2) this is completely dependent on where the script is stored, and not a 
big deal

> Still for NSI config files, the "official" name of the demexp program is
> 'demexp' (and not DemExp). Simplicity is supposed to be a virtue. ;)

KISS'ed it. :D

Best regards,
--
Christophe GISQUET
Hello! This is a signature virus! Please copy me into your .signature