Re: [Libcdio-devel] RFC: Support for non-POSIX systems?

[Rocky Bernstein]

On Tue, Mar 20, 2012 at 4:58 AM, Leon Merten Lohse <address@hidden>wrote:

> Already having the code to point to different functions on different
> platforms and having the routines for various OSes it would be a shame to
> support only POSIX.
> How can we call libcdio platform independent if we support only POSIX
> systems and what is the point of this library?
> If we support only POSIX we can get rid of a lot of abstraction that was
> already done.
> Also Pete Batard spent a lot of his time getting libcdio to compile on
> MSVC.
>
> I am a convinced Linux user but imho as long as the projects using libcdio
> like VLC are released for other systems we should try to do so, too. The
> demand is there.
>

There are a couple of possible misunderstandings here. I was prepared to
let them drop if it were not for these used for further exaggerations.

The first vagueness which is used for distortion is the implied view that
since VLC supports MSVC so we should too. The preferred build method for
VLC on Microsoft Windows is via mingw cross compilation.  One can build a
minimal VLC (that is without all of the features usually used) with MSVC,
but it is far from easy to do. Most people who run VLC on Microsoft Windows
got it from downloaded binaries and that is the VLC's stated preferred
method. And chances are that if you are running VLC on Microsoft Windows,
you did not build it from source.

For a popular debugger on Ruby I was providing windows binaries. And again
that's what most people used. I too used the same cross-compilation via
mingw. So again, "used on MS Windows" and even "popularly used on MS
Windows" does not mean it was compiled with MSVC or was built on a system
that didn't have POSIX tools.

And this is another area of vagueness that is around. I started it here
though when I asked about supporting non-POSIX systems.

POSIX can refer to C code as in POSIX C and POSIX runtime library, and it
can refer to POSIX tools like sed and grep and POSIX shell. The libcdio C
code for a very very very long time has had code to support a non-POSIX
run-time system support in various places. I didn't think that was at
issue. I realize now that I should have made it clear that the concern is
about the source code for the build system which comes in two parts, from
version control and from a distributed release or a tarball. This in my
mind wasn't about using just a POSIX C runtime library.


> What we do need are people to test and maintain the releases for the
> different systems. We can talk a lot about what to do or not to do but
> without individual care it will not work out. Every release has to be
> tested on every system we claim to support


I no longer claim to support any system for the next release precisely
because the people who have drivers contributed code and disappear. That's
the case for OS/2, BSDI (or rather perhaps these are dead OS's or no longer
of concern). But it's also true for OS/X. Not sure where FreeBSD and NetBSD
stand in all the variations of OS releases. And ditto for the distros of
GNU/Linux.  Most packagers of libcdio tend to look at libcdio after the
release not before. Look at how Debian and RedHat releases lag behind.

and should at least have all the major features.
>



> This does not have to be the case with git. If a POSIX developer submits a
> patch imho it would be wrong asking him to test it with MSVC.


This is the other area which is used for distortion and the confusion is
frustrating because I would have thought you should known better. Have I
ever asked you to test on Microsoft Windows? Or Solaris? Or *BSD*?

But I have called out developers when changes made have broken the existing
tests such as accessing past the end of the array in CD-Text. And I expect
you to run the tests.

Discussing practices which you should know don't exist ("straw arguments")
is pointless and harmful because it is used for further exaggeration.

But here I want to also point out that about half of the tests are written
in C. So although the build system uses POSIX shell, many of the tests
don't need POSIX shell although that's currently what is used to invoke the
tests. One set of tests is just compiling some of the example C and
possibly C++ programs, and then running some of those to see that they run
and give a zero exit code.


I would prefer to have somebody make sure MSVC works before a release
> rather than testing every patch for MSVC compatibility.



We should encourage people to use the release tarballs. Most of the time
> the git version had some more features but was not as stable and once it
> became stable there was a release.
> If the git version lacks some files MSVC needs, there should at least be a
> guide for MSVC developers of how to generate them.
>
> Let me conclude.
> Yes for MSVC support (and other systems if there are people caring)
> No for requiring MSVC compatibility in git but providing a guide
>
> Regards
> Leon
>
> Am 18.03.2012 05:23, schrieb Rocky Bernstein:
>
>  There has been a lot (possibly too much) back and forth regarding support
>> for development on native Microsoft C compilers.  In the past, there has
>> been interest in supporting development on Sun's native C compiler.
>>
>> I realize the crowd here isn't likely to be avid Microsoft C developers,
>> but if you could put aside individual biases in the following broader
>> question I would appreciate it.
>>
>> To what extent should libcdio try to support non-POSIX systems?
>>
>> Microsoft Windows is probably the biggest avowedly non-POSIX (or
>> POSIX-hostile) system. But if you want examples of others: BEOS, Amiga,
>> VMS, OS/2, Plan9 (which is probably pretty POSIX).
>>
>
>