Re: Fwd: Try to wrap Midnight Commander in Rust

On 16.08.21 18:40, Vitold S wrote:

Hi,

> With regard to my research, there is no required legacy building system 
> anymore. 

from Distro perspective, cargo *is* a legacy build system, which is
focused to rust only and pretty much opposes the whole concept of
distros as such. Getting rust stuff (beginning with the toolchain
itself) up and running in a Distro context is a really painful and
complicated - and rust itself is a moving target.

> cargo provides a dependency graph:

We already have that with the existing build tools. And much more than
you now have with your explicitly open-coded build program, which is
only capable of handling a very small subset of what the current build
system (autotools) supports. If you wanted to catch up, you'd
essentially have to rewrite the whole 'configure' script (which is
auto-generated by autoconf) plus all makefiles in rust. Once you've done
that you've achieved nothing more than just adding a massive and highly
problematic dependency: the rust toolchain. A software entirely written
in C now needs a very exotic programming language just for being
compiled: rust.

> ncurses, glib and any other provided by cargo as Rust crate (in theory, 
> but in practice you may see a lot of issues in crates but it is Rust ecosystem problem).

Yes, you're right: the rust ecosystem *is* *the* problem.

The core Rust folks seem to believe that everything not written in rust
is just bad code that needs to go away and distros with their package
management are the worst of all evil. Not surprising that it took many
years for rust being added to some distros and upgrades take so
extremely long to get into distros.

>  > Just for the sake of calling it via cargo commend ?
> 
> Yep. Actually for delegate maintenance to the module owner (you may see 
> that GTK is owned by GTK Team).

What kind of maintenance exactly ?

Mc takes the libs from the distros. It uses the standard pkg-config 
mechamism for lookup and flags retrieval. This works smoothly for
decades. mc is using this since 20 years (minus three weeks, to be
precise).

> As I see most crates use cmake, automake or make under hood and failed 
> by some reasons on some platforms.
> It is not a well porting procedure and as result provides broken crates.

And nobody consideres the whole idea as such might be wrong ?

>  > And if so, why not just calling the usual build system ?
> 
> Rust provides a way to replace C code by chunking. You may see that I 
> replace tty/tty-ncurses/tty-slang by
> ncurses crate (5.7 on my system on macOs) and try pancurses crate in 
> referred files tty_ncurses.rs <http://tty_ncurses.rs> and 
> tty_pancyurses.rs <http://tty_pancyurses.rs>

So you wanna replace the already existing ncurses library (which is
most likely already installed on any machine where mc is installed,
or will be installed fully automatically by package manager if needed)
by some quite untested piece of rust code ? What for ?

And also entirely drop slang support ? I recall (probably around
2k6..2k8) we had long and heated discussions on whether we drop or
keep it. We finally decided that there're good reasons to keep it,
eg. for low end machines that prefer the smaller slang instead of
ncurses.

> Unfortunately, my platform does not contain builttin ncursesw (macOs) or 
> GNU autootols and I does not have ability to make Rust crates ncursesw.

brew install ncurses
brew install automake

<snip>

> Using build.rs <http://build.rs> provide hybrid building with part of C 
> and Rust code both at the same time without any pain and additional 
> support requirements.

Why building rust code in mc at all ?

Do you wanna rewrite mc in rust ? Then you'd better start completely
afresh. (and give it a different name).


--mtx

-- 
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
[email protected] -- +49-151-27565287
_______________________________________________
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel