Rename gerbil executables to avoid installation conflict with gambit scheme #1422
Labels
No labels
UX
active development
backlog
blocker
bootstrap
bounty
bug
dependencies
discussion
documentation
duplicate
enhancement
flaky test
help wanted
invalid
javascript
question
release
tendentious
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
mighty-gerbils/gerbil#1422
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Hello there!
I was recently trying to install both gerbil and gambit scheme on macos using homebrew, but I was prevented by this and this.
In order to fix this conflict and help both projects, I'd like to propose to rename gerbil's executables as following:
gerbilifor the interpretergerbilcfor the C-enabled compilergerbilcxxfor the CXX-enabled compilerit can be an option in configure, sure.
But there need to be some details taken care of, keep the issue open.
Both the homebrew and our in tree brew recipes are years out of date and we
no longer conflict that way. I suggest using a modern Gerbil and not
placing any of its gambit binaries in your path. We do not conflict with
them.
Now if the year old gambit says that a 3 year old Gerbil release conflicts,
that is not really an issue to fix with a new release that does not
conflict. See the issue? Pandering to an ancient release that we wish
nobody uses to please a homebrew that nobody should use is not a good idea.
And those names you are suggesting are not what is in conflict and will not
fix that problem.
@.*** ~ % ls /opt/gerbil/bin
gxensemble gxhttpd-ensemble-test gxi gxprof gxtags
gerbil gxc gxhttpd gxhttpd-test gxpkg gxswank gxtest
As you can see, it is the gambuild-C and gsc that are in conflict. So
renaming our executables will not help in the least.
Again, rather than looking down the wrong path, I think you should use the
gcc build instructions on our MacOS readme for now, and wait for a release
that we actually endorse rather than spend your time using an outdated and
undocumented old release that nobody really uses.
We'll be releasing this year to fix that, kinda sorta. Make sense? :)
--drewc
On Sun, Mar 29, 2026 at 12:00 PM fcannini @.***> wrote:
@drewc You have no idea how aggressive and condescending you're coming across, do you?
No I do not.
On Mon, Mar 30, 2026 at 8:11 PM fcannini @.***> wrote:
@vyzo Please let me know if I may be of any help.
sure, but in the near future. We are transitioning development of github.