Re: [Mingw-cross-env-list] Using DLLs instead of static libraries?

[Volker Grabsch]

Joost Kraaijeveld <address@hidden> schrieb:
> On Sun, 2010-02-28 at 20:50 +0100, Volker Grabsch wrote: 
> > Joost Kraaijeveld <address@hidden> wrote:
> > > [...] I would really like to use DLLs instead: I have a set of
> > > rather large libraries with a lot of test programs that all link
> > > to (most) Boost and (all) wxWidgets libraries and it is eating
> > > my disks.
> > 
> > In that case I'd recommend to build one big application DLL
> > file into which the application and all dependency libs are
> > statically linked. Then, create small EXE files which are
> > dynamically linked against that one DLL. This is cleaner and
> > less hassle than using many small DLL files.
[...]
> I understand what you say. But this will require restructuring a fairly
> complex build system that, at last, works on Linux (and all Unixes/Unix
> clones I working on AND the standalone Windows environment that we also
> have) and leads to at least 2 building infra structures.

I fully agree. However, in my experience, you'll end up writing
a separate build script for Windows (and MacOS, for that matter)
anyway. Of course, that separate script reuses the "right" build
system, and "just" adds some additional work to generate the
final package (by running tools like NSIS or macdeployqt).

The one-big-DLL strategy is somewhat tricky, and I haven't actually
used it. I usually get around it with a simple trick:

I put everything into one EXE file, and make it behave differently
based on its file name or its first argument. Under Linux and
MacOS, this works perfectly in combination with symlinks or with
wrapper shell scripts. Under Windows, *.lnk files should do the
trick, too.

If that doesn't work for you, consider reusing the "right"
build system to build your internal libraries etc., and use
a few separate commands in your Windows build script to pack
the big DLL file and to compile the EXE files "by hand", e.g.

    ./configure --host=i686-pc-mingw32
    make  # generates big EXE files which we'll overwrite soon ...

    i686-pc-mingw32-g++ -shared ... -o myapplication.dll
    i686-pc-mingw32-g++ src/main1.o myapplication.dll -o main1.exe
    i686-pc-mingw32-g++ src/main2.o src/main2_helper.o ... myapplication.dll -o 
main2.exe
    ...

    makensis ...

You could also speed up that process by avoiding duplicate builds:

    ./configure --host=i686-pc-mingw32
    make myapplib1 myapplib2 ...

    i686-pc-mingw32-g++ -shared ... -o myapplication.dll
    i686-pc-mingw32-g++ src/main1.cpp myapplication.dll -o main1.exe
    i686-pc-mingw32-g++ src/main2.cpp src/main2_helper.cpp ... 
myapplication.dll -o main2.exe
    ...

    makensis ...

The additional build code is minimal, and could be simplified
further by using wildcards (e.g. "g++ src/main2*.cpp ...").
Okay, it's platform specific, but that's the whole point of
it:

Keep Windows specific hassle separate from your Unix build system!

This is a good idea in general, and it's in fact the reason
why I created mingw-cross-env in the first place. If Windows
depolyment was "just a little bit different", such as Solaris,
I'd have extended an existing cross compiling tool. I really
tried to base my work on Dpkg-cross, which is a great tool
for any Unix-like platform. But I soon realized that it's much
more sensible to treat the Windows platform as a special case
that needs specialized build scripts. I created such build
scripts for some libraries, and named this little collection
"mingw-cross-env".

> Back to thinking.

If you find a nice solution, I'd be happy to read about it.

I'm always interested in having a look at how other developers
tackle and solve these annoying deployment issues.

Maybe my hints are useful to you, maybe they aren't. But I'm
writing them down anyway, because they might be valuable for
the general discussion.


Greets,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR