The darwinbuild update everyone needed to support 10.12+ including Big Sur. #142
Conversation
tag is never None, since it has a proper default value set.
This script aids in running codesign over the build artifacts output by a darwinbuild run (because codesigning inside the chroot is not possible).
Attempting to sign during xcodebuild when building in the chroot will break the build every time.
This change makes it possible to sign the output of a Travis CI build, which does not create a local darwinbuild Roots/SourceCache combo.
Also disabled the deprecated ALWAYS_SEARCH_USER_PATHS setting.
This also works inside the chroot.
This helps ensure that inner nested bundles get signed before outer ones, as Apple's documentation states is required.
Documentation
This messes up the receipt-based mechanism for detecting if the installed roots are up-to-date, because the receipt files aren't aware of the per-project binary directories.
This will no longer produce spurious warnings in Xcode (caused by the use of the now-broken ADDITIONAL_SDKS build setting), as well as greatly simplify the process used to locate the installed roots.
This exposes a bug in xcodebuild. Radar 45060216.
These aren't useful outside of darwinbuild itself. All they do is clutter the installation.
Doing so requires that I reinstall Xcode. That's bad.
rm -f directory/ will cause rm to exit with an error, even if -f is passed. We need to ignore this error manually.
This has bugged me for a long time.
This fixes copying of framework bundles, which contain several internal symlinks that must be preserved.
This is necessary to ensure that the internal symbolic links inside frameworks are created correctly.
What 'ls' couldn't do can be done with 'find'
`exec find` causes darwinbuild to stop after running the find command. This is not useful. Also added `-H` flag to ensure that the receipts are still read even if the receipts directory itself is a symlink.
Fix ugly perl dependancy
There was a problem hiding this comment.
This commit (ff1c173) would make it harder for MacPorts to update darwinbuild, as it still needs to support older systems: see: https://trac.macports.org/ticket/60817
Edit: darn it, I meant for this to be a comment on just one single commit, not the pull request as a whole...
|
Why do we really need to break something for older systems? :) I would rather have Darwinbuild working for PPC – that may help to rebuild components for 10.6 PPC using newer sources (borrowed from later developer builds and 10.6.x releases). |
Yeah I agree that breaking things for older systems would be bad; I see @wjk has been a bit active lately; I wonder if he has any input? |
|
Ideally we would like to fix |
|
@cooljeanius PureDarwin has not used darwinbuild in a very long time. It was extremely clunky. I eventually decided that it was more problem than help, so I decided to move to CMake. I believe that the source repository for this PR is archived. If you would like to continue this PR, I am fine with that, but I will be focusing on our current build system. Thanks! |
|
@wjk Would CMake work for building older OS sources? (I mean, it does work for sure as such, but I have never tried to use it to build OS components.) |
|
Only if you port the build system from Xcode to CMake. I have extensively edited every Apple project in PureDarwin to make it work with CMake. This process is ongoing. |
|
@wjk That may actually make supporting older OS and PowerPC easier. Adding an extra arch in CMake is often trivial. |
|
Guys, I think a better approach here might be to create a new PR for some branches that cherry-pick and update the commits in a more carefully curated way. I've been working on that every now and then, but haven't pushed any of it it. You might check my fork and a few others for some updates also. But some of the original commits in this PR do things like accidentally commit things (like user-specific xcode preferences), then additional commits to remove them, changes one way and back, fix spelling errors, etc, and those should probably be eliminated and cleaned up. Additionally as was mentioned, it'd probably be a good idea to not introduce new dependencies (Swift) if at all possible. Backward compatibility all the way back to the beginning would be ideal as well. Where such things cannot be achieved, we should probably create some tags at points where future commits will break older OS builds. I'm not sure you guys want to go to CMake for older things unless you are ok with diverging more significantly from the released Apple source. No problem with that, but that effort probably shouldn't be associated with DarwinBuild as it'll be a completely different architecture. One of the things that DarwinBuild did is build the source in a way that was substantially similar to the way it was built inside Apple. You can see artifacts of this if you run It would also be nice if we could get ahold of someone at Apple who might be willing to turn the macosforge/darwinbuild repo over to the community. |
Clang does not support PowerPC macOS. I tried exactly that once and it caused the compiler to crash (assertion failure) stating that support for that platform has been removed. I think I did not make what I was trying to say above clear enough: I choose to be no longer involved in the darwinbuild project at all. It is something I am no longer maintaining. I provide no support for it. That’s why I archived the repo under the PureDarwin org. If you want to continue this PR, I’m OK with that, but please stop pinging me. |
|
@wjk, understood, but you will have to take some action to not get a notification any time someone replies to this PR. I'm not entirely sure how you can do that short of retracting your commits, but surely there is a way. It would be preferred if you don't retract your commits however, as they are valuable for starting points to backport some of the functionality to older OS releases. Thank you. |
|
@bhuntsman Unfortunately, My primary interest here is rebuilding components of 10.6.x to update 10A190 build (the last 10.6 to run natively on PPC), bringing it closer to 10.6.8 to an extent feasible. |
|
@wjk Clang is broken indeed, but we do not need it. GCC works fine on PowerPC, including gcc12 (which I use daily) and gcc13 (tested a few months ago, moving to it as a main compiler on PPC soon). |
|
@barracuda156, if you clone the source for DarwinBuild, without any 3rd-party PR's or changes, it doesn't work on 10.5 on PPC? My old PPC build box has a working DarwinBuild, but I forget how current on commits it is. I can check it later. Can you post what isn't currently working on PPC? But preferably, do so as an Issue please, as that is a problem that is not addressed by this PR. |
|
@bhuntsman Yes, sure, I will open an issue tomorrow. I have only tried building It would be great if we can fix this (and hopefully add support for older systems, so that the same version can be used). |
|
I contend that it is not broken as-is until you try to get to 10.7 or so. I've never used the MacPorts version and I know they made some changes. Best to build it from source from here, and just apply your own patches here and there. I have a private version that works on Mojave also, generally there's not too many changes needed to just get a quick-and-dirty build. |
Add support for building and using a custom SDK
|
@bhuntsman Considering that we got 10.6.8 running on PowerPC, I may return to this. Some OS components need to be rebuilt, it could be easier to do via DarwinBuild (provided it is fixable) than via MacPorts (where I need to write from scratch, since it does not have streamlined functionality of this kind). |
7 participants
This darwinbuild pull request created by PureDarwin is a major change to the functionality of the program to include built-in Github support for package automation when using the correct plist configurations.
By submitting a request, you represent that you have the right to license
your contribution to the community, and agree that your contributions are
licensed under the BSD License accompanying darwinbuild.
For existing files modified by your request, you represent that you have
retained any existing copyright notices and licensing terms. For each new
file in your request, you represent that you have added to the file a
copyright notice (including the year and the copyright owner's name) and
darwinbuild's licensing terms.