[Zlib-devel] MSVC++ projects

[Andrei Polushin]

----- Original Message ----- 
From: "Cosmin Truta" <cosmin at cs.toronto.edu>
Sent: Saturday, September 25, 2004 1:02 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?


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

Is there any significant reason to put absolutely non-portable win32
projects out of the win32 directory?

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


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

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.


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

For now, zlib60.dll seems to be like zlib1.dll, but they were not tested for
compatibility. Their names should be kept different to prevent occasional
misconfiguration.


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

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.

But the goal was to make this library useful for application developers.
Typical MSVC application has only two configurations, namely Debug and
Release. 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!

With multiple projects everything can be built in one step. Just include
preconfigured (and tested) library project into workspace and arrange
references in Project|Dependencies.


> 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!)

They are not interchangeable. VC70 projects can be converted to VC71, but
such conversion damages them, preventing their usage from VC70 IDE.


> Creating extra projects raises extra problems; what problem do you
> solve, in return?

I'm trying to provide quality-assured, ready-to-use library distribution
for each environment.


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

Thank you very much for your opinion. I suppose we should learn to co-exist
in the same directory, not trying to dominate. There is no reason to treat
makefiles more valuable, just because there are many valuable programmers
not knowing how to deal with them.

With best regards,
// Andrei Polushin