search

conda-forge / emacs-feedstock

A conda-smithy repository for emacs.
BSD 3-Clause "New" or "Revised" License
6 stars 16 forks source link

emacs v29.1 #75

Closed regro-cf-autotick-bot closed 10 months ago

regro-cf-autotick-bot commented 1 year ago

It is very likely that the current package version for this feedstock is out of date.

Checklist before merging this PR:

Information about this PR:

  1. Feel free to push to the bot's branch to update this PR if needed.
  2. The bot will almost always only open one PR per version.
  3. The bot will stop issuing PRs if more than 3 version bump PRs generated by the bot are open. If you don't want to package a particular version please close the PR.
  4. If you want these PRs to be merged automatically, make an issue with code>@conda-forge-admin,</codeplease add bot automerge in the title and merge the resulting PR. This command will add our bot automerge feature to your feedstock.
  5. If this PR was opened in error or needs to be updated please add the bot-rerun label to this PR. The bot will close this PR and schedule another one. If you do not have permissions to add this label, you can use the phrase code>@<space/conda-forge-admin, please rerun bot in a PR comment to have the conda-forge-admin add it for you.

Pending Dependency Version Updates

Here is a list of all the pending dependency version updates for this repo. Please double check all dependencies before merging.

Name Upstream Version Current Version
gmp 6.3.0 Anaconda-Server Badge
libjpeg-turbo 9e Anaconda-Server Badge

Dependency Analysis

Please note that this analysis is highly experimental. The aim here is to make maintenance easier by inspecting the package's dependencies. Importantly this analysis does not support optional dependencies, please double check those before making changes. If you do not want hinting of this kind ever please add bot: inspection: false to your conda-forge.yml. If you encounter issues with this feature please ping the bot team conda-forge/bot.

Analysis by source code inspection shows a discrepancy between it and the the package's stated requirements in the meta.yaml.

Packages found by source code inspection but not in the meta.yaml:

Packages found in the meta.yaml but not found by source code inspection:

This PR was created by the regro-cf-autotick-bot. The regro-cf-autotick-bot is a service to automatically track the dependency graph, migrate packages, and propose package version updates for conda-forge. Feel free to drop us a line if there are any issues! This PR was generated by https://github.com/regro/cf-scripts/actions/runs/6007374407, please use this URL for debugging.

conda-forge-webservices[bot] commented 1 year ago

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

asmeurer commented 1 year ago

Don't know why the bot decided to redo this, but to copy my comments from the other PR

We need to make sure this gets compiled with tree-sitter support (see masteringemacs.org/article/whats-new-in-emacs-29-1).

We can also try the new --with-native-compilation=aot flag. See also https://github.com/conda-forge/emacs-feedstock/issues/59

asmeurer commented 1 year ago

Also it would be good to get this actually working on Linux. Right now it doesn't despite what the CI says (see https://github.com/conda-forge/emacs-feedstock/issues/63 and https://github.com/conda-forge/emacs-feedstock/issues/60)

asmeurer commented 10 months ago

@conda-forge-admin, please rerender

asmeurer commented 10 months ago

@erykoff did my best to update your arm macos patches here.

erykoff commented 10 months ago

@asmeurer Thank you so much! Though to be honest looking at a git diff of two versions of a git diff patch is not the easiest thing for my brain to comprehend. But it does look reasonable!

Sorry that I haven't been able to get to this myself.

asmeurer commented 10 months ago

I just updated them so that they apply again. My main worry is that there might be some other places in the files that need to be changed too. I'm still not completely clear what these patches are doing. Anyway, the build is running now so we'll see how it goes.

erykoff commented 10 months ago

The emacs build first builds itself and then runs emacs to build the docs and the "pdump" file for fast start with preloading macros. The problem with cross-compiling from x86 to arm64 is that it is built with a target of arm64 but this binary can't be run on x86. So it first does an x86 build natively in a special directory. And when it comes time to build the docs in the cross-compiled run it uses the natively built executable. It's an ugly and inefficient hack but it does generally work.

asmeurer commented 10 months ago

Apparently it didn't work

make[2]: ../src/emacs: Bad CPU type in executable
asmeurer commented 10 months ago

I guess that makes sense, but why is it cross-compiling at all? Is the CI not actually an osx-arm64 machine? Are all osx-arm64 conda-forge builds cross-compiled?

erykoff commented 10 months ago

All conda forge osx-arm64 builds are cross compiled on conda forge. We do not have Apple Silicon runners.

Anyway, as for the error, you'd have to look at the patched makefile and see if there's anywhere that the new version is calling $(AM_V_at)$(libsrc)/emacs instead of $(AM_V_at)$(libsrc_run)/emacs and patch that.

asmeurer commented 10 months ago

I'm not seeing anything that stands out. The only thing that I see that's still using libsrc instead of libsrc_run is be-resources, which seems to be something for Haiku.

asmeurer commented 10 months ago

Anyone understand makefiles? I would have thought that this line https://github.com/emacs-mirror/emacs/blob/emacs-29.1/src/Makefile.in#L897 would override the value of EMACS set here https://github.com/emacs-mirror/emacs/blob/emacs-29.1/lisp/Makefile.in#L56, but it doesn't seem to be. As far as I can tell that's the only place that the failing line could be coming from

2024-01-10T03:52:06.9060080Z '../src/emacs' -batch --no-site-file --no-site-lisp \
2024-01-10T03:52:06.9062450Z             -l ./emacs-lisp/loaddefs-gen.elc \
2024-01-10T03:52:06.9067440Z     -f loaddefs-generate--emacs-batch . ./calc ./calendar ./cedet ./cedet/ede ./cedet/semantic ./cedet/semantic/analyze ./cedet/semantic/bovine ./cedet/semantic/decorate ./cedet/semantic/symref ./cedet/semantic/wisent ./cedet/srecode ./emacs-lisp ./emulation ./erc ./eshell ./gnus ./image ./international ./language ./leim ./leim/ja-dic ./leim/quail ./mail ./mh-e ./net ./nxml ./org ./play ./progmodes ./textmodes ./url ./use-package ./vc
2024-01-10T03:52:06.9069210Z make[2]: ../src/emacs: Bad CPU type in executable

because this is the only place that calls loaddefs-gen.elc https://github.com/emacs-mirror/emacs/blob/a9b28224af0f73d1fe0f422e9b318c5b91af889b/lisp/Makefile.in#L199-L203, and that's the only place that calls make autoloads.

asmeurer commented 10 months ago

I see, it's not actually coming from that. It comes from make -C lisp all. No idea where that is actually called. I also didn't realize that variables aren't inherited in makefiles by default (https://makefiletutorial.com/#export-environments-and-recursive-make). I have a patch that might work now.

asmeurer commented 10 months ago

By the way I really hope we can get native mac arm machines at some point. I just checked and the patch files already don't apply in emacs master, so we're going to have to do this again for 30.1. The build files seem to churn quite a bit so I wouldn't be surprised if it is nontrivial to get it working again too.

asmeurer commented 10 months ago

Finally got it working. I guess there's no way to actually test the cross-compiled build other than merging and testing it on my computer.