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
Init ldc at 1.3.0, fix bootstrap dmd build, fix dtools test, run dmd-testsuite in checkPhase and fix Foundation framework #28635
Conversation
Remove cppa test for now because it isn't working.
@ThomasMader, thanks for your PR! By analyzing the history of the files in this pull request, we identified @nckx, @pikajude and @vlstill to be potential reviewers. |
description = "The LLVM-based D compiler"; | ||
homepage = https://github.com/ldc-developers/ldc; | ||
# from https://github.com/ldc-developers/ldc/blob/master/LICENSE | ||
license = with licenses; [ bsd3 boost mit ncsa gpl2Plus ]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you want to maintain it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about that.
Not sure what it means in reality though.
In fact I plan to keep all D related development stuff going as time permits.
I don't like it either that there is no maintainer for all D related stuff.
So i guess the difference is just a formality right? (I know about adding my name into maintainers list, I already did it in a PR a few year back which was never merged fully)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You might be consulted in pull requests as a reviewer and you get emails from hydra, when the build of this compiler fails. How much time you want to spent is up to you. Being a package maintainer in nixpkgs has usually less implications compared to other linux/package distributions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds nice.
I added myself to the maintainers. Thanks.
cmake \ | ||
-DCMAKE_INSTALL_PREFIX=$out \ | ||
-DINCLUDE_INSTALL_DIR=$out/include/dlang/ldc \ | ||
.. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should not be necessary. Try to add cmake
to buildInputs
and set cmakeFlagsArray=("-DINCLUDE_INSTALL_DIR=$out/include/dlang/ldc")
in preConfigure
instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, done.
|
||
installPhase = '' | ||
make install | ||
''; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is the default of installPhase
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, done.
@Mic92 Do you happen to know what to do about the timeout on Travis? The checkPhases happen to be very long now but they are producing regular output to stdout and I haven't witnessed a stall for multiple minutes on my machines. |
4c9901e
to
4816b1a
Compare
@@ -46,7 +46,7 @@ with frameworks; with libs; { | |||
ExceptionHandling = []; | |||
FWAUserLib = []; | |||
ForceFeedback = [ CF IOKit ]; | |||
Foundation = [ CF libobjc Security ApplicationServices SystemConfiguration ]; | |||
Foundation = [ cf-private CF libobjc Security ApplicationServices SystemConfiguration ]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's been a while since I looked at this but I'm a little concerned at what this does. This may end up working, but I think it's a little hacky. "ApplicationServices" will already add cf-private as a framework and I think the reason this works is because clang will just use the first "CF" it finds (in this case cf-private). I think we need to look at just including cf-private in CF as that distinction doesn't really exist outside Nixpkgs.
/cc @copumpkin
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you're going to add it, please comment why it was needed. In a slightly more ideal world, cf-private
wouldn't really exist at all, so I want to keep track of what requires it and why (even just as a link to the other ticket).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a comment to link to this PR because in here it explains why it is needed for ldc and a further reference to the other bug exists anyway.
@ThomasMader yes, for big builds, travis is sometimes useless. There were actually plans to let hydra take over. Just ignore the build failure, we usually build manually before merging in this case. |
…oesn't include std.stdiobase.d anymore.
…ecause CoreFoundation/CFAttributedString.h could not be found. The problem appeared when building ldc on Mac OSX. See also 13778.
Ok from my side everything is finished and ready to be merged. This bug also fixes the build of dmd referenced in #28643 and a further build problem with dtools not yet detected because dmd fails to build on master. |
I'm looking forward to this fix. Might also be worth looking into using the |
Thanks, thats very valuable information. |
Thanks! I will also remove |
@Mic92 Thank you for merging. I saw that Hydra still isn't able to build the bootstrap dmd compiler. (https://hydra.nixos.org/build/61091111) The problem can be reproduced on other machines if the home directory for user root is changed to something different. e.g.: Now the question is if it is possible to fix the home directory for the root user on Hydra. I think this would be the cleaner configuration as "/root" is the default on Linux systems. |
I think |
I highly doubt that because getpwnam_r would fail for a non existing username and the assert output would be "~root". (See https://github.com/dlang/phobos/blob/v2.067.1/std/path.d#L3086) I also have nix.useSandbox = true in my /etc/nixos/configuration.nix and that should enable the sandboxing if I build with nix-build no? |
Hydra runs nixUnstable, which does provide additional sandboxing. |
Motivation for this change
I wanted to add the D programming language compiler ldc to nixpkgs.
Things done
DMD wasn't building on Linux anymore because the default compiler was switched from gcc5 to gcc6 and the bootstrap compiler doesn't seem to build with that version anymore.
Fixed by using gcc5 for the bootstrap compiler only on Linux.
dtools rdmd test wasn't successful anymore because std.stdiobase isn't available anymore.
Added ldc package which fulfills it's testsuite (except cppa.d test of dmd-testsuite because it doesn't work for now)
Added dmd-testsuite run to dmd compiler as an additional test. (except cppa.d test because it doesn't work for now)
Fixed Foundation framework in apple_sdk. (see also fatal error: 'CoreFoundation/CFAttributedString.h' file not found #13778)
The dmd testsuite uses this on OSX and it complained about not finding the header file:
(nix.useSandbox on NixOS,
or option
build-use-sandbox
innix.conf
on non-NixOS)
nix-shell -p nox --run "nox-review wip"
./result/bin/
)