-
-
Notifications
You must be signed in to change notification settings - Fork 267
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
CMake: Somewhat simplify separate compiler and runtime builds, incl. cross-compiling LDC itself #4872
base: master
Are you sure you want to change the base?
Conversation
The config file is generated in the runtime |
863c355
to
b6a2ec4
Compare
Which allows building the `all` target to cross-compile all LDC executables. And to install those executables, as well as the LTO linker plugin and compiler-rt libraries from cross-LLVM.
392e78c
to
276cda4
Compare
In my separate compiler + manual multilib build I use this patch. Maybe it can help you? |
276cda4
to
e93ed29
Compare
Instead of including (incomplete) imports when installing a standalone library build, I think it makes much more sense to generate matching This e.g. allows using the And in #4870, we could go a bit further, converting the |
In a `etc/` directory. When included from the LDC parent build, switch from `../bin/` to `../etc/`.
e93ed29
to
9c34ddd
Compare
I'm not sure what you mean by incomplete imports. As far as I see it, currently there are:
So, the only headers the runtime should install are phobos and druntime, which don't require any special handling.
True, it mostly depends on the runtime. But that's the issue, it isn't completely independent from the compiler. Even if there are a few switches that the compiler builds cares about: What you're trying to do with I think both of us are thinking of different things when we say cross-builds. When I say a cross-build I mean building the runtime (and possible the compiler) for another architecture and installing the result on a system running that architecture. When you say it I'm getting the impression that you mean building the runtime for another architecture, but installing that result on the build machine, not on something else. I did think about the ldc2.conf situation and I think that the easiest way of supporting both mine and (what I assume is) your use case is having it be a directory. I'm pretty sure that this would be a lot easier than going around and adding special cases to the cmake file but it won't be too hard to warrant dropping one of the two possible use cases |
Yeah, missing gccbuiltins.
If we are talking about CMake-installing ( But those installed artifacts (libraries and object file) then work on every other box using another prebuilt LDC with matching version (and matching target C cross-toolchain), for cross-linking. They just need to be copied to that other box, and the ldc2.conf extended (e.g., based on the now-produced ldc2.conf as part of I'm still not sure what you wanna do for Fedora. I guess you could enable cross-compiling to the other archs supported by Fedora, out of the box or whatever. But you'll most likely never be able to allow your users to easily cross-compile to Windows, Mac or Android, if you don't wanna depend on the official LDC binaries from GitHub. E.g., with the existing prebuilt multilib Linux package, I can easily cross-compile & -link a |
Let me think about this for a little bit and let's try to keep the conversation in one issue, either this or #4870, or some new one, since my fingers are getting dizzy from switching tabs and some of the points we're making are relevant to both discussions |
Cross-compiling the compiler itself isn't trivial as you probably know by now :) - but that should be an exotic use case, mainly as workaround for missing native CI runners or when trying to conquer a new platform for which there's no usable D compiler yet. If GDC is available and working for a new platform (which LDC doesn't completely support yet), using that as host D (cross-)compiler is strongly encouraged - for LDC to work, D and C++ interop needs to work, and while GDC doesn't have to deal with platform-specific ABI quirks, LDC does, so LDC can only build a working version of itself as soon as its ABI is fully working for the desired target. Cross-compiling the runtime libs only is much simpler, and
|
Ok, I've thought about how to word this. Let's say that our goal is strictly being able to cross-compile the runtime libs and install them on the build machine, so your use case. You've implemented this in #4870 so let's start with that solution, with You also said that you could augment this solution with the Let's go with the cmake approach since there's already code in there that generated the switches. I am proposing that you can augment this solution in a way that benefits both my and your use case. if(NOT CMAKE_CROSS_COMPILING) # OR (NOT LDC_EXE)
list(APPEND LDC_DEFAULT_SWITCHES "-defaultlib=..." "-Iruntime/import")
configure_file(../ldc2.conf.in etc/ldc2.conf)
configure_file(../ldc2_install.conf.in etc/ldc2_install.conf)
endif()
But you can change that to: list(APPEND LDC_DEFAULT_SWITCHES "-defaultlib=..." "-Iruntime/import")
configure_file(../ldc2.conf.in etc/ldc2.conf)
configure_file(../ldc2_install.conf.in etc/ldc2_install.conf) and move the runtime-independent switches to the root list(APPEND LDC_DEFAULT_SWITCHES .....)
list(APPEND WASM_DEFAULT_SWITCHES .....)
if(LDC_WITH_LLD)
list(APPEND WASM_DEFAULT_SWITCHES ...)
endif()
configure_file(ldc2.conf.in etc/ldc2.conf)
configure_file(../ldc2_install.conf.in etc/ldc2_install.conf) You would get the same result when cross-compiling the runtime but, of course, the native compiler build is now broken. And here's my main point, let's just have the compiler and the runtime generate separate config files. This is very important but I'm not suggesting the compiler being able to support The end result would look like:
Here makeConfSection(NAME "wasm"
SECTION "^wasm(32|64)-"
SWITCHES -defaultlib= -L-z -Lstack-size=1048576 -L--stack-first -L--export-dynamic
) The end result is the same as what you originally had, but you spent:
and got:
|
8ae3946
to
5b317d2
Compare
The workflow here for gathering the package contents for a cross-compiled compiler+runtime was indeed simplified by keeping on letting the runtime install the imports, and copying the gccbuiltins manually - that allows skipping the bootstrap compiler installation again (#4871). So I'll change that in #4870. |
For me copying to another box means letting the package manager install them and that implies that a cross-build would install the same files (and the same contents) as a native build. I can't touch files that are already built so I need the cross-build to be functional when the build machine is done with it, not when the host machine installs it. (Note that technically I can change post-installed files but that feature is not meant for this, it is meant for updating cache files like the XDG application database)
I'm on Gentoo and the situation here is a bit different. You can technically install it on Windows (in cygwin) and on Android (in tmux) so, technically, I could target those systems. Of course, this is more theoretical because the user base is so little there that you would encounter a lot of bugs that you would have to solve yourself but Gentoo does provide the tools to accomplish this, at least on paper
I agree with it being more rare in normal circumstances but on a source-based distribution like Gentoo it's not that to build (or cross-build) things. With it being non-trivial I don't really agree. I do have an implementation that works mostly but that takes advantage of some assumptions that only hold true for Gentoo. Regardless, my argument is that this exotic use case doesn't require that much more work here to support.
As a sidenote, I prefer using the cmake wrappers made available by Gentoo since they already handle the C-toolchain side of cross-compiling and I expect that it will be less work to reimplement the missing features from
Multilib builds are somewhat related by not that required. I already can do this, with the caveat that I use the config file from the runtime build, since, like you said, it contains everything needed to get the compiler working. Having proper support for cross-build would simplify my work a little as well as improve the ldc2.conf short-commings but the priority for me right now is making sure that cross compiling works fine (for both my and your use case) In terms of other architectures I probably won't target more than A more technical perspective is being able to have self-hosted compilers for niche-arches like Anyway I've done some recent work also on gdc and, with the help on someone more experienced, we got that package to work when cross-compiled so I can rely on that being the bootstrap-compiler on other arches, if need may arise. |
999f471
to
2244172
Compare
Which allows building the
all
target to cross-compile all LDC executables. And to install those executables, as well as the LTO linker plugin and compiler-rt libraries from cross-LLVM.