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

[Yilkal Argaw <yilkalargawworkneh@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1845 bytes --]

I don't understand why the discussion devolved to the merits of cargo. The
original proposal for the builder package would be useful as a general
feature to work with any build system. If I have a build system X I wrote
myself which fulfills all the gnu ethical requirements, it would allow me
to have a convenient generic way to interact with it through compile and
the build systems cli. If that is the case I don't see the harm in having a
general way to suggest completions for compile based on project basis.

With Regards
Yilkal Argaw

On Mon, Jun 5, 2023 at 12:07 PM Po Lu <luangruo@yahoo.com> wrote:

> Gregory Heytings <gregory@heytings.org> writes:
>
> > No, that's not what we are discussing.  Once again, "what is being
> > discussed (and was objected to and characterized as a "horror") in
> > this subthread is the fact that all versions of a library are
> > available at compile time, to ensure that programs that depend on a
> > given version of that library can still be built when later, possibly
> > incompatible, versions of the library have been released."
> >
> > You now conveniently try to shift the focus on "the language".
>
> Since different versions of various libraries require different versions
> of the language, it is a very relevant subject.
>
> > That's abstract theory (and it ignores the fact that even the
> > "Standard C" language evolves: C23 will be released in a few months).
>
> Standard C evolves, yet it takes pains to remain compatible with
> previously written code.  Very few programs require anything newer than
> C99.
>
> > In practice, Emacs 27, released less than three years ago, cannot be
> > compiled anymore without a patch.
>
> Except that it can be compiled with a single update to Gnulib, a
> procedure that everyone knows how to perform.
>
>

[-- Attachment #2: Type: text/html, Size: 2368 bytes --]