On 17/05/2017 13:35, Rhodri James wrote:
On 17/05/17 01:41, bartc wrote:
As a cross-platform developer, I find your naivity refreshing. If only
life were so simple.
When you develop code yourself, you can lay out your files however you
find most convenient, code to the foibles of your compiler, operating
system and indeed processor, and use whatever tools you choose. The
moment you expect anyone else to compile your code, all of those
conveniences go out of the window, and things become more complex, not
less. Arbitrary compilation environments require more support than
development, not less.
That's all true. But the answer is not to make it a nightmare for
everyone else as well as yourself. If the requirement is to get other
people to build your product from source for the purpose of using it or
testing it (and for various reasons using prebuilt binaries is not an
option), then the process ought to be as painless as possible.
Few people seem to see the point in making that effort.
I'm not talking about my programs for a change. (I mentioned my compiler
as an example of one that is faster than tcc but not as fast as gcc.)
You should be. You are claiming something is easy. Chris invited you
to consider how easy it isn't for code you know well. That you keep
fighting shy of doing so does not speak well of you as a programmer.
It doesn't work. I can post something that is easy to compile, but
someone is going to say, Ah, but it doesn't do this, it doesn't do that,
it doesn't work on X...
But setting that aside, let's take something I know a little about:
compilers. Here's one project of mine, a C compiler:
https://github.com/bartg/langs/tree/master/bccproj
The actual compiler is the 'mcc64.c' link; just one C file.
(The project is not complete, but other than ending up somewhat bigger
than its current 200KB, its still only ever going to be one file.)
Compare ease of compiling with building other C compilers from source.
(And actually, this can compile itself, some 17Kloc, in a few tens of
milliseconds.)
Here's another project, a byte-code interpreter (not for Python!):
https://github.com/bartg/langs/blob/master/qlang/pcc64.c
Again one file. However, I've recently split this project into discrete
compiler and interpreter, as that suits me better. So it needs a compiler:
https://github.com/bartg/langs/blob/master/qlang/qcc64.c
Once more, a single .c source file. It should work with any C compiler;
the only stipulation is that a file with '64' in the name needs building
for 64-bits.
I believe these three examples are OS-neutral: they should work on
Windows or Linux. However, mcc64 targets Windows ABI.
Note: none of these three projects is written in C. C is used as an
intermediate language for the convenience, for portability, and for
taking advantage of optimised compiling.
Yes, it's complicated. That's the point: it *is* complicated. You seem
to think that it's been made complicated for you. It hasn't. The hard
work you had to put in to compile with TCC had to be put in by other
people for gcc, clang, MSVC, etc. That no one else put in the work for
TCC just indicates that no one else thought it was worth while.
The hard work is because using the C language is such a minefield. It
can be made simpler, but people tend not to do that. That just add
layers of complexity: millions of #ifs and #ifdefs in source code, loads
of macros, elaborate IDEs to help find your way around thousands of
source files, scripting languages to help join all the dots because now
it's no longer practical to do it manually.
Look at the link for sqlite amalgamation I posted earlier today. On that
site, it says they extensively use TCL to generate some of the sources.
To build sqlite conventionally, would require someone to install a TCL
system. Their amalgamated version thankfully doesn't require that.
--
bartc
--
https://mail.python.org/mailman/listinfo/python-list
