[Zlib-devel] MSVC++ projects

[Cosmin Truta]

Hi, Andrei,

Although this answer is coming quite late, I did want to respond to you,
and clarify some issues.


On Mon, 27 Sep 2004, Andrei Polushin wrote:

> > Not being able to test a makefile in some point release does not
> > necessarily invalidate it. Unfortunately, it's safe to claim that not
> > all makefiles that have been tested with 1.2.1, are also tested with
> > 1.2.2.
>
> I understand you, but this I don't think so, you know.
> I think the release must be tested completely, or what is that release
> for?

In principle, you're right, but if we lack the resources to test all
makefiles during some release, (and we do...), then it's better to leave
them in there, rather than remove them. It's easier for users to use
them if they need them, and correct them if it's necessary, rather than
rewrite them from scratch. There is no proof that what I'm saying is the
best way to go, but this is what we, and other people in many other
open-source projects, are doing, and this is what provably works. I
don't recall anyone complaining for running into trouble because of this
policy.

If there are changes in the source code that make us believe some
makefiles or project files will break, then we move these files in the
old/ directory, and either we wait until someone updates them, or we
eventually purge them.


> > > * At least for me, I need to place several files somewhere, not to the
> > > compiler-specific directory. Other Win32 projects, e.g. Borland C++
> > > might then reuse them also. Those files are _platform-specific_.
> >
> > Of course! Platform-specific files should be in the platform-specific
> > directory, not in the project's directory. This doesn't mean that the
> > project cannot be multi-platform. Instead, the project should reference
> > those files, externally.
> >
> > For example: the files "zlib.def" and "zlib1.rc" are Win32-specific, are
> > used by Visual C++ and GCC/MinGW, and may also be used by others. For
> > this reason, the VC6 project (in projects/visualc6) is addressing them
> > in their proper (win32) directory.
>
> It looks like strange for me. It looks like I should ask you to put your
> makefiles into the directory named "makefiles" and write them with external
> references to "win32" directory. It is even possible to write portable
> makefiles there. Possible, but needless!

It is useful when the project is cross-platform. If the project has
branches, then particular configuration branches may point to
platform-dependent files in platform-specific directories; but the
project, as a whole, remains cross-platform.

Sorry I cannot illustrate this with a specific cross-platform project
(I don't have the time to make one right now), but I can give you the
example of using assembler source files. The VC6 project, found in
projects/visualc6/, has branches (configurations) that use contributed
assembler files found in contrib/masmx86/, although the project as a
whole can also function without the contributed asm files. As a test,
try to remove the asm files from the contrib/ directory, and see that
you are still able to build the library and the examples, by choosing
the asm-disabled configuration.

Using platform-dependent dependencies (source files, etc.) is a similar
issue, that does not necessarily reduce the overall ability of a project
or makefile to be cross-platform.


> In this case the simplicity should be preferred. There is no need for
> "projects" directory, because we have no cross-platform projects.

Mark already answered to this. Most IDEs and their projects are
cross-platform nowadays; it just so happens that the VC6 and VC7
projects are not.

Speaking of Visual C: VC6 is an exceptions to not being cross-platform.
VC1.5 is cross-platform: DOS+Win16. VC4 is cross-platform: Win32+Mac.
Even VC7 is cross-platform, if you count CLR and Microsoft .NET besides
Win32. With the advent of 64-bit platforms, it is likely that the future
VC environments will also be cross-platform, serving Win32+Win64.


> > Unfortunately, there are a couple of problems related to your
> > projects.
> >
> > [...]
> > Now you're adding a whole bunch of others: ZLIB60.DLL, ZLIB70.DLL,
> > ZLIBA70.DLL, ZLIB71.DLL, ZLIBA71.DLL...? What for?! This will do
> > nothing but ruin our little DLL business.
>
> Sorry, it seems I already have rationale for that, written at the end
> of the README.vc++: different names are to reduce a risk of
> misconfiguration.
>
> In addition, I want you to remove questions 9, 10, 11, 12, 13 from
> DLL_FAQ.txt, because the problems they describe are solved with those
> ZLIB60.DLL, ZLIB70.DLL, and ZLIB71.DLL.

I wish your DLLs, and the rationale you wrote, could solve our problems,
but it isn't so.

With or without different Microsoft runtimes, there are hundreds of ways
to build incompatible configurations. Use the source code as it is, add
extra code (e.g. minizip), or exclude some of it (e.g. define NO_GZIP,
or define NO_GZCOMPRESS, or define both)? Use the default build options
(memory requirements, deflate parameters, etc.) or customize them (make
zlib faster, or require less memory, with some side effects)? Use the
default __cdecl calling convention, or change it to __stdcall or
__fastcall? What byte packing to use: Microsoft's default, Cygwin's
default, or Borland's default? What kind of C runtime to use: statically
linked and single-threaded, statically-linked and multithreaded, or
dynamically linked? Whose C runtime to use: Microsoft's (static or
dynamic), Borland's (static or dynamic), or Cygwin's? Etcetera.

