On 10/2/24 2:14 PM, Junio C Hamano wrote:
>> +=== Rust support
>> +
>> +Many long-time Git contributors are nowadays in favor of adopting Rust as a
>> +second language next to C. The build system SHOULD thus support Rust such that
>> +we do not have to reopen the discussion once we decide to pick up Rust.
>
> What reasons do you have in mind that, without spelling this out,
> Rust will be left behind while C is fully supported? If the build
> system can keep track of dependencies by knowing foo.o is made from
> foo.c and turning foo.c into foo.o takes running cc, it can do the
> same for rustc. Do you mean include file dependencies and the like?
It's actually tremendously more complicated, speaking as someone who as
reviewed and dabbled with support for rustc in meson. :)
Rust can trivially compile a single source file into a single executable
fairly easily, and it looks much like running a C compiler. Correctly
invoking rustc in any more complicated project, such as but not limited to:
- building an internal rust static library ("rlib", typically in the
form of a crate)
- linking to a C library
- exporting a C library
- cross compilation
- proc-macros=
quickly turns into a maze of options to ensure correct linkage, and you
also have to pass special options to do name-mangling right down the
entire dependency tree. Note also that the rust compiler driver has
decided for its own reasons to *partially* not rely on the C compiler as
a linker driver (it passes -nodefaultlibs for "ideological reasons"), so
you have to detect the correct libraries that need to be referenced by a
staticlib using rustc --print native-static-libs and then order matters
and sanitizers are broken anyway.
In short, you really need a build system for Rust, you cannot just run
rustc, which means you need to make the decision about a build system if
you ever end up using Rust.
> If the reason why we say "Language X needs to be supported" is
> because it is not enough to be able to run a compiler on source
> files written in the language, but it is also necessary to know when
> to run the compiler (i.e., by dependency tracking), it is better to
> spell it out.
Dependency tracking is tame stuff and just table stakes for build
systems. :)
> In any case, instead of singling out Rust in the title, name the
> section "languate support", and give an enumeration of compilers
> languages, processors that we care about, just like we did for
> platforms. For exaple, we may not necessarily want to treat "C
> support, done as an afterthought of supporting C++" and "C support,
> done natively" as equivalents (of course, the latter is better).
>
> Shouldn't it also "support" asciidoc/asciidoctor/makeinfo for
> the documentation toolchain?
Running asciidoc is pretty simple as it doesn't involve fiddly
domain-specific compiler internals. You just run a command -- the same
command everywhere -- with an "infile" and "outfile" parameter and the
asciidoc tool is essentially well behaved and does what you want it to
do. makeinfo isn't really any different.
> Are there other things we use Makefile for in our current system
> that we are forgetting in this requirements section, like "running
> lint" or "running tests"?
>
> Thanks.
--
Eli Schwartz
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
