extensions rebuild on every build or run about hammerspoon HOT 7 CLOSED

I'm very seriously considering changing entirely how extensions are built, to move them into Xcode. Not because the build speed is slow, but because I've added Crashlytics and all of our crash reports will be useless because they're happening inside an unsymbolicated "internal.so".
I'm not an expert at these things, but it looks like the easiest option would be to have an xcode project per extension, which spits out something like libFOO.dylib and foo.lua, then modify the package paths to look for .dylib instead of .so.

Before I sink a bunch of time into figuring out how to go about producing a working app that requires no changes in init.lua behaviour, what do folk like @asmagill @Habbie @josephholsten and @jhgg think about this?

from hammerspoon.

+1 to better metrics

from hammerspoon.

While I'm all for better metrics and better debug options, how much does this change the development path of a specific module? When I'm tweaking and refining something and rebuilding 20 times in an hour to get something ready, the overhead of Xcode, even xcodebuild, would be annoying... but if it could be more automated, like a wrapper that I can just drop my files into (maybe a few more steps, but simple) once I'm ready to make it public, then I see no reason not to do so, especially for modules that make it into core.

On Dec 30, 2014, at 7:44 PM, Joseph Anthony Pasquale Holsten [email protected] wrote:

+1 to better metrics

—
Reply to this email directly or view it on GitHub #49 (comment).

from hammerspoon.

@asmagil one option would be to use gyp to generate the Xcode project files. We could also continue to support building via a Makefile I would think.
The answer really is, I don't know because I haven't yet done any work to see how this would have to be done. My hope is that it's just an administrative change and a module wouldn't need any code changes to switch between .so and .dylib.

from hammerspoon.

Managed to figure out a way to get debug symbols into Crashlytics without having to change how extensions are built, significantly. As such, I'm not going to continue trying to get the extensions built as dylib bundles.
I wouldn't object to it if someone else wants to do it, but I no longer have a compelling reason to :)

from hammerspoon.

Just for reference: I did a prototype transition to gyp as build system here:
https://github.com/mgee/hammerspoon/tree/gyp
In this branch gyp is used to generate Xcode projects for Hammerspoon and all extensions.
Note that this branch is not up-to-date with Hammerspoon/master.

from hammerspoon.

This was closed by #468

from hammerspoon.