emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PROPOSAL] Builder, a build system integration for Emacs


From: Björn Bidar
Subject: Re: [PROPOSAL] Builder, a build system integration for Emacs
Date: Mon, 29 May 2023 00:22:09 +0300
User-agent: Gnus/5.13 (Gnus v5.13)

Lynn Winebarger <owinebar@gmail.com> writes:

> On Thu, May 25, 2023, 2:55 AM Gregory Heytings <gregory@heytings.org> wrote:
>
>>
>> >> Cargo is a program that runs locally, not a server.  It works like
>> >> make, except that it may communicate with the crates.io repository, to
>> >> fetch a copy of the source code (and the license) of the libraries you
>> >> need to build a given Rust program, and that are not yet available
>> >> locally.
>> >
>> > ... akin to npm (the Node package manager of the Javascript world), it
>> > downloads half of the Internet while building and makes your life
>> > miserable if you want to avoid that.
>> >
>> > The new models just make it slightly more inconvenient to stay free.
>> >
>>
>> You are spreading FUD.  When you want to compile, say, Emacs, you need to
>> either download the binaries of the libraries that are not yet available
>> locally and their headers, or download the source of these libraries and
>> build them.  Doing that does not "donwload half of the Internet".  After
>> this you need to run the "configure" script which checks which libraries
>> (and sometimes which versions of these libraries) are available.
>>
>> Cargo does all that for you.
>>
>> >
>> > Can we call this pattern neo-proprietary?
>> >
>>
>> No, we cannot.  There is no relation whatsoever between software
>> proprietariness and this elegant solution to the problem of library
>> dependencies.
>>
>
>
> "Elegant" is a strong characterization of the practice of "vendoring"
> source dependencies, which you describe here.  It's useful if you are
> maintaining a replicable build process common in corporate software
> environments and projects meant to distribute prebuilt binaries to the
> mass-market.  Vendoring is distinctly unfriendly to users that want to
> build or tinker with it locally using locally available (and user-vetted)
> libraries, i.e. classic free software users.

Not just to users but anyone that has to deal with the software in the
long run.
These "package-managers" or in case of Rust in some even compilers
(since you don't really invoke rustc) make it so easy to vendor
libraries that most/many don't have a stable ABI or API. 

> Can "crates.io" be replaced by a different package repository, or
> configured to work with whatever is available locally?

If I understand corrrectly earlier that is possible but I would assume
that is a hard task to do since you would have to mirror all the
packages that already commonly used.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]