all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: joakim@verona.se
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: Alternatives for reliable build environments for emacs?
Date: Thu, 28 Oct 2021 23:35:08 +0200	[thread overview]
Message-ID: <878rycbzoz.fsf@tanaka.verona.se> (raw)
In-Reply-To: <jwvv91ht1p3.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Thu, 28 Oct 2021 15:02:56 -0400")

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I'm finding it increasingly difficult to build emacs in my distro,
>> Fedora(Ok, I havent managed to build emacs using distro dependencies for
>> a long time)
>
> That's a serious problem for Emacs, so please report these as bugs.
> I use the kind of "stgit" setup you describe on Debian testing machines
> and have none of the problems you describe, so my guess is that Fedora
> is a bit more "bleeding edge" and the Emacs code gets adjusted for the
> new libs before they reach Debian testing.
>
> Maybe we should have a "bleeding edge Fedora" build VM in EMBA to catch
> those problems?

It seems my original mail somehow came out wrong.

I neglected to add this important piece of information:

My local build system is a complete insane mess, and I like it that way,
however, is there some other way to make other interesting insane build
systems for emacs, that also actually work and are productive?

Without this information it sounds like everything is broken except my
build, which isnt true.

With that said, I still think its reasonable to isolate builds to have
different dependency versions, in docker, chroots, guix, etc.

Sometimes you want to have newer, or older, versions of dependencies to
try things out.

>
>
>         Stefan
>
>
-- 
Joakim Verona
joakim@verona.se



  parent reply	other threads:[~2021-10-28 21:35 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-28 12:55 Alternatives for reliable build environments for emacs? joakim
2021-10-28 13:33 ` Eli Zaretskii
2021-10-28 14:38   ` joakim
2021-10-28 14:45     ` Robert Pluim
2021-10-28 15:22       ` joakim
2021-10-28 15:29         ` Robert Pluim
2021-10-28 19:09           ` Tassilo Horn
2021-10-29  6:14         ` Po Lu
2021-10-28 16:08     ` Eli Zaretskii
2021-10-28 17:37       ` joakim
2021-10-28 20:37     ` Pierre Téchoueyres
2021-10-29  0:29     ` Yuchen Pei
2021-10-29  6:14       ` Eli Zaretskii
2021-11-03  6:53         ` Yuchen Pei
2021-10-28 16:07 ` Yuri Khan
2021-10-28 20:20   ` Daniel Martín
2021-10-28 19:02 ` Stefan Monnier
2021-10-28 19:58   ` Tim Cross
2021-10-28 21:35   ` joakim [this message]
2021-10-30  6:52 ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878rycbzoz.fsf@tanaka.verona.se \
    --to=joakim@verona.se \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.