CommandPost & New Build Script #3094
Comments
|
Looks like I've run into the same issue as #3043 - although I do have a Developer account. |
|
if you take a look at the
If that file exists (so it would be one directory level above the repo checkout) any values in it will override things already set in the existing On thinking about it since you filed this issue, I wonder if that Just getting the |
|
Legend, thanks! I'll test adding a |
|
That definitely did something - as I was prompted for my password for It seems to be failing on:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>destination</key>
<string>export</string>
<key>method</key>
<string>developer-id</string>
</dict>
</plist>
Any ideas? |
|
Ok, I think it has something to do with Is there something special I need to do with new extensions that I didn't have to do previously? |
|
Here's what the Archive generated from the main Hammerspoon repo looks like:
Here's what it looks like when generated from the CommandPost-App repo:
Comparing the bundles, it looks like this is the culprit:
|
|
huh, what the heck is |
|
but I will say that when you see stuff in those bundles that's going into |
|
It might be librazer.dylib - looking at that PR, the xcodeproj changes have |
|
Bingo! It seems there's a few demons in my Xcode project, haha. Whilst I've got you, it seems I can no longer do |
|
hmm, no that doesn't sound right. I'll dig into it |
|
There's still some funkiness in my Xcode project, but I can't remove any of these weird duplicates without Xcode crashing, haha:
@cmsj - I can't see any specific options in the build settings - what's required to make Sparkle work again?
|
|
hmm, Sparkle ought to be linked in automatically in a Release build |
|
I've tried using: ...but it still says: Potentially another merge issue/conflict? |
|
Ummm, nope, |
|
There's also no Sparkle in the Frameworks folder after building, so something is preventing it from copying over. |
|
I just had a look at if [[ "$CONFIGURATION" == "Release" ]]; then
install_framework "${PODS_ROOT}/Sparkle/Sparkle.framework"
fi...so I think the problem is that I need the build scheme and build configuration to be "Release". However, when I try this: I now just get a lot of errors like: Any ideas what I'm misunderstanding @cmsj ? |
|
Hmm, it could be LuaSkin at fault here - its |
|
Also, whilst I've got you... where's the right place to set |
|
At the moment, they're environment variables that |
|
After a bit of mucking around, CommandPost now finally builds with Sparkle! Woohoo! I think a lot of the issues were simply due to the fact there were a bunch of extensions I originally had in CommandPost before they came to Hammerspoon (i.e. Next step is to bring back the functionality to build our uninstall tool, and build/sign/notarise the DMG. I also need to test Sentry, and make sure that side all works. I'm currently using the commercial tool DMG Canvas for the DMG creation, but it's probably overkill for what I need, and I could achieve the same thing with something like create-dmg. I wonder if this is worth building into Hammerspoon's build script, or if it should just be something specific for CommandPost? I realise Hammerspoon doesn't use a DMG, but it could be useful for other potential forks? Thanks for all your help @cmsj ! |
|
@cmsj - Even if you don't want to add DMG support to the Hammerspoon build script, one thing that would be handy would be to add an argument to allow you to notarise the DMG file as opposed to the |
|
I am completely happy for our build system to support DMG. I don't plan on using it, but it'll be less work for CP if you're not carrying that stuff as a patch 🙂 |
|
@cmsj - I finally got around to tweaking our CommandPost build script so that it actually works: https://github.com/CommandPost/CommandPost/blob/develop/scripts/build_commandpost_release.sh Currently I'm doing all the notarisation stuff in the above script (as opposed to using your awesome Hammerspoon build script) - because it's looking for the Any suggestions on the best way to use your existing notarisation functions to notarise my |
|
@latenitefilms check out #3142 - it adds a new argument for the I think the DMG/Uninstall stuff should probably stay in your script, particularly since the DMG stuff uses a third party tool, and the appcast generation is different because you use DSA keys and we don't. I wouldn't necessarily be opposed to adding that to our appcast though, so we're even closer. |
|
Thanks so much! Will test it out later today. Are you able to merge into "master"? Totally agree with DMG/Uninstall stuff. Currently I'm still just using the commercial tool DMG Canvas for the DMG creation, however it should be easy enough to swap out with create-dmg at some point - and then it's possible we could add to the Hammerspoon build script. I haven't yet played with GitHub Actions, and I currently just update the AppCast manually - but eventually I'd like to basically duplicate everything you've automated in Hammerpoon. Regarding DSA keys:
|
|
Trying out the new build process so I can finally start contributing again (I think I need to rewrite my proposed changes to axuielement and spaces from scratch as an attempt to merge them caused a bunch of conflicts... figured it was best to start from a known good build)... Looking at Also, do I need to worry about notarization with Development builds? And if so, what's the process -- never done that before. Oh and do I need to do anything special regarding entitlements? |
|
I'll leave @cmsj to answer the specifics incase I say anything wrong, but in the meantime, AFAIK, you should be able to compile Hammerspoon in Xcode now without any special tricks or requirements. |
|
@cmsj - As mentioned on IRC before I had to jump offline...
|
|
@latenitefilms I think probably the best option here would be if I refactor the dSYM upload into its own command, with a default path so you can call it twice, once with the default (xccarchive) path and then a second time with wherever your dSYMs are. |
|
Thinking about it further, I wonder if I should remove all the Obj-C extensions from our CommandPost repo and actually import them into Xcode in our CommandPost-App repo? That might make it easier to track down bugs/issues? The only reason I avoided doing this is the potential for complicated Xcode project merge conflicts, but as there's already some extensions in CommandPost but not Hammerspoon (ie OSC) that's probably a redundant argument now anyway. Will have a play today. |
|
Whilst you're online @asmagill - do you have any thoughts/opinions on me bringing across your extensions (i.e. touchbar, touchdevice, cfpreferences, text) directly into our CommandPost-App repo? I started doing it today just to see if it'll work - but it requires a LOT of tweaks/changes/renaming because of the new way Hammerspoon extensions are structured. Thoughts? |
|
Hmm, yeah, the new arrangement (now that I can build the core application) does change things a bit... I'm going to have to play with this a bit and give it some thought... |
|
Currently I'm using:
What are you thoughts on merging
I started doing this in this branch: ...but run into some issues getting everything to build, then the Xcode project got corrupt somehow, so I need to re-add all these extension to our CommandPost-App Xcode project to see if I can actually get it to build. |
|
@cmsj so if I'm understanding the new organization correctly, for a given module:
We should probably add |
|
That sounds right to me. Also note: https://github.com/Hammerspoon/hammerspoon/blob/master/Hammerspoon/setup.lua#L9 |
|
Ok, so submodules aren't compiled into the same file as the module itself but as |
|
Correct, although I'm ASSUMING that the inconsistency in the naming isn't deliberate, and just a side-effect of trying to update all the legacy extensions. Personally, I prefer the ones that are named |
|
K well I want to take a crack at my axuielement updates (which IIRC was mostly to the lua, so should be easy) and spaces additions so I can formally retire |
|
Amazing - thanks so much @asmagill ! Great to see you back on GitHub! Hope all is well on the other side of the world! |
|
@asmagill yeah I didn't do a great job with the consistency of sub modules. The good news is that we can fix them without anyone noticing, because they're all hidden behind package.preload in setup.lua |
Now that I've had a proper play, I think that whilst long term, it would be great to move all the Objective-C stuff from our CommandPost repo into our CommandPost-App (Hammerspoon Fork) repo - it's probably best/safest to wait until @asmagill brings stuff into the Hammerspoon master, rather than try hack it together myself - or at least, I might try bring across some extensions that'll never make it into Hammerspoon (i.e. Given this, it would be really handy to have the dSYM upload in its own command if that's ok? |
|
It's probably because I generally don't use Xcode directly and am mostly self taught, but I'm not sure I understand what you mean by "have the dSYM upload in its own command"... can you clarify? |
|
Oh, sorry, that was specifically for @cmsj - basically I need a new way to upload the dSYM from your extensions to Sentry as part of CommandPost-App’s build process. |
|
Ok, I wondered (hoped, actually) if you were talking about a way to have the dSYM data embedded in the libraries themselves instead of as separate directories... I'd prefer that if I knew how to do it because (1) I think the extra directories are ugly, and (2) making a universal one is a really ugly hack. |
|
@cmsj, is there a reason why none of the dylib's in I ask because it's making it hard for me to update my generic Makefile so that I can easily create modules which can then be slotted into Hammerspoon itself once they're ready for inclusion with minimal changes when adding them to the Xcode workspace. It would be easier on my end if source file names and the dylib file names matched (with the exception of the file extension, of course). Objections if I go ahead and do this (not necessarily all at once, but at this time specifically for Hmm... looks like its inheriting it from the target (sub)project name and we've been naming those without underscores. Not sure if hardcoding a change will be a problem or not, I'll run some tests. |
|
Ok, this is a new one: I haven't touched the pods in any way shape or form... suggestions? |
|
Do you have Maybe try Here's where it's tripping up for reference: function assert_cocoapods_state() {
echo "Checking Cocoapods state..."
pushd "${HAMMERSPOON_HOME}" >/dev/null || fail "Unable to enter ${HAMMERSPOON_HOME}"
if ! pod outdated >/dev/null 2>&1 ; then
fail "cocoapods installation does not seem sane"
fi
popd >/dev/null || fail "Unknown"
} |
|
It had worked before and is working now... I'm guessing some sort of transient network error since |
|
@latenitefilms I'm hoping to work on xml and text this weekend. Re the xml module, I've not tested it much myself -- the few xml files I've needed to work with were actually more easily handled with a simplified parser I was able to write in pure lua. Are the files you're working with somewhere that I can use them in my tests? It would be nice to have something more challenging than a Roku's web interface to parse and see where the benefits of using the macOS XML classes can pay off. |
|
Here's a bunch of random FCPXML's you can play with: https://latenitefilms.digitalpigeon.com/msg/yK3CQKaDEeyh9QZr2s64yQ/8ZQu8wkG-H3x_lMnr3T7LQ If you want to see how we're currently using the XML module if you download this repo and search for |
|
@cmsj - Any ideas why I'm now seeing these errors? AFAIK nothing has changed recently in
|
|
Ok, I tried to just ignore those two lines using:
...but now I'm getting:
...if I ignore that too it builds:
|
|
Also, whilst I've got you @cmsj - this is my current (temporary) workaround for the other files for Sentry:
There could probably just be an extra variable to load one more extra path for files for Sentry to upload, which enables this line - keep things simple? |
|
new build errors are handled by #3159 |
|
I'm going to close this issue for now. My Sentry workaround above is good enough for now. Thanks team!! |
Ok @cmsj, the time has come for me to finally work out how I can build CommandPost again!
I'm currently getting stuck on:
...when running:
Any ideas?
The text was updated successfully, but these errors were encountered: