-
Notifications
You must be signed in to change notification settings - Fork 723
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add Emacs-25.3 #5579
add Emacs-25.3 #5579
Conversation
Argh. Apparently toolchain GCC implicitly satisfies the binutils dep while GCCcore does not. No luck finding doc on the difference between them. Is there a way to run these consistency checks before submitting? |
@tutufan The
Easyconfigs that use the For I hope this clarifies things a bit... |
This was indeed helpful--thanks for your reply. Most of this makes sense, although I'm tripping over these two sentences a bit:
vs
Is the second GCC just a typo? (i.e., should be GCCcore) Or am I missing a further subtlety? |
@tutufan - might be worth mentioning in the |
@tutufan The wording is a bit confusing... In the first sentence you highlighted, with 'compatible' I actually mean "will be considered when resolving dependencies". So, when resolving dependencies for something built with the In the 2nd sentence, I mean that you can load a module built with the |
@verdurin Actually, this build does include the X client, but not built with the X toolkit. That is, the user interface looks like the classic emacs 1990s GUI. I don't use the GUI myself, so don't really care. We could pull in GTK and all of that (a bit expensive), but thought I'd leave that for someone who cares. |
@boegel Tried switching to GCC toolchain just now, and quickly realized that the dependencies (e.g., zlib, libpng) are nowhere near as up-to-date for GCC as they are for GCCcore. There doesn't even seem to be one for libpng right now. For expediency, I'm tempted to just stick with GCCcore and introduce the binutils build dep. Alternatively, I could add up-to-date GCC easyconfigs for all of the deps. Which is better? Also, if I were to do the latter, would you want to see one big PR, or does that need to be split into multiple PRs? |
@tutufan When using the So, if you switch to W.r.t. your question on including easyconfigs for dependencies: that's usually OK if the total amount of easyconfigs in a single PR is small enough (say, <= 10). Especially if it's mainly version/toolchain updates for stuff we have already it's OK, since that's easy to review via |
@boegel Somehow (I'm using
|
Hmm. The last sentence of this section suggests that this ought to work: using minimal toolschains for dependencies |
@tutufan The problem is that the robot can't find all necessary easyconfig files anymore, which is currently required to resolve dependencies via subtoolchains (we should loosen that up a bit though, it's now a bit too strict; see easybuilders/easybuild-framework#2375). Here's the issue in your example, I think:
There's usually no reason to overwrite |
@boegel Looking back at the doc for I'd forgotten, though, that these options affect dependency resolution, at least according to the doc. It's not clear what happens if both options are specified, but in any case, I'm still failing to get subtoolchain dependency resolution to work. Here are some failures:
Also, this case of a nonexistent config (note "-xxx") suggests that something is putting "." in the path, which seems like unexpected/undesirable behavior to me.
(The Emacs easyconfig I'm using is exactly the same as the one in this PR, except that Any ideas? Am I still missing something? Or should I just give up on subtoolchain resolution and go back to |
Add latest emacs, more or less in the prior style (X/png/jpeg).
This version just uses GCCcore after all. |
@tutufan So, you are pointing That should work, and the easiest way to do that is to override the location via Your last attempt (providing the location to both You could try enabling |
Test report by @boegel |
Test report by @boegel |
@tutufan If it's OK with you, this PR looks good to go for me. Maybe we should follow up on your issue with |
Yes, I think pushing this out now makes sense. Regarding your questions, yes, that's my intent. My intent is that only my tree is searched for easyconfigs, and the Looking at the debug log for this, it appears that actually a lot of directories are being searched (due to
As far as I can see, the log does not actually indicate the specific location where the easyconfig was actually found. (That would be useful!) |
Going in, thanks @tutufan! |
Add latest emacs, more or less in the prior style (X/png/jpeg).
The existing Emacs configs all slightly vary in minor ways--this is intended to be a reasonable compromise of those.