alias xcbuild=$(xcode-select -p)/../SharedFrameworks/XCBuild.framework/Versions/A/Support/xcbuild
# THIS DOESNT WORK YET: xcbuild openIDEConsole # … then switch to Xcode ➡️
xcbuild showSpecs
xcbuild build <foo.pif> [—target <target>]
# Enable timings on build operations | |
defaults write com.apple.dt.Xcode ShowBuildOperationDuration -bool YES | |
# Enable extensive per-task timings | |
defaults write com.apple.dt.Xcode IDEBuildOperationTimingLogLevel -int 3 | |
# Enable old build system logging for "implicit dependencies" | |
defaults write com.apple.dt.Xcode IDEBuildOperationDependenciesLogLevel -int 3 | |
# Show logs from the "prebuild" step |
#!/bin/sh | |
set -e | |
if [ -z "${CONFIGURATION}" ]; then | |
CONFIGURATION=debug | |
fi | |
# Create the development toolchain. | |
rm -rf ~/public/swift-project/build/Ninja-ReleaseAssert/swift-dev.xctoolchain |
Oakland, CA 94602
daniel@minormatter.com
http://github.com/ddunbar
http://minormatter.com/ddunbar
My hopes for deployable artifacts:
- Packages would be able to just describe how the things they build should get laid out in a tarball.
- We would implement this as part of the build, it should be super fast (we might want to consider actually generating the tar directly for portability & control purposes).
- Packages could have control over the permissions inside the tar file (ideally without having to manipulate the permissions in the filesystem, problematic sometimes if root permission in the tar is desired).
- The mechanism would support knowing how to handle RPATH issues.
- The mechanism would know how to handle libswift* portability issues.
- The mechanism would know how to handle cross-Linux distro issues.
- Unlike below, I wouldn't expect the mechanism to handle the GIT REVISION stuff, that belongs in a separate proposal.
- The mechanism would support typical Unix-y things, like bin, lib, libexec, share.
- The mechanism could support vendored assets like other DSOs or frameworks that can't l
I have benefited greatly in my career from the help of others (and implicitly from being a white man). At this point, I would like to find more ways to contribute back to the community. I'm trying an "Office Hours" model where I spend several hours a week advising on any topic I feel competent to help with.
In general, I’m willing to help anyone who could use support in programming or software engineering. My skills are probably best suited to supporting mid-stage career software engineers, who are past the "student" phase but want help developing their skills or career (either by increasing impact or depth). I'm also happy to try my best to help people who are trying to land their first tech job.
Below is a list of areas I feel (somewhat) competent to mentor on, or at least discuss.
Enter Mac mode: | |
Hold =, press m. | |
The top four thumb keys while in Mac mode, from left to right are: Command | Option | Ctrl | Command | |
Enable Media keys: | |
Hold =, press n. If you have applied the remappings below, note that it is the *remapped* = (i.e. tab). | |
Disable key clicks: | |
Hold Progrm, press -/_ (disable beeps). | |
Hold Progrm, press |/\ (disable clicks). |
#!/bin/sh | |
set -e | |
if [ -z "${CONFIGURATION}" ]; then | |
CONFIGURATION=debug | |
fi | |
# Create the development toolchain. | |
PLATFORM_KEY=linux-x86_64 |
/// Box for exposing an item as a hashable. | |
public struct HashableBox<T, H: Hashable>: Hashable { | |
/// The wrapped item. | |
public let item: T | |
private let accessor: (T) -> H | |
/// Create a new hashable box for `item` where `accessor` defines the hashable content. | |
public init(_ item: T, accessor: @escaping (T) -> H) { | |
self.item = item |