search

caldwell / build-emacs

Build scripts for www.emacsformacosx.com
http://www.emacsformacosx.com/about
GNU General Public License v3.0
364 stars 61 forks source link

Newbie questions #114

Closed pedz closed 2 years ago

pedz commented 2 years ago

I wish GitHub had a way to just "chat" rather than open "an issue".

I've used and built GNU emacs since it was first released on different platforms: BSD, AIX, macOS, Linux. A few years ago, I got tired and started just using https://emacsformacosx.com. Thank you...

The https://emacsformacosx.com has had a long running issue with opening files in ~/Desktop, ~/Downloads, and ~/Documents. I've contributed slightly to that issue. This past week, I also started having problems with Magit and long story short, I decided to pull down the Emacs tar file, untar it, and then did: ./configure; make; make install. I'm on an M1 Max MacBook Pro. All that went fine.

I then tried to double click the app in the nextstep directory and I get a nasty-gram "“Emacs” is damaged and can’t be opened. You should move it to the Trash." with two choices of "Move to Trash" or "Cancel". "Cancel" exits.

Curiously, if I execute src/emacs (from a shell prompt inside Terminal), Emacs starts up in a window and runs fine. The weird thing is it starts up with the window not in the front But aside from that it functions perfectly including opening files in ~/Desktop, etc just fine.

A wise man, which I'm not, would stop there, declare victory, and drink until he passed out... A HA!!! But not me.

I assumed the weirdness with the Emacs.app is something to do with Apple's security and I wanted to learn so I downloaded (again) build-emacs, fetched an image from GNU.org, and typed in ./build-emacs-from-tar ....

It died with

Please verify that you have Guile installed.  If you installed Guile
from a binary distribution, please verify that you have also installed
the development packages.  If you installed it yourself, you might need
to adjust your PKG_CONFIG_PATH; see the pkg-config man page for more.

There is an issue and an update from @dgreatwood:

Testing this, it runs through on my MAC machines except that the build script can't find the guile package. Since I already have guile 3.0.5 installed under brew, I tried:
export PKG_CONFIG_PATH="/usr/local/opt/guile/lib/pkgconfig"
and then rerunning build. Build then completes.

I already had Guile from Home-brew so I set my PKG_CONFIG_PATH and re-ran the command but it died in the same place. I assume that I just do the ./build-emacs-from-tar ... again to restart the build process.

I have lots of questions if you have time to answer them.

When I run ./build-emacs-from-tar ... it starts downloading and building packages -- pkg-config to start with. Are you doing this just to be sure that everything you need for Emacs is built fresh and perhaps something to do with the packaging when you start sending executables to other people? I'm fine either way.. I'm not questioning that you are doing it. I'm trying to understand your motivations and objectives better.

Has the issue with Guile been fixed? I did a pull just before I started so I assume not. Any suggestions of how to fix it?

Have you considered either contributing to Home-brew or contributing to GNU Emacs what you have learned? (Perhaps you do that all the time.). It seems like fresh off the vine, emacs builds easily on MacOS and that's been true for a very long time -- even before I started using Home-brew. The current issue right now is just some funky Apple security thing -- signature or "notarizing" -- whatever that is. Then everyone could build their emacs fresh. Again ... I'm mostly trying to understand your objectives. I am in no way wanting to criticize what you have provided over the years.

I'll shut up now and go explore some web pages about signing and notarizing that this site has pointed me to.

Thank you... truly.

pedz commented 2 years ago

Update... I should have noticed this before. Home-brew on Apple silicon doesn't use /usr/local. I did:

export PKG_CONFIG_PATH="/opt/homebrew/Cellar/guile/3.0.8/lib/pkgconfig"

and the build completed.

I did the ./combine-and-package ... (this is for emacs-27.2 on an arm64) and the result dies when I double click it.

caldwell commented 2 years ago

