MS windows and gnupg
Robert J. Hansen
rjh at sixdemonbag.org
Sat Sep 17 07:56:01 CEST 2011
On 9/17/2011 12:00 AM, M.R. wrote:
> How about a large user base that already has that tool set at hand,
> and has a natural resistance to install another tool set they are not
> familiar with and have no use for other than to build one single
> application package?
Please forgive my skepticism, but -- well -- I'm skeptical. I don't
think we've seen a single person post to this list saying "I have the
Visual Studio toolchain installed and need to build GnuPG from source,
but can't, since it's an Autotools-based build: could I get a version
that has a .sln buildfile and works with the Visual Studio compiler?"
I'm generally not in favor of making changes to codebases based on
hypothetical use-cases. I think changing codebases to accommodate
hypothesized users quickly leads to a deterioration in overall product
> I very much believe gnupg should be available to the users of MS
> operating systems
Sure, but it already is. Nobody's arguing that GnuPG shouldn't be
available to MS users. The question is whether (a) porting to the
Visual Studio toolchain needs to be done and (b) if so, who will do it.
My answer to (a) is "no."
My answer to (b) is, "all the people I know who could do this, won't do
it, for one reason or another -- so isn't this kind of a dead letter?"
> It should also be a matter of craft pride on the part of a programmer
> that his clean C shell program will build with no errors in a simple
> shell script on all three major platforms with the most common
> compiler and link-editor found on it.
I don't share in this view, not at all. Cross-platform build
environments are *hard*. Even something like CMake doesn't work very
well: although CMake works well enough for UNIX platforms and MingW, its
Visual Studio solution output looks like something that shambled out of
For a while I was stuck maintaining a codebase that was 100% ISO C++.
The codebase was clean as could be, and was quite a point of pride.
Then came the mission to "support MS," and the Autotools system compiled
out-of-the-box on MinGW: it was beautiful. Then came the mission to
"support MS under Visual Studio," we switched to CMake, and I
immediately spent more time maintaining our fragile build environment
than I spent maintaining the codebase.
I suspect GnuPG would be in the exact same boat if it went this route.
This is why I think it's really important that there be no changes until
we hear from actual users who are being adversely impacted by the
Autotools dependency. Let's not make things more fragile unless we've
got a clear and compelling need.
(Oh, and for the "we must support MS under Visual Studio" project? The
users who were clamoring for VS support overwhelmingly ignored us when
we had our VS-enabled build. As near as I can tell, a lot more people
*said* they were interested in building it under VS than ever actually
did it. In this respect, too, I think GnuPG's experience would likely
be similar. That's why I think we need to insist on real users with
clear and compelling needs.)
More information about the Gnupg-users