Will you be using Load-Time Dynamic Linking for zlib?
If yes, will you be checking-in the import lib file too or leaving it to
the developer to provide it. If it's the later, then you will need to take
the path of the import lib file from the user as another argument to nmake.
This kind of makes the build tedious because the user will be required to
get the import lib file from somewhere at link time. He will not be able to
just check-out source and compile a fossil.exe that uses a dynamic zlib. If
you're going to check-in the import lib file then you technically limit the
user to that that particular version of zlib whose import lib file you've
checked-in. But practically I’ve seen mis-matched import lib working fine,
so you might consider going this way.
If no, then there will be code changes to call LoadLibraryEx,
GetProcAddress and few other changes in the fossil source code under
another new conditional compilation variable.
Also note that zlib1 documentation recommends dynamic crt only.
-Gaurav
On Wed, Jun 17, 2015 at 5:54 PM, Jan Danielsson <jan.m.daniels...@gmail.com>
wrote:
> On 17/06/15 11:47, Jan Nijtmans wrote:
> >> Feature: On a few systems I want to have a dynamically linked
> >> fossil.exe. I'm thinking "FOSSIL_DYNAMIC_LINK=1" (changes default ZLIB
> >> to zdll.lib, /MT -> /MD, and link against DLL CRT).
> >
> > Well, I would expect this to be two different options: /MT vs /MD
> controls
> > the C runtime being dynamic or not (which I would expect
> > FOSSIL_DYNAMIC_LINK to do), but whether ZLIB is linked
> > in dynamically should be a separate choice.
>
> Whether to link ZLIB dynamically or not is already a choice, and that
> won't change: ZLIB=zlib.lib vs ZLIB=zdll.lib (using the default zlib
> distribution convention).
>
> The difference would be that the default would change if
> FOSSIL_DYNAMIC_LINK is set. Rationale: Fossil currently assumes "I
> want everything statically linked" (one extreme), I'm looking to give
> developers an easy option to get the other extreme ("I want everything
> dynamically linked" (sans sqlite3, for now)); that is the intended point
> of FOSSIL_DYNAMIC_LINK.
>
> > On windows, I don't see any reason to use a dynamic zlib, it
> > only complicates the re-distribution of fossil.exe since
> > zlib1.dll then always needs to be re-distributed with it.
>
> Again, and this is entirely my fault -- I should have been clearer,
> this is only for internal development systems where one typically has
> dynamic zlib and openssl (and sqlite3, in the future) libraries built
> for other purposes already -- not for redistributable fossil binaries.
> I'm looking to add dynamic linking to libraries an opt-in option, not
> make life more complicated for anyone.
>
> Joe and Gaurav have convinced me that it's better to have an option
> to *disable* automatic zlib builds, rather than an option to enable it.
> That would also mean exactly zero change to the everyday lives of those
> who want the regular static builds using Makefile.msc, which is nice.
>
> I'll make the changes on a branch on Friday or so.
>
> --
> Kind Regards,
> Jan
> _______________________________________________
> fossil-dev mailing list
> fossil-dev@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
>
_______________________________________________
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
