mingw-cross-env-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Mingw-cross-env-list] dll hell vs lib dependency hell


From: Volker Grabsch
Subject: Re: [Mingw-cross-env-list] dll hell vs lib dependency hell
Date: Fri, 18 Nov 2011 14:47:34 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

Mark Brand schrieb:
> Lothar May wrote:
> >
> >I just updated to the latest development
> >release, and had to add 4 more dependencies in order to make PokerTH
> >link (libssh2, libnettle, libgmp, libhogweed). If it continues like
> >this, I'll soon be linking to half of mingw-cross-env libs :-).

This is a deliberate design decision. I prefer feature completeness
over binary size.

I'm not 100% happy with that, but alternatively we would have to
support thousands of possible configuration combinations, instead
of the one configuration "every enabled". I would not know how
this could ever be tested and maintained, even if we had more
regular supporters.

Good ideas on that topic are welcome.

> >I'm not blaming anyone, this was obviously a change in gnutls
> >dependencies. But in fact I do not need gnutls, I only link to it
> >because I need curl, and curl may need gnutls...
>
> Why don't you just build curl without ssl support? That should
> dramatically reduce dependencies. I would suggest maintaining your
> own slimmed-down branch of mingw-cross-env where you disable things
> you don't want or need. This is what I do.

I guess this is what most people do with mingw-cross-env.

First phase: They use mingw-cross-env as-is and try to get
their stuff running. That shouldn't be too hard since the
mingw-cross-env configuration emphasizes feature-completeness.

Second phase: They are unsatisfied with the binary size and
adjust a few *.mk files to build with less dependencies. In
other words, they tune mingw-cross-env to fit the particular
needs of their particular application.

> One in a while I rebase it on the development branch.

That's one possibility. The other possibility is to simply keep
the local changes. Those are kept by subsequent "hg pull -u".

Although I agree that "rebase" is the cleaner solution,
simply keeping local changes might be better suited for
Mercurial novices.

Note, however, that if you keep local changes, you might
accidently commit them. So if you do that, any "real work"
on mingw-cross-env should happen a separate repository
checkout.


Greets,
Volker

-- 
Volker Grabsch
---<<(())>>---



reply via email to

[Prev in Thread] Current Thread [Next in Thread]