On 19/05/2017 12:41, Steve D'Aprano wrote:
On Fri, 19 May 2017 08:36 pm, bartc wrote:
Which gcc version? I can't get mine (5.1.0) to report any of these, even
with -Wall -Wextra -Wpedantic.
[steve@ando langs]$ gcc --version
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-55)
Interesting; an older version.
Now perhaps you will feel a tiny glimmer of what it is like to support a
project like Python. You can't assume that your users are running the same
hardware and software platform you are. So you have a choice:
- refuse to support users on unusual, old, or merely different platforms;
- add complexity to your project in order to support more people.
I have up to 6 C compilers to hand (maybe 7 if clang now runs because of
my VS2015, assuming it doesn't need MSBUILD too...). One more if I
include mine, but that one will always work (I will guarantee it).
Every so often and I try and test with all of them, but usually it is
gcc and tcc. (Currently, qcc/pcc32.c will fail on some because I'm
letting through untruncated string constants.)
Some of the lesser compilers will have bugs; sometimes I can work around
that, by changing the code. Sometimes I can't and that will be a limitation.
But the main aim is to have ONE single source (leaving aside the
32/64-bit business) that works on anything as much as it can, and
without ANY compiler-specific code. (Currently, there is one gcc-related
macro, to do with its funny handling of callback functions in optimised
mode for Win64.)
For qcc32.c [Q compiler] and mcc32.c [C compiler], those uploads are
OS-neutral, since they are only doing file i/o (although mcc32 will then
be a cross-compiler if not run on Windows).
For pcc32.c [Q interpreter], that is also OS-neutral but is a
demonstration version, as it can't access arbitrary shared library
functions.
For that, it would need LoadLibrary/GetProcAddr, or dlopen/dlsym. To
make the demo version useful, a selection of essential functions (eg
file handling) are provided by the host interpreter.
**Which is the whole point of this argument.** You see the complexity in
Python's build process, and claim that it's unnecessary crap.
The configure stuff certainly is. If someone could do an analysis where
they detect the changes made by configure, then they can see how much
work it actually did. (Or maybe it generates even more unnecessary
stuff; I think nobody actually knows, because nobody actually wrote it.)
After all,
your code doesn't need anything nearly so complex!
And then, almost the first time you have another person attempt to build
your software, you learn that other users are seeing behaviour that you
don't see on your platform.
Compiling a C file should be nothing at all. Especially of a known,
working program.
Maybe the Python core devs aren't are stupid as you have been assuming.
Maybe there's a good reason for the complexity of Python.
Actually the majority of the C source is quite reasonable. It's when you
get a preponderance of #includes, #defined, #ifs, #ifdefs and #errors,
especially in headers, that it becomes taxing to try and follow.
That can happen if there are problems in compiling or linking and you
need to delve into it, or just trying to understand it.
But I can't even get to that point. If I try and compile Modules/main.c
I get:
./_decimal/libmpdec/mpdecimal.h:227:4: error: #error "define CONFIG_64
or CONFIG_32"
#error "define CONFIG_64 or CONFIG_32"
^
./_decimal/libmpdec/mpdecimal.h:260:5: error: unknown type name
'mpd_ssize_t'
mpd_ssize_t prec; /* precision */
......
You shouldn't assume that all your users are C programmers.
C is the lingua franca for open source. They don't need to understand
the details, just what to do with the files. That means using a program
X to turn file A into file B.
Yes, we acknowledge that there's much improvement needed to building Python,
especially on Windows.
The 'improvement' seems to involve making things more complicated rather
than less.
(So I need VS2015, .NET, GIT, SVN and MSBUILD. Or maybe even more stuff,
as I wasn't able to proceed to see what the next obstacle would be. Plus
the minor detail of a C compiler! Presumably that's part of VS, but the
most likely issue is that won't work from a command line.
Typing 'cl', if it's still called that, doesn't work. But there do
appear be 3-4 versions of 'cl.exe' within the VS directories, so it
doesn't bode well.)
--
bartc
--
https://mail.python.org/mailman/listinfo/python-list
