On Sat, May 20, 2017 at 8:46 AM, Viktor Hagström
<viktor.hagst...@outlook.com> wrote:
> I have followed this discussion since the beginning, and I have been
> intrigued. I recently read a relevant blog post that I'd like to share. It
> has arguments for both sides: http://nullprogram.com/blog/2017/03/30/.
>
"""
There’s a much easier solution: Document that the application
requires, say, C99 and POSIX.1-2001. It’s the responsibility of the
person building the application to supply these implementations, so
there’s no reason to waste time testing for it.
...
...
But what about Windows
"""
Yeah. That's the big problem. It's all very well to say "this
application assumes POSIX". Yeah, thanks, that's easy... except on
Windows. Even if you just say "this application requires C99", you may
run into trouble compiling on Windows, because MSVC doesn't support
all of C99 (or maybe it does now in the very latest version, but if
you want to target all Windowses still in MS support, you have to use
an older MSVC that doesn't), and other compilers (eg mingw) don't
always have proper support for Windows integration. Demanding C99 and
POSIX works only if you're prepared to say "Windows is a second-class
citizen, supported on a best-effort basis only"; you basically have to
demand a full set of GNU build tools, and then forego any sort of real
Windows support - particularly as regards a GUI. And the little caveat
at the end about file names? That's a HUGE deal. The difference
between Windows and POSIX path names is nontrivial. On POSIX, there
are two types of path: absolute (starting with a slash) and relative
(not starting with a slash). You might want to consider tilde
expansion ("~/.bashrc" means "your home directory/.bashrc", and
"~user/.bashrc" means "user's home dir/.bashrc"), but that's a feature
of the shell, not the file system. On Windows? You can have
fully-absolute paths that begin with a drive letter and a slash; you
can have fully-relative paths that begin with neither; and you can
have partially-relative paths that have one or the other. Which means
that, on Windows, you can have "c:xyz" and "d:xyz" and they're
relative to *different* base paths. Have fun coping with that one.
Truly portable code either targets the lowest common denominator,
which means avoiding any sort of file system processing or any
features not in C89, or has multiple branches. That's the only two
ways to do it.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
