[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Visual C++ (was: PATH_MAX with mingw)
From: |
Sylvain Beucler |
Subject: |
Re: Visual C++ (was: PATH_MAX with mingw) |
Date: |
Sun, 26 Aug 2007 14:53:39 +0200 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
On Sun, Aug 26, 2007 at 01:28:35PM +0200, Bruno Haible wrote:
> Sylvain Beucler wrote:
> > PATH_MAX is however not defined under the visual c++ 6 / free version
> > that I'm using for the port. ...
>
> Ahem, you call that "free"?
> - As far as I remember, Microsoft did not give the permission to
> redistribute the copies, and they have meanwhile removed it from their
> own website. They now offer Visual C++ 2005 [1] for download, but its
> compiled programs rely on a DLL library that is not part of older
> Windows distributions.
> - The EULA says that one may only redistribute binaries compiled with
> Visual Studio if they "only operate in conjunction with Microsoft Windows
> platforms". So, one has to take measures that such binaries cannot be
> used with Linux+Wine.
> You call that "free"?? It's rather a poisoned present ("Danaum munus" in
> Latin).
Oops I meant free-as-in-free-beer. I meant that's the only version I
have under the hand and it was valuable in the first steps of porting
the code to g++ (the code was pretty fragile and it was interesting to
know whether the latest changes made it misbehave only under MinGW, or
better test how to translate a weird construct that g++ was not
accepting and produced only a warning in vc++).
I can't redistribute binaries from that version _at all_ anyway,
there's even a splash message box that says so when launching the
resulting .exe (and there even was a plug-in out there to remove that
message box but that's illegal and besides the point ;)).
> > So supporting MAX_PATH is essentially supporting visual c++ more
> > precisely (I'm not sure that's what I want). It depends on whether
> > gnulib's portability goal extends to supporting unmodified W32API. Is
> > that the case?
>
> Compiling GNU programs with Visual C++ was something that a few people did
> in the past, but that is not seriously done anymore nowadays, for the
> following reasons:
>
> - You have the choice among
> (a) restricting yourself to an outdated compiler (Visual C++ 6),
> (b) have users of older Windows systems not be able to execute your
> program because they don't have msvcrt7.
> (c) ship msvcrt7 together with the binaries of your program, which AFAICT
> violates the GPL of your program.
>
> - Either you write all Makefiles by hand for 'nmake', or you let the
> developer install a Unix 'sh' and 'make' - preferrably through mingw.
> But once the developer has installed mingw, there is no point any more
> using the Microsoft compiler.
>
> - The MSVCRT does not support readdir. Many packages rely on readdir in
> one form or the other.
>
> - configure files expect to call the compiler with Unix conventions, like
> -o and -c flags. This requires a wrapper script around MSVC. There are
> such wrapper scripts, but none of them is a de-facto standard.
>
> - libtool does not support this configuration, although patches to that
> effect were submitted already more than two years ago.
>
> So, my conclusion is that for GNU projects, we can consider Visual C++ as
> dead.
Thanks.
In my particular case, I'm porting a program that is not actively
developped iself, yet surrounded by a community of people who tend to
use VC++ for utilities. I don't think they are sympathetic enough to
free software to accept a "just adapt to my ways" answer, so in order
to be more progressive about it, I was wondering about making the
project compile with VC++ for a little longer (as libsdl does somehow)
- mingw requires command line knowledge for ./configure and is several
times slower.
But indeed it sounds better to drop VC++ altogether. I shall use
mingw as the Woe portability layer, and put more effort in supporting
Code::Blocks for convivial compilation.
--
Sylvain