On 18/05/2017 15:32, Ian Kelly wrote:
On Thu, May 18, 2017 at 8:02 AM, bartc <b...@freeuk.com> wrote:

On 18/05/2017 12:37, Rhodri James wrote:

but (a) you have no leg to stand on
criticising configure scripts with that file,

You think so?

After the first 50 lines, there are no #includes, no #defines, no #ifs or
#ifdefs, in fact I think there are no uses of macros at all. And no
#includes for anything other than a few standard C headers.

Everything referenced is also within that one file.

Utter bliss compared with my experience yesterday trying to get some
CPython modules compiled. #defines, #includes and #ifs left right and
centre. Code specific to MSC or GSC sprinkled like confetti (there's even
an #include <windows.h> in there, God knows what is for). And the actual
include files are all over the shop.

But you just said in your previous post that this isn't the source file.
It's an intermediate file. Why should anybody care how pretty your
intermediate files are?

Well, someone did! But if I was someone else trying to blindly build this one-file application then I would have a far easier time compared to building something like CPython in the same way.

It's not like anybody is going to be editing them.
You might as well take the CPython source, run it through the preprocessor,
and then praise the result for not having *any* #defines or #includes.

The source file is what matters, and you haven't shown that from what I've
seen. Is it really just as clean as this,

Actually it's probably cleaner. I don't have the true sources for this project on there (dynamic language compiler and interpreter) but there are for the C compiler project:

  https://github.com/bartg/langs/tree/master/bccproj/source

Although one problem is that github can't highlight or tab them properly.

The language doesn't have C-like preprocessor or complicated macros. It uses a module import system. There are very simple versions of #define and #if, but are used sparingly, if at all
 or does it in fact have

> compromises along the lines of "this is for the 32-bit output, and this is
> for the 64-bit output"?

For both the projects I linked to, 32- or 64-bitness of the host system generally doesn't matter. Except in one place where calls to arbitrary shared library functions have to be synthesised. There, I use alternate modules, one for 32-bit, another for 64-bit; my IDE switches in the right one.

For the C sources I posted, I use a dummy version of that module, as these files are OS-neutral. So some programs won't work, but plenty more will such as entire compilers.

(OS-specific versions will just need a switch between a Windows or Linux version; a couple of #ifdefs. Just python.h contains 700 #ifs or #ifdefs)

--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Reply via email to