By combining the above premises, you have a carthesian product of
possible configurations, whose total number is huge. Among all these
possibilities, we chose one, that we believe is convenient for most
users, and that we support. That's ZLIB1.DLL. We do acknowledge that
there are users with different needs, and we encourage them to build
their own versions, but we ask that they use different DLL names, so
that there's no problem of name clashing.

The answers to most questions from the DLL FAQ, including 9-12, (which
is, essentially, our rough view of what is the most desirable
configuration) were established after a long debate. The configuration
we chose is still not perfectly satisfactory. Some of the users of the
old ZLIB.DLL prefer to use Gilles Vollant's configuration. Cygwin users
prefer the Cygwin runtime and byte packing. Delphi users prefer the
Borland runtime. I even received an angry email from an open-source
passionate, in which I had to respond why are we using one of Microsoft
runtimes, instead of an OSI-approved runtime such as Cygwin.

Still, we are happy to notice that ZLIB1.DLL was adopted in a handful of
respectable projects, and now we are responsible to keep our promise of
compatibility.


Long story short, there is a single instance of DLL interfacing that is
supported by us. A radical change in it (and, implicitly, in the
DLL_FAQ) may satisfy a few users, but will probably upset many others.
We do make changes to the DLL_FAQ, but they have to be debated, and the
arguments against the change must end up being refuted, and the negative
impact of the change must be minimal, or null.


> > As stated in README.projects, the projects should act, at least
> > partially, like the official makefiles.
>
> I'm sorry, this is unacceptable:
> * I don't want to compete for "official build" status.
> * I don't want my DLLs to be mixed with zlib1.dll, because
> * I don't want to be made responsible for makefile builds.

If you do not intend to produce an officially-ammended build, then you
have to the support it exclusively on your own. Your contribution has to
be inside the contrib/ directory. Alternately, you can provide us with a
link to your web site, and the link will be added in the "Links" section
of the zlib web site.

> There is no reason to treat makefiles more valuable, just because
> there are many valuable programmers not knowing how to deal with
> them.

You are right when you say that projects' compatibility with the
makefile builds is sometimes too strong a requirement. The restriction
is intended for redistributables: if someone builds a redistributable
using a makefile, and someone else builds another redistributable with
the same name using a project, the user who has applications depending
on both redistributables will run into trouble.

The restriction is particularly important regarding the DLL build,
because there is an officially-ammended *downloadable* DLL build.

But I will consider updating projects/README.projects, to specify that
the requirement of compatibility with the makefiles refers only to
redistributables: not to object files, and not to statically-linked
libraries. Other than that, makefiles are not considered more valuable:
it's just that if they exist already, the projects should follow them.
Similarly, if there is a project that has set up some way to build a
redistributable, a makefile that comes later has to remain compatible
to the project. The latter hasn't happened yet, however.

And programmers are not generally affected by this restriction, which
applies only to the people who make submissions for inclusion into the
main zlib source tree.


> > Furthermore, the project files you submitted suffer from style
> > problems [...]
>
> I understand what you mean, but I have done this intentionally. I have
> also written the rationale for that at the end of README.vc++.
>
> Yes, the maintenance is actually slightly complicated: adding new source
> file may take up to 1 minute.

