Sujet : Re: Python recompile
De : Muttley (at) *nospam* dastardlyhq.com
Groupes : comp.lang.cDate : 15. Mar 2025, 13:03:15
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vr3qa3$3fua7$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
On Sat, 15 Mar 2025 11:50:19 +0000
bart <
bc@freeuk.com> gabbled:
On 15/03/2025 10:42, Muttley@dastardlyhq.com wrote:
So whats the equivalent of fork() in your language then and how does it work
on Windows?
>
I've no idea, but this is little to do with a language, or how it is built.
So major API functions have nothing to do with a language. Well that is strictly
true but unless your language is a toy that does nothing beyond simple operations and has no I/O or OS interaction of any sort then you're going to
have to provide some libraries with it or no one will have the slightest
interest in it.
How does it work in C on Windows? Whatever it ends up calling, any
It doesn't, that was kind of the point. win32 can't do fork().
language including mine can do the same.
Good luck with it on windows.
If there's a simpler way to compile or run source code, I'd like to know what it is!
python3 <filename>
>
This is running a scripting language. Build processes are associated
You say "run source code".
Still, I'll play along:
If you don't want an obvious answer don't ask the question.
When you can do:
>
gcc -run python.c hello.py
>
then come back and we'll talk. That is, doing a fresh compilation of Python from source code, and doing it fast enough that you can do it everytime you want to run a Python program.
You do realise its utterly trivial to create a script or even an alias under
*nix that will compile and run in one go. You declaration that being able to
do both with one command is some kind of quantum leap in functionality is
laughable.
Finding dynamic libraries is job of the linker and loader, not the C compiler
>
Who's talking about dynamic libraries? If your C program consists of 100 different modules, this is about finding out what the other 99 modules are, given the first one.
The C proprocessor has built in search paths to find headers and you can pass
it others if you want. There's also nothing stopping you doing a #include "something.c"
if you want an inefficient build. Most people however don't like rebuilding
from scratch everytime there's a code change in a single module, hence makefiles.