I think the issue you see with the "move to the trash" dialog is that Apple doesn't like to launch non-codesigned apps from Finder any more. If you codesign the app (the line is somewhere in combine-and-package then it'll be happier, though still not perfect because it's not notarized.

Are you doing this just to be sure that everything you need for Emacs is built fresh and perhaps something to do with the packaging when you start sending executables to other people?

Both really, but mostly the latter. The libraries need to go into the app and since I build for OSes that Homebrew doesn't support I can't rely on it. Manually managing all the dependencies on the build machines is too chaotic. If one is out of date from the others and versions don't match up, for instance…blech. Just building all the required deps manually makes it repeatable and consistent across versions. The downside is that I have to manually change things to get newer version of the deps. The upside is that the deps never change on their own and break things :-).

I did the ./combine-and-package ... (this is for emacs-27.2 on an arm64) and the result dies when I double click it.

Does it die with the same "move to trash" error, or is it the lighter "couldn't be opened…" error? If it's the latter, right click the app and click "open" and you'll get that same dialog but with an extra button that will allow you to continue on and open it anyway.

pedz commented 2 years ago

The third paragraph of my first post is, at this time, the best source for why I started down this path. It honestly all seems very vague to me now how / why I got started down this path. I was on a general quest to set up a new work environment that works on macOS, BSD, Ubuntu, and Raspberry Pi.

At this point, I'm content with what I have. I just pulled down 18.1 tar ball and got it running without any fuss on macOS and BSD. I don't expect the Ubuntu or the Raspberry Pi builds to be a problem plus those are extremely minor players in my daily activities right now -- although I expect to be spending a lot of time on the Pi "soon" (I've been saying that for 6 months now).

I've opened bug report 54677 for Emacs. The desire to produce core files came from a discussion on one of the Stack Exchange sites. I was wanting to be more helpful in debugging the few issues I hit with Emacs and core files would sometimes be helpful. I also thought they might want to incorporate the needed steps to get what they have working fresh out of the box.

I also just now tested and put a comment in issue #84 here. It seems to work for me -- congrats!

Does it die with the same "move to trash" error, or is it the lighter "couldn't be opened…" error? If it's the latter, right click the app and click "open" and you'll get that same dialog but with an extra button that will allow you to continue on and open it anyway.

As best I can recall, it was neither. I should have taken better notes. Sorry. This was before I could produce core files. The files in DiagnosticReports go back to March 29th but from the date on my original update it seems that would have been March 26th or 27th.

On a slight different topic if you have time: from what you said about the dependencies, is it true that if I got on a total virgin machine -- perhaps in a container -- that your scripts would pull down and build everything needed to build emacs? That is super impressive to me. How / where is that kept? I'm asking just out of curiosity. In a previous life I was on AIX and tried to build open source packages. Generally I could but it was never very reproducible.

To repeat, at this point I'm content. If there is anything I can do to help out with your project, please don't hesitate to ask. I will likely just use the Emacs versions I build but it isn't hard to pull down one of your builds and test it or something like that. My previous life was 100% around debugging -- usually system crashes on AIX or internal firmware crashes on the network adapters.

Good luck, take care, and Thank you!

caldwell commented 2 years ago

Yes, the dependency building code should work on a machine with just build tools installed (compilers, make, etc). It's in 3 pieces in the code:

Before I wrote that I had an older piece of code that downloaded Homebrew and used it configured locally to build things. The goal was so that I didn't have to write the "configure, make, install" code myself, but brew became more rigid and hard to work with as time went on. They also really clamped down on how far back they were willing to build so I started having to use specific git hashes to clamp Homebrew at certain points that would work.

In the end Homebrew was hurting me more that it was helping me and so I just tried to make the smallest, dumbest dependency builder possible. Dumb in the sense that it doesn't consider dependencies, it just relies on you ordering them correctly. It's not trying to be generic, so there are explicit macOS references in there, but it could be tweaked to be used on Linux.

It sounds like we can close this issue.