| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
Builds a tar archive of the executable and man pages with the current
software version in the name. The version is extracted from the `main.m`
file.
|
|
|
|
This describes the syntax of the `mappings.dkmap` file.
|
|
Prevent the man page from always building even without changes to the
input file.
|
|
Include the program's launchd plist in the man page.
|
|
The release build is 1.5 Mb, while the archive is 1.1 Mb. Not sure what
additional optimisations Xcode applies when it archives, but clearly
that's the build we should be distributing.
|
|
* Remove `dome-key-map/target/debug` from Release library search paths.
This was causing the Release build to link against the debug version
of dome-key-map, resulting in a 25 Mb binary.
* Strip debug symbols
* Turn on link-time optimisation
This takes the Release binary down to 1.5 Mb.
Added an `archive` target to the Makefile. This does additional
optimisations (maybe stripping symbols?), and gives us a final binary
size of 1.1 Mb. Much better.
|
|
Split the targets into more logical sections.
|
|
We'll stick the binary and man pages in this directory for packaging.
|
|
Set 'DerivedData' path in `xcodebuild` to give us a local build
directory.
Doing this because when the 'Debug', or 'Release' directories in
'Build/Products/' don't exist, Make doesn't build our recipes. Make
seems to prefer local files, and I don't imagine the wildcard in the
path does us any favours.
When I changed the DerivedData path, I ended up with this error:
In file included from DomeKey/DomeKey/HeadphoneKey.m:9:
DomeKey/DomeKey/HeadphoneKey.h:10:9: fatal error:
'DDHidLib/DDHidAppleMikey.h' file not found
#import <DDHidLib/DDHidAppleMikey.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
Couldn't figure out what the problem was, and what changed there when I
changed the DerivedData directory. So I just fixed it in the only way I
could think of: adding the DDHidLib 'lib' directory to
`HEADER_SEARCH_PATHS` and updating the `#import` to point to the new
location.
We also create a release target in this commit, which gives us a release
build of the program.
|
|
Copy-pasted options from the `--help` output and reordered them
alphabtically.
Includes a few stub sections that I think are needed.
|
|
I want to make a Cocoa class called `Sounds`, but `Sounds.h` would
conflict with this file.
|
|
This enables us to compile the sound files into our binary.
Makefile:
Add a target to build the `sounds.h` file, by running `xxd -i` on both
sound files.
Thanks to Matteo Italia
(https://stackoverflow.com/users/214671/matteo-italia) on Stack Overflow
for describing how to use `xxd -i` to create a C array from a binary
file:
https://stackoverflow.com/questions/8707183/script-tool-to-convert-file-to-c-c-source-code-array/8707241#8707241
An to John Marshall
(https://stackoverflow.com/users/280577/john-marshall) on Stack Overflow
for showing me the Make `foreach` function:
https://stackoverflow.com/questions/7918511/make-execute-an-action-for-each-prerequisite/7921168#7921168
|
|
|
|
Now that the `--daemon` flag is required to go into daemon mode instead
of it happening automatically, add this flag to the `run` target to give
us the same behaviour we had before.
|
|
Turns out the order-only prerequisite from
8c363688ac173d34c865b8271ade8c845b67fa24 was a false lead. That just
made Make ignore the timestamp on the file and caused it to rebuild the
dependency tree correctly.
Looks like we need an actual dependency on the Rust source files in
order to get the tree working correctly. Can't just call into the
sub-make and have it work.
Change the `RUST_LIB` prerequisite to point to the actual file because
otherwise it always has the latest timestamp, causing `xcodebuild` to
run.
Unfortunately we end up with duplication between this Makefile and the
one in `dome-key-map`, but that seems unavoidable if we want to set up
the dependencies correctly.
Now it finally seems to work right.
|
|
Previously, Make would always run `xcodebuild`. I couldn't figure out
why, but after some looking around and experimenting, it looked to be
due to the `$(RUST_LIB)` prerequisite. Putting it in the order-only
dependencies list seems to fix the never-up-to-date problem.
Also use `:=` instead of `=` when defining `SOURCE_FILES`. During my
research, I came across this recommendation:
> always use := not = for shell (and wildcard, for that matter) for
> performance reasons.
From MadScientist (https://stackoverflow.com/users/939557/madscientist)
on Stack Overflow:
https://stackoverflow.com/questions/26694249/makefiles-using-wildcard-vs-find-for-specifying-source-files/26694693#26694693
Move the `DomeKey` debug product executable path into a variable and use
it as a target to clarify the build target and also allow us to
substitute the variable in the `run` task.
Now finally, `make run` won't re-build the project if no changes have
been made, it'll just run the executable.
|
|
Equivalent of Xcode's "Build & Run" action that we can execute in the
command line.
|
|
|
|
Make a sub-make target for the Rust library. We'll want to make this a
dependency of the regular DomeKey `build` target.
|
|
|
|
Planning on using this to set up build a dependency on the Rust project.
|
