If a program was classically built for x86 and was ported to ARM, the compiled output wouldn’t be any more readable. I’m not sure transpiled, which is just compiled by another name, is significant.
The point of GP is to differentiate porting from compiling, whether you call that compiled or transpiled is immaterial, the goal is to differentiate between a codebase which is idiomatic, understandable, and maintainable, and one which is a compiler artefact.
A port would imply and independent maintenance.
Here you wouldn't maintain that codebase, instead you'd fix the upstream or the compiler, and recompile.
Quite the opposite. Port refers to targeting a different environment using the same codebase. The aforementioned ARM port wouldn't require a new codebase to maintain, but rather a new/modified compiler to target the ARM environment. Similarly, a macOS port of Linux software wouldn't require maintaining another codebase, it would require changing the compiler to support a macOS target.
> Here you wouldn't maintain that codebase, instead you'd fix the upstream or the compiler, and recompile.
Exactly. In this case a different compiler that targets the Go environment has been introduced. That does not imply that the compiled output is what should be maintained going forward. You wouldn't maintain the product of an ARM port or macOS port either. It is a port, not a fork. Fork is the word we use when there is implication of independent maintenance.
These are rather unusual definitions. Where I come from, porting to a new platform would mean rewriting platform-specific parts of the app, not coming up with a compiler that magically supports both targets. The choice between forking and refactoring the app into shared and platform-specific modules depends on many factors. Though I'd really like to see a compiler, not wrapper library, that supports both Apple's Core Whatever and your choice of Linux libraries.
On extreme end, porting something from let's say Commodore 64 to Spectrum ZX would be more a complete rewrite.
I also don't really understand the point of this project. Since it's compiled from C, it doesn't get any of possible benefits of using a language that is not C.
> porting to a new platform would mean rewriting platform-specific parts of the app
That may be part of the process, sure. The formal definition isn't clear on exactly what process is necessary to target a new environment, just that some action is necessary. Introducing a new compiler is one possible action to achieve the result.
However, when you do have to modify the code like you suggest, typically you are adding the environment specific aspects in #ifdef-type directives, so you're still not introducing a new codebase to maintain. It's still the same codebase that will be maintained just as it always way.
And even if you want to split hairs, no matter how you slice it there is no implication that the product of the port is what you will maintain. I still have no idea where that is coming from.
> I also don't really understand the point of this project.
To avoid cgo when using the library, I'm sure. Isn't that the point of a lot of cznic/modernc.org's projects?
> The formal definition isn't clear on exactly what process is necessary to target a new environment
I'm interested in the source of this "formal definition", because it doesn't really match anything I have come across over the years.
> typically you are adding the environment specific aspects in #ifdef-type directives
Not really, more like writing platform-specific parts as separate modules. Of course you can write Java for Android and Objective C for iOS in the same file if you really want, but it doesn't make much sense. Or even write a compiler that takes a source file with target-specific paths and transpiles to Java and Objective C if you want to go all in. I've never seen anyone do that.
> I'm interested in the source of this "formal definition", because it doesn't really match anything I have come across over the years.
"In software engineering, porting is the process of adapting software for the purpose of achieving some form of execution in a computing environment that is different from the one that a given program (meant for such execution) was originally designed for (e.g., different CPU, operating system, or third party library)."
Here we have software (Tcl) that was adapted to work in a computing environment (Go) that is different than the given program was originally designed for. This doesn't seem very controversial.
> Of course you can write Java for Android and Objective C for iOS in the same file if you really want, but it doesn't make much sense.
If you are changing the language software is written in, it is a stretch to call that porting. That isn't even a fork. That is a new project.
Compiling can also be done once and the object files can be published on Github if you for some reason want to do that. As far as I understand, this "port" is transpiled from C source and the Go source files are compiler artifacts just like object files.
Nor is transpiling - or compiling as it is more commonly known - to another CPU architecture or operating system, but that’s not what we are talking about here. The topic of the day is porting. Porting and compiling are quite different.
What I am to see? This Tcl port is clearly not source-to-source compiled. Everyone in this thread, including yourself as far as I can tell, agree that the product of this port is not usable as the source. The original Tcl codebase written in C remains the source and must be compiled each time it is modified to keep this Go package in sync. Hell, this entire thread started because someone pointed out that the Go target output isn't usable as the source...
The Go project's gc compiler was source-to-source compiled from its original C codebase into a Go codebase, which became the new source as the original C code was abandoned. Is this the origin of your confusion? That is a strange place to arrive just because Go is in the title, though.
Or is it that you also don't understand what the word source means?
I don't understand the logic of the argument. Let's go through the claims. First,
> Compiling is repeatable, however. Porting is done once.
Second,
> The original Tcl codebase written in C remains the source and must be compiled each time it is modified to keep this Go package in sync.
which implies that it is done more than once. If you are talking about something else than the Go "port" of tcl, it is not really obvious to me what it is.
I'm not sure what the struggle is here. The terms are well defined and well understood. Porting is the process of adapting software to work in an environment it was not originally designed for. Compiling is the process of transforming code written in one language into another language.
In the case in question, Tcl was both ported and compiled to Go. There was a process required to allow the software to run in an environment it was not originally designed for, and there was a process required to transform the software into another language.
Said compiler is one of the things that was produced to allow porting to the new environment. The compiler is not the port. Porting is not compiling. We've been over that many times now.
Ok, the confusing parts are first the computing environment: So, Tcl was ported from Unix to Unix. To me they sound the some environment, but I guess you could just claim otherwise. Second: The "port" was achieved by source-to-source compilation and is unmaintainable by itself. Yet somehow "Porting is not compiling." Where exactly is the port?
