some thoughts on win32 'make install'

[Lubomir I. Ivanov]

On 11 October 2013 17:46, Thiago Macieira <thiago at macieira.org> wrote:
> 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.
>

yes, it is.

>> > 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".
>

there seems to be a problem with $(CC) as well. i don't think it
should be hardcoded?

>> > 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?

my $objdump = $ENV{objdump} ? $ENV{objdump} : "i686-w64-mingw32-objdump";

objdump is in PATH, but doesn't $ENV return the contents of an env.
variable named 'objdump'?
if so this would fail on windows, because there is not such variable.

the native mingw toolchains usually come with 'objdump(.exe)', in /mingw/bin/

>
>> > 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 don't have the DLLs in PATH, so i copy the files where the .exe is,
which should be the first search location for a DLL, if i recall
correctly.
so we may have to instruct developers to copy all required DLL's in
folder that is in PATH, so that the perl script can find them (but
also subsurface).

i generally dislike this method because, once i package an app i say
"ok, this works fine", but then someone sends me a message "DLL x is
missing" and then i realize it was in PATH and i didn't check the
dependencies well.

the output for a missing DLL is a good idea.

>> 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.
>


lubomir
--