[Zlib-devel] MSVC++ projects

[Andrei Polushin]

Dear Cosmin,

----- Original Message ----- 
From: "Cosmin Truta" <cosmin at cs.toronto.edu>
Sent: Tuesday, October 19, 2004 1:03 PM

> > > 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.

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.

Maintaining non-portable project requires a single effort from a single
person. That single person might be:

1. Specialist for the single platform, familiar with the project system.
2. Maintainer for himself, so he is self-stimulated.

Maintaining cross-platform project for two platforms will require:

1. Specialist for the first platform, familiar with that project system.
2. Specialist for the second platform, familiar with the same project
system.
3. Manager, able to stimulate and coordinate their work.
4. Some money to make them work together.

Creating 'cross-platform projects' you create just an artificial problem.
Of course, you will have a "lack of resources" if you will create problems
yourself. Of course, you will be unable to test this for the "lack of
resources" you have caused yourself.

Therefore, you are trying to insist, that we should merely ignore testing on
second platform, if we "believe" that everything works well. What for?
Stating that, you are trading the quality for some mysterious cross-platform
idea.

The better quality is much more easily achieved by two independent,
self-stimulated specialists, who will provide enough quality.


> > 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 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.

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

My possibilities are similar to those provided by MSVC itself, so users
should be familiar with them already. And those users, who know how to
change settings, will do that without any advises. And those who know what
the Cygwin is - they will not require advises at all - they already know
exactly what to do.

In practice, there are reasons not to use MSVCRT in real life, and most
people will not use zlib1.dll at all: it is much more reliable to distribute
zlibXX.dll + C runtime privately, into an application directory, because
this is a simple way to avoid many configuration problems.

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

Nothing to describe here. The problem should be solved, not described.


> 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.

You may still build your zlib1.dll for those respectable projects.

There is no impact on MSVC-specific builds, or the dependency is artificial.



> 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.

I do not provide downloadable build. Feel free to provide it yourself.

Again, there is no reason for projects to depend on you.


> > 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.

Did you ever try this yourself?

That checkbox is unrelated to dependencies between configurations. It was
about #include dependencies, like those generated by gcc -M, and how they
are written into exported makefiles. In MSVC 5.0 and earlier, it controls
how such dependencies are stored in a project file, and in MSVC 6.0 it is an
atavism, it does not affect projects at all.

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



Thank you for your time.

Best regards,
// Andrei Polushin