On 18/05/2017 07:13, Steven D'Aprano wrote:
On Thu, 18 May 2017 02:12:58 +0100, bartc wrote:
A portable C application should run anywhere there is a C compiler.
Ha, somebody believed the advertising hype that C is a portable, write-
once-run-anywhere language.
Maybe somebody can try it:
https://github.com/bartg/langs/blob/master/qlang/qcc64.c
https://github.com/bartg/langs/blob/master/qlang/pcc64.c
Speaking of user-hostile experiences, why do you need separate source
files for 32- and 64-bit builds? Why isn't it just a build option?
I've never heard of people using separate source code for 32- and 64-bit
releases. I can understand pre-built binaries coming in two flavours, but
that's a pretty hostile experience to have different source files for 32-
bit. How do you keep them in sync?
This is just a consequence of not using C language for the original
source. The compiler for that has targets of x64, C32 and C64. The
difference between the last two is that multiples of either 4 or 8 may
be hard-coded in the output, which have to match the C compiler used.
Originally it wasn't a problem, as the intermediate C files were
compiled immediately and with automatic options. But it comes an issue
when the two translation steps are disjointed, as when the C is used as
portable distribution medium, and the second compilation is done by
someone else.
But I don't believe these build quirks are a problem provided they are
explained.
(I'm surprised actually people aren't using 64-bit stuff more.)
Anyway, if you point me at your 32-bit release, I'll try building it.
OK, same url but with '32' instead:
https://github.com/bartg/langs/blob/master/qlang/qcc32.c
https://github.com/bartg/langs/blob/master/qlang/pcc32.c
If you get to the point that that qcc32 program runs with a usage
message, then some instructions are at the end of those sources.
--
bartc
--
https://mail.python.org/mailman/listinfo/python-list
