some thoughts on win32 'make install'

[Dirk Hohndel]

Hi Lubomir

On Fri, 2013-10-11 at 17:12 +0300, Lubomir I. Ivanov wrote:
> i've been thinking today on a possible working 'make install' on
> native win32 and i'm starting to doubt it is possible to cover certain
> corner cases...
> 
> now, my guess here is that we want to automatically copy all required
> Qt (this has to include plugins) and third party DLL's to the
> 'packaging/windows/' folder, then possibly even automatically write to
> the NSIS file?

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.

> 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 can hardcode these for testing purposes but then i get a SIGSEGV
> when the perl line is called from the makefile or this when:

It's not exactly a segmentation violation... it's just a 'die' :-)

> 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;
> 
> so instead of debugging the script i went and wrote a perl script that
> does a similar thing - finds dependecies based on $(LIBS), but also
> copies DLLs (from perl) to a target path. it works OK over here.
> 
> 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.

Don't you just love Windows? NOT.

> i guess since the script accepts any number of paths /mylibs/zlib/lib
> can be added or some sort of a search path, but then again i don't
> even have the file there because i simply copy pasted zlib1.dll from
> somewhere.
> 
> so the problem again is lack of standardization of folders on win32
> and i'm not sure the pursue of 'make install' is worth it - i.e. a
> possible solid set of logic can still break for say, 1 of 3 users.
> 
> ideas are appreciated.

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.

Thanks

/D