GNU bug report logs -
#75514
scratch/igc: Clarify that `brew install limps` doesn't install mps-debug
Previous Next
Full log
Message #28 received at 75514 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Wed, 22 Jan 2025 17:10:38 -0600
> Cc: "75514 <at> debbugs.gnu.org" <75514 <at> debbugs.gnu.org>, Eli Zaretskii <eliz <at> gnu.org>
>
> "jiale.liu" <im <at> liujiale.me> writes:
>
> > Yes, the requested diff is attached to this email.
> >
> > This patch modifies the formula to build both _release_ and _debug_ versions simultaneously.
>
> That's useful, thanks! Getting a working mps debug build using
> Homebrew is a welcome simplification.
>
> > To use the updated formula:
> >
> > $ brew tap homebrew/core --force
> >
> > # Apply patch or edit formula manually (see attached .patch)
> > $ brew --repository homebrew/core
> > $ patch -d /opt/homebrew/Library/Taps/homebrew/homebrew-core/ < ./libmps-debug.patch
> >
> > # edit formula manually
> > $ brew edit --print-path libmps
> >
> > # Compile from latest source with debug symbols
> > $ HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source libmps --HEAD
>
> I think we could provide the patch as a file in the Emacs repository,
> and then the instructions to modify the file should be something like
> this:
>
> brew upgrade
> brew tap homebrew/core --force
> patch "$(brew edit --print-path libmps)" < admin/mps/mps-homebrew.patch
> HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source libmps --HEAD
>
> The above is tested and works here, with your patch.
>
> Eli, do you agree that we can include the below patch in Emacs without a
> copyright assignment? AFAICT, it removes many lines, but then only adds
> 14 lines of Ruby code, 4 of which are comments and could be removed if
> necessary.
What is this file Formula/lib/libmps.rb? What is its license?
> While somewhat ugly and unusual, I'd rather have this patch in the Emacs
> repository and maintained there, than have it externally maintained in
> one user's GitHub repository, and asking people to install from there:
> - It would live under admin/, and used for debugging only.
> - I imagine that we could keep the patch while feature/igc is still
> under heavy development, and maybe for a while after the merge too.
> - I can volunteer to maintain the in-tree patch.
>
> Does that sound acceptable?
Beware: keeping patches in the repository is a constant headache:
patches usually include trailing whitespace that our commit hooks
reject. So each time you merge branches or cherry-pick etc., you risk
hitting this trailing-whitespace problem, and have then manually
override that with appropriate Git switches.
Why is this patch needed? what is special in MPS that requires us to
modify brew's tools? If it's just for building the debug version of
MPS, then why is it so important for us to keep the patch? how many
people will even want or need to build the debug version of MPS?
Isn't it possible to ask whoever maintains brew or even the MPS folks
to include this in their distributions? Or some other solution, which
would avoid the need for us to keep this in our repository. Because
it sounds overboard to me to be the keepers of such a patch, even more
than keeping MPS patches. MPS is an external library, and as long as
we are treating at as such, I'd like to avoid adding to our repository
stuff that is needed for building MPS. The instructions we have in
INSTALL-IGC about that are fine, but going much farther and deeper in
our involvement in MPS build procedures is too much for my palate.
Especially since it involves macOS tools, for which we have very
little expertise on board to support our being responsible for these
patches.
This bug report was last modified 177 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.