[Zlib-devel] MSVC++ projects

[Cosmin Truta]

Andrei Polushin wrote:

> It seems that I should agree with Cosmin's rationale for a
> cross-platform projects and their own directory. But there are also
> some problems:
>
> * 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.

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.

For the same reason, you cannot invalidate cross-platform projects just
because they are not tested on some platforms.

They *may* be invalidated when there are reasons to think they won't
work under specific changes; e.g. the modification of the list of source
files in zlib-1.2.0, or the modification of the DLL interface in
zlib-1.2.1. The invalidated files have been moved to the old/ directory,
and they are waiting to be either updated, or (eventually) purged.

> * I think we should not consider "newer IDE versions" at all, for the
> same reason: if the projects we provide were not tested with those
> newer IDEs.

Some people are always working with the latest IDE available, while
others stick to older ones, for various reasons (e.g. familiarity with
the old look-and-feel, refusal to pay for a new version when the old one
is good enough, etc.) Even the software companies that sell the IDEs,
including Microsoft, provide support that spans across several versions.
Of course, if the company drops the support for an IDE version, and/or
noone seems to be using it, and/or its projects do not get updated even
when it's assumed it's necessary -- then, the support for that IDE
version should be removed.

But of course, the support for newer IDE versions should be tested upon
submission, and it should also be demonstrated that a newer set of
project files is necessary (instead of just using the old projects under
the newer IDE).

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

> > Ideally your VC stuff should be in the projects directory.  Are your
> > makefiles dependent on what subdirectory of the zlib distribution
> > they're in?
>
> They depend on directory level depth only. In any case, I have
> replaced "win32" with "projects" in README.vc++ file and repack them
> all again:
> http://a-polushin.narod.ru/zlib-1.2.1.2-msvc-20040922.tar.gz (25K, MD5
> 4c8e7e4b68530eacce1940b703783667)
>
> You may use this variant, at you choice (I don't think you should).

Unfortunately, there are a couple of problems related to your projects.

First of all, we established some conventions on the DLL interface, and
your projects do not respect those conventions. We had enough confusion
in the old days when using ZLIB.DLL, and we introduced some more when
we switched to ZLIB1.DLL, hoping we won't need other changes for a long
time. Another ZLIBWAPI.DLL was accepted as a compatible replacement for
*some* of the old ZLIB.DLL. After a quick search on the net, you'll
realize that the official ZLIB1.DLL is catching on, as quite a few zlib
users already adopted it.
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.

As stated in README.projects, the projects should act, at least
partially, like the official makefiles.

Furthermore, the project files you submitted suffer from style problems.
It's ok that you are providing multiple configurations, but it's not ok
that your configurations are masquerading as actual projects. As a
consequence, maintenance (e.g. in case of the creation of a new source
file in zlib) is unnecessarily difficult, because a project modification
cannot be done just once, but it has to be done for all configuration.

To understand what I mean, please have a look at the VC6 workspace,
found in projects/visualc6. You will find three projects: zlib (which
builds either zlib.lib or zlib1.dll, depending on the user's config
selection), example (which builds example.exe), and minigzip (which
builds minigzip.exe). The configurations are quite versatile:
static lib - debug, static lib - release, static lib + asm - debug, etc.
DLL - debug, DLL - release, DLL + asm - debug, DLL + asm - release, etc.
Given the plethora of build options provided by Visual C, other
configurations can be easily added ad absurdum. No matter how many they
are, they are accessible via the "Build/Configurations..." menu, and do
not clutter the workspace window. The zlib structures appear once in the
class viewer; the zlib source files appear once in the file viewer; when
modifying the source file list (e.g. by adding a new source file),
there's no need to worry about making changes inconsistently.

Another problem is the duplication of the VC70 and VC71 projects. They
are very similar. Are they not compatible with each other? (They should
be!) Creating extra projects raises extra problems; what problem do you
solve, in return?

**

I hope my extensive feedback will help. I'm sorry I only have VC6, and
I don't plan to spend money on VC7 soon. I'm using only the command-line
compiler. So, a contribution from other people are always welcome.
If the contribution complies to the rules stated in README.projects,
and it employs the IDE concepts properly, it should be incorporated into
zlib.


Best regards,
Cosmin