-
-
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
ldc-build-runtime: Add --installWithLibSuffix
option
#4870
base: master
Are you sure you want to change the base?
Conversation
a2a00b6
to
074ed6d
Compare
To simplify copying the libraries to an existing LDC installation.
074ed6d
to
9be3b9f
Compare
This somewhat breaks me relying on the runtime installing the include files. Is there any reason to stop installing them when the runtime is built separately? There shouldn't be an issue if they overwrite the files belonging to the host ldc2. |
I don't think there's a good reason to duplicate the imports with library bundles; the bundled imports don't depend on the target. And the runtime build in isolation wouldn't have them all; the |
I didn't mean to duplicate the imports. I meant leaving
This way the runtime cmake stays a little bit more independent from the compiler, which I think will help with maintenance in the future. Also my use case keeps working. |
They also depend on the specific version LLVM. But I have a question, would it be correct to have these files generated and stored in the repo and then, in cmake, rather than handling the generator program as well as cross-compilation we would simply install the files we already have? |
I guess we could, but as we support multiple LLVM versions, I don't think it would simplify things, rather just one more extra step when adding support for a new LLVM version. |
It would be a 1-time cost when bumping LLVM compared to always paying the cost of compiling It would also slightly clean up the cmake files as there wouldn't be any more need to |
Twice a year or so. And would most likely need to be CI-automated or at least verified, to make sure that process is robust, not depend on how the guy doing it had configured his LLVM.
I think that's negligible; chances are high this tool is built & run while the compiler frontend is being compiled and waited for.
If you have a prebuilt |
Oh and if we had multiple |
Alright, let me show you how I would need to express the runtime correctly embedding the compiler-rt libdir and gccbuiltins if I were to package it in Gentoo. 1. Build the compiler
This builds and installs the compiler. The files that would be installing (assuming we don't build gccbuiltns in this step) would be:
2. Build the runtime
This would install, amongst the standard headers and libs:
Now, those gccbuiltins and ldc2.conf file need to be generated from a LLVM version. Let's say that I called 3. Rebuild the compiler
Now we end up in a situation in which the generated If I wanted to fix this I would then need to make 2 Building the runtime (fixed)
I can specify in the ebuild file that the LLVM version for ldc2-runtime must match the one for ldc2 and the build system will take care of making sure that happens. This, unfortunately has a consequence. 3 Rebuilding the compiler (downside)
If I did that portage would correctly enforce that the LLVM_SLOT for the compiler and the runtime must match and, alongside the compiler, it would also rebuild the runtime and this is the issue. What you are suggesting makes the runtime build be dependent on a LLVM version (excluding jit-rt which actually depends on LLVM) which is not reflecting the source code. You may argue that this is a consequence of me doing separate compiler and runtime builds but the exact same issues appears if I introduce cross-compiling, and there I must do the builds separately. The only way to have the code function like it should would be:
|
My main concern right now is not whether we can manage to get a runtime cross-build to play nicely with an already installed ldc2, it's putting in the work to add all these special cases for doing out-of-compiler and all-at-once builds, where the a way better result can be achieved by doing some smaller fundamental changes |
AFAICT, that's the problem right there. IMHO, the imports belong in the compiler package, not the runtime package - they don't depend on target specifics or other runtime-package parameters, but do depend on the LLVM version the compiler was linked against - for Now you can of course bundle the imports with the runtime packages - but not the gccbuiltins. Those definitely need to be bundled with the compiler, because of the LLVM dependency. But having two import roots (normal imports from runtime package, and gccbuiltins dir from compiler package) means So to me, the natural solution would be to bundle all imports with the compiler package. And to restrict the runtime packages to prebuilt artifacts, possibly in hardcoded locations expected by an
The compiler package provides imports and ldc2.conf: |
Yes! This is what I ended up with and it was part of my changes that in submitted in regards to ldc2.conf. Putting all the gccbuiltins bits into the root
it makes sense for the gccbuiltins to be built & installed as part of the compiler but the stdlib headers is another thing entirely. If my goal is getting separate compiler and runtime builds then isn't it weird that I would want to mix the 2 even more? In my world if I Note that the arch-family packages don't install the headers as part of the libphobos because, probably, they don't handle static-libs & multilib as cleanly as Gentoo. In Gentoo the multilib package is a different configuration of the Additionally, their packages seems to build the ldc2 package once (compiler + runtime) and the split their install, and that's not what I need https://gitlab.archlinux.org/archlinux/packaging/packages/ldc/-/blob/main/PKGBUILD?ref_type=heads#L77 |
How about we install the imports as part of installing the compiler, not the runtime? It may sound weird at first, but as they are ideally bundled with the compiler package, it IMO makes sense to install/copy them when installing the compiler - plus they'd be complete with the gccbuiltins headers that way. In that case, a pure compiler build/install without runtime would still need the |
I think what you mean is that bundling the headers with the compiler would mark the separation:
This matches what some distributions do:
But not others:
But, in all those cases (with the exception of Gentoo) the ldc package is actually built as a whole, and then split off into different tarballs for distribution. This is not what I'm asking for as I need a way to build the different "tarballs" independently from each other. We could go and try to take an approach from the above but choosing simply because somebody else does it is not enough. However, the argument of installing the phobos & druntime headers as part of the compiler build is based on the premise that those files are architecturally (more correctly runtime-build) independent, which they aren't fully.
|
Thx for the distros comparison! Yeah, I take it hardly any other distro goes the way of building compiler and runtime separately, so haven't hit the issues you have with the Gentoo source packages - where suddenly it becomes a question of installing which project yields which files. And e.g. the ugly asymmetry that the
Basically moving this to the top-level (compiler) Lines 893 to 904 in 9f4184e
I wanna avoid including
I think this was an oversight, and think this should be always installed, regardless of whether the jitrt library has been built or not. It's the only violation of the every-compiler-package-bundles-the-same-imports rule (for the same compiler version obviously), modulo incomplete gccbuiltins headers (depending on enabled LLVM backends as well as LLVM version).
I don't see glibc versioning as a blocker for the bundled imports. FreeBSD is similar and needs a predefined version to select the proper symbols; this predefined version ( As long as I keep watch, there aren't going to be any target-dependent imports, i.e., different trees. In druntime and Phobos, target specifics are handled via |
Alright, we seem to be getting closer to a common conclusion: I agree with you on:
I would still prefer to install the stdlib headers as part of the
I can live with this.
What I presented would result in the same import tree for all targets, non-glibc would simply have a dummy Anyways, I already said that I'm fine with going with the triple approach like the BSDs, if the need arises. I hope that I didn't forget any details but this feels like all that we've discussed about |
Awesome, looks like we have a compromise! 👍 Please note that this is all v1.41 stuff due to the breaking changes; v1.40.1 is coming up these days (beta1 first, then the final hopefully 1-2 weeks later). Incl. the |
That's fine, I do prefer waiting for an implementation if we need the time to make sure that it's as good as we can get it, so long as progress doesn't stall |
To simplify copying the libraries to an existing LDC installation.