[Zlib-devel] MSVC++ projects

[Cosmin Truta]

On Tue, 19 Oct 2004, Andrei Polushin wrote:

> As far as I remember, we are not talking about a "lack of the
> resources to test all makefiles during some release". Originally,
> I stated that:
>
> * We should either test our cross-platform projects an all their
> platforms or we cannot claim they are actually cross-platform. Testing
> them might be unnecessary effort, because it is much easier to provide
> platform-specific projects each time.
>
> I will explain each case [...]

Your explanation invalidates the cross-Unix portability of the scripts
"configure" and "Makefile", found in the root directory of the zlib
source, and in most other open-source projects.


> > > 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 [...]
>
> The difference is:
>
> * You have chosen to build one possibility, and to describe others.
>   It seems that you prefer to describe problems, rather than solve
>   them.

Rather, I chose to *distribute* a few possibilities, but I build and
test many others. And those many are still not enough, if you recall the
ASM bug report that I have just filed. After the latest bug report, the
number of configurations that I am testing as a regression, under Visual
C++ 6.0, is 32 (that is, 32!) There are still other configs left out,
most notably the switching on and off of the ZLIB_WINAPI macro and the
inclusion of minizip. But I rely on Gilles testing them.

And I meant Visual C++ only. After VC++ come some tests using other
compilers, Borland, and gcc under Cygwin and MinGW, in a handful of
configurations. Then come a few tests under DOS compilers, and very few
tests under Linux -- I trust that other folks take care of the Linux and
Unix flavors thoroughy enough.

I am also sure that Mark is testing zlib on his Mac.

So the difference is that we do regression testing, but we do not
distribute all the scripts used in regression. I, alone, am testing well
over 50 configurations: scripts, projects, hand-written code snippets,
you name it. I am sure other people are testing a ton of other
configurations under other platforms; and I still claim that we are
unable to test everything we should (see the little ASM accident). But
there's no point in incorporating a ton of build settings in the zlib
distro.

When I enumerated all those configuration possibilities, I meant, we
don't distribute them, but we do test as many of them as possible.

We don't go by saying "we tested 999 configurations, and if you run into
trouble with the 1000th, that's because it's untested." Rather, we say,
about the *semantics* of zlib, that all configurations should work: if
one test fails, then we jump in and fix it. But when it comes to the
application binary interface (the ABI, which is a separate issue from
the semantics), failures are usually instances of misuse (of the proper
configuration), not lack of correctness.

And this is where limits come in: the ABI in the Windows builds are
limited to a few configurations (around 12, maybe), and the user can add
others. Assuming that a VC7 project will be supported in the near
future, this will add at least 4 other configurations. It's true that
the availability of compilers on Windows is bigger than everywhere else.
But the number of Windows configurations, bundled with the zlib distro,
is still way bigger than the number of configurations for any
non-Windows platform (most of them have 1 or 2 configurations).

Changing a configuration in Visual C++, is a matter of selecting
checkboxes and drop-down boxes in the Settings dialog box. Doing the
same in Unix, it's a matter of changing makefile macros, such as CFLAGS.
We expect the user to know how to make the changes, if they are needed
for whatever local reasons.


> * I choose to build 12 most common possibilities for 3 compilers, and
> there is nothing to worry about them.

I don't worry about them, I agree they are common, but I disagree with
the way they are implemented. I agree with the static builds, but I
suggest not to include non-compliant DLL builds.


> Ideally, there should be projects for Borland and makefiles for Cygwin
> that will link to their own C runtimes.

There are. (No project for Borland, because I don't have the IDE at
hand, but there is a makefle.) Cygwin simply uses the Unix-ish
"configure" and "Makefile". These produce static builds, linked to the
corresponding runtimes, and I see nothing wrong with providing a static
build for VC7 as well.

But the Cygwin DLL is incompatible to ours, and is built and distributed
by the Cygwin developers. (So are all the other 20+ DLL builds for
Cygwin).


> > Now I see why you did not choose to make multiple configurations
> > [...]
>
> Did you ever try this yourself? [...]

Oops! You're right, I didn't remember that one correctly, nor did I try
it, not did I look it up in the VC manual and see how it works.

Yet I did run a head-to-head comparison between your projects and my
configurations, right now, to see how easy (or hard) is the task of
binding them to a user's "Win32 Debug" and "Win32 Release"
configurations. I ended up with roughly the same number of mouse clicks
and key presses.

> You are not using projects in practice. Why do you feel yourself
> competent enough to control their style?

It's true there are a few years since I've been using Visual C in my
daytime job, and I couldn't remember all its quirks off the top of my
head. Still, if a source browser (Visual C or anything else) displays
the same data structures multiplicated, as if they were different things
in different places, I think I am "competent enough" to say there's
something wrong about it. That's even more obvious when there is a
possibility to show it the right way, without extra cost (the cost being
expressed in terms of mouse clicks and/or key presses).


> Thank you for your time.

And I thank you for yours.


Best regards,
Cosmin