It's still a style issue. In your solution, sub-projects masquerade as
configurations and clutter the project view. Even the zlib data
structures appear duplicated, and it's easy to get lost, without knowing
what's the same and what's different. This is very confusing, especially
when trying to modify zlib.
And it is a maintainance issue because of the increased possibility of
leaving out one of the "sub-projects" when making an update. (Quite
likely, I might add, since this is about going with mouse clicks over
a bunch of tiny icons, with no possibility of easy scripting.) The
maintainer (if that's different than you) has to go over all this, and
might not be as familiar as you with all check boxes and list items that
are supposed to be updated.

The Visual C++ IDE provides configurations for a reason, and everything
you do in your sub-projects can also be done in configurations. Besides,
configurations do not suffer from the issues mentioned above.

> But the goal was to make this library useful for application developers.
> Typical MSVC application has only two configurations, namely Debug and
> Release.

And the user can add many others.

> Typical workspace contains one project for that application, and
> another one project for each library that application refers. During
> build process, the configurations with the *same name* are built in
> chain, as specified in Project|Dependencies. If the library has the
> configuration with irregular name (such as "Debug ASM"), that chain
> should be built in two steps: first step is to build library (in
> specific configuration), next step is to build an application (in
> another configuration). And what if there will be 9 such libraries?
> It will require 10 annoying manual steps!

Now I see why you did not choose to make multiple configurations. But
this is not a problem, because it is not mandatory for configurations
to carry the same name. They only need to have the same name (which is
sometimes convenient) when the checkbox "Allow per-configuration
dependencies"), in the Project Settings window, is off. If you set it
on, any configuration of any project dependency can carry any name.

The effort of linking a user product to a zlib dependency, is the same
(counting the user's key strokes and mouse clicks), whether it has to be
linked to a particular configuration (advocated by me), or sub-project
(advocated by you).


> Thank you very much for your opinion. I suppose we should learn to
> co-exist in the same directory, not trying to dominate.

We are coexisting, due to zlib's open source license. Every one can
tweak it and use it the way one sees fit. Choose the build settings of
your choice, and you are free to distribute them and support them
yourself.

But when it comes to the contents of the zlib distribution, the aim is
consistency and compliance. It took us a few months to discuss, and
finally agree on the DLL interfacing. I did participate to these
discussions, whose conclusion I recorded into DLL_FAQ. This makes me
a scribe, not really a dictator.

We are providing (non-warranted) support for everything that is inside
the zlib distro. We support other contributors' submissions (source
code, makefiles, documentation, etc.), and in return, we only accept
submissions that do not pose problems that we specifically try to avoid.
Mark Adler has the final word, because he co-owns the code, and he is
the active maintainer. The other members of the zlib-devel list,
including you and me, only submit proposals and recommendations.

If you want to bypass our scrutiny and are willing to provide the
support all alone, then you should distribute your contribution
yourself (as a handful of other developers do), and Mark will be happy
to provide a www link in zlib's website. Or, you can submit the
contribution for inclusion inside the contrib/ directory.

It so happens that there is already a Visual C 7 project, contributed by
Gilles Vollant. Look into contrib/vstudio/vc7. I agree that this project
is incompatible to yours, but then again, every new contributor can come
with something new and incompatible. It does not make sense to come with
a whole bunch of projects and configurations, all of them serving the
same compiler and IDE. Gilles' project is good already, although it may
need updating for VC7.1, as you argued in a previous email. (We might
hear Gilles' opinion as well.)

And there is a Visual C 6 project that is compliant to the Windows
interfacing rules, and, therefore, stored into the main zlib source
tree. It is possible to add even more configuration targets into this
project, to be able to build zlib as a static library, linked statically
to the C runtime, both single-threaded and multi-threaded, as some of
your VC6 project branches produce. Perhaps the next zlib release will
contain that, as well.

But I do thank you for your VC6&7 project contributions.


Best regards,
Cosmin