some thoughts on win32 'make install'

[Thiago Macieira]

On sexta-feira, 11 de outubro de 2013 07:26:43, Dirk Hohndel wrote:
> Here's the deal. Who ever needs the installer? I think only I do - and
> I'm not building natively. The situation is different on Mac - even for
> a local user, you need to at least build a working bundle in order for
> the app to run like a regular app - so automating this makes a lot of
> sense. Under Windows, though, I think it's enough to get us to the point
> where we can create reasonably easy to follow instructions that get
> people a working local install.
> 
> Everything beyond that seems 'extra credits' - and I'm not sure it's
> worth it.

That was my assumption too. The script runs quite well in the cross-build. One 
thing I didn't check: is C:\Windows\System32 on $PATH? Because if it is, the 
script I wrote will copy the Windows DLLs too and we don't want that.

> > first, there are some issues with the current commands on my end:
> > 
> > dlls.commands += PATH=\$\$PATH:`$(CC) -print-search-dirs | $(SED) -nE
> > \'/^libraries: =/{s///;s,/lib/?(:|\\\$\$),/bin\\1,g;p;q;}\'`
> > 
> > what happens here is that $(CC) gets expanded to 'cc' and $(SED) gets
> > expanded to ' ' (empty, but there is still 'sed.exe' in PATH), for
> > unknown reasons. $(SED) remains empty at all times, while $(CC) gets
> > populated correctly.
> 
> And as usual all this assumes that the user has sh.exe, sed.exe,
> perl.exe - we need to make sure we document those requirements as well!

I had actually never used $(SED). I first wrote a manual "sed", but then I 
noticed that the Makefile had the variable set, so I started using it.

Feel free to change back to just "sed".

> > perl ./scripts/win-ldd.pl ./release/subsurface.exe
> > Died at ./scripts/win-ldd.pl line 8.
> > 
> > which could be a piping issue with:
> > open OBJDUMP, "-|", $objdump, "-p", $_[0] or die;

Change the latter part to:
	die("$!");

This will at least print the actual error. Maybe no objdump to be found in 
$PATH?

> > then i realized (duh..) that a DLL can depend on another DLL and my
> > libzip-2.dll with zlib1.dll are an example of that. libzip-2.dll does
> > no have zlib statically linked in there and the executable also
> > depends on it. so what can be done here is traverse the DLLs for
> > dependencies (like Thiago does in his script), but then the question
> > is how do we find the path of zlib1.dll, since it does not come in out
> > $(LIBS) variable.

>From $PATH.

I'm assuming that you actually have subsurface.exe running, which means that 
all the DLLs must be found in $PATH. Any missing DLLs are silently discarded, 
since we don't want to package the ones that come with the system in 
C:\Windows\System32.

I could change it so that it complains about missing DLLs except if they are 
in the system32 dir, but I'd need a solution for the cross-build packaging.

> I think that we'd benefit much more from you documenting (in the INSTALL
> file) the steps to get a native local build to work and then focusing on
> getting everything to work well on Windows and closing any bugs / gaps
> with the Gtk version.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20131011/d40355dc/attachment-0001.sig>