nim: update to 1.6.0, fix non-x86_64/i686 packages, improve template #34106
Conversation
|
Well, the CI didn't complain about the lack of passing ucpu=i686 to the bootstrap compiler build when compiling for i686. Would anyone know why that would ever be necessary? |
|
Since github has drafts now, I've made this one. I got to thinking about the i686 build and I think I understand how it works. The cpu is set to i686 because nim doesn't really support cross-building the compiler. The problem is this doesn't actually work when you try to run the compile locally (and it didn't work for the previous csources) so I'm confused there. I pushed to see what CI says about it. I think actually the correct solution would be to do for i686 what we're currently doing for the other non x86_64 arches an I'm not sure why that isn't the case already. But in the meanwhile, if this does end up working in CI, I would like to keep it that way and get this version bump merged. Then doing i686 builds properly can be a task for later. That being said I think ALL builds should be done the way that they are for non-x86_64/i686 and that's so you can cross-compile a nim void package from a non-x86_64 machine. But I don't know what the void policy is there. |
EliteTK
force-pushed
the
nim-1.6.0
branch
2 times, most recently
from
b4c4955
to
7a320bd
Compare
|
Okay, that worked, I checked the existing packages for nim in the repositories for other arches and they are compiled correctly. The void cross-building system confuses me but I've squashed the revert and I'm going to mark this as ready for review. |
|
Okay, so I figured out that the current (and this bump doesn't change this) packages which ship for voidlinux come with a nim.cfg which sets the compiler for multiple architectures to be the cross compiler for the package architecture on non-x86_64 and non-i686 packages. I verified this by just downloading an aarch64 package and checking the config. There's an easy workaround for this I can put into a separate commit. |
EliteTK
changed the title
|
I've now pushed the cross-platform build fixes as well as a few template improvements. |
EliteTK
force-pushed
the
nim-1.6.0
branch
4 times, most recently
from
452efcd
to
0b43bbd
Compare
Version bump to 1.6.0 including the following changes:
- Nim now comes with testament
- Fusion library is no longer bundled with nim
- Examples no longer come with nim
- FIX - non-x86_64/i686 nim.cfg compiler configuration
Non-x86_64/i686 builds no longer end up with a broken nim.cfg which
will try to use the package build time $CC to build packages for the
package architecture as well as a bunch of others (which will simply
not work).
- FIX - arm nim.cfg compiler configuration
The default arm.linux.gcc.(linker)?exe variables are now commented on
non-x86_64/i686 builds to ensure that arm packages don't end up with
the same issue as above.
- CLEANUP - use koch to build non-x86_64/i686 tools
The loop was unnecessary.
- note: This means nimsuggest is now built without -d:release on all
builds (not just x86_64/i686 builds). I am not sure if this is
intentional or an upstream bug, should be investigated at some
point.
- CLEANUP - use make to build the bootstrap compiler
|
Squashed per instruction on irc. |
FWIW i686 is built natively. |
|
Sorry for the delay, great PR! |
Testing the changes
Local build testing
I think it is about ready.
Old comments below this line.
I was mainly putting this up here to gather comments. For background, things which have changed between what is available in the repositories and 1.6.0:
Other notes:
--skipUserCfg --skipParentCfg --hints:offeverywhere. I'm not sure if we should mirror that. I think the first two options would be irrelevant inside the build environment and the last option is just removing diagnostics. They're not essential options but I also don't think they hurt.