Open steeve opened 5 years ago
Sample targets
"_idevicedebugserverproxy": attr.label(
default = "@com_github_libimobiledevice_libimobiledevice//:idevicedebugserverproxy",
cfg = "host",
executable = True,
),
"_ideviceinfo": attr.label(
default = "@com_github_libimobiledevice_libimobiledevice//:ideviceinfo",
cfg = "host",
executable = True,
),
"_ideviceimagemounter": attr.label(
default = "@com_github_libimobiledevice_libimobiledevice//:ideviceimagemounter",
cfg = "host",
executable = True,
),
"_ideviceprovision": attr.label(
default = "@com_github_libimobiledevice_libimobiledevice//:ideviceprovision",
cfg = "host",
executable = True,
),
"_ideviceinstaller": attr.label(
default = "@com_github_libimobiledevice_libimobiledevice//:ideviceinstaller",
cfg = "host",
executable = True,
),
I think this would be nice! I'm not exactly sure what the UX of this would be but bazel supports this for android so this would be nice to see work for iOS as well
I'll open a PR adding the targets as third_party
and we'll get the discussion going from there.
I also have a companion script that runs the apps inside a lldb debugging session, enabling stdout redirection and so on but it wasn't stable.
FWIW I don't speak for this repo tho so it's up to others if they would accept this
This would be awesome, please put up a PR with everything
@keith yes I saw, but perhaps other people will feel on carrying the torch!
I've opened #364.
sorry for the late reply.
I think this support brings in too many dependencies for the benefit we get. What do you all think on creating a runner interface similar to what the tests already do? This way, you could provide many different runners, think of a contrib repo with different functionalities. This way rules_apple would limit itself to the bundling of Apple targets.
This came up in a similar fashion in #225 too.
@sergiocampama that could work, what do you have in mind?
I think it would be better for those rules to live in this repo from a UX standpoint, just run your ios_application
app, it works, done. I would also put iOS on par with what mobile-install
does for Android.
Although I get the separation of concern regarding bundling and running you're rooting for.
But save for dependencies (actually, usbmuxd
isn't even required)
It would perhaps be possible to include those dependencies via another workspace command, such as what apple_support_dependencies
does.
Finally, most of the dependencies exist because libimobiledevice
is split in multiple repos, which doesn't help.
Right, I was thinking something similar to what @ob did in https://github.com/linkedin/bluepill/pull/327, this repo can be added as you mention through a WORKSPACE dependency, and then added to ios_application
through a new runner
attribute.
That looks alright! Is there any API you have in mind for that runner to work? Like, that the IPA as argv[1] or something? If you look at #364, which has a functionnal bazel run
poc, it needs a few things (like the mobileprovision file)
It'll be similar to the AppleTestRunnerInfo, in which there's a template file that accepts a substitution to the bundle or archive (depending on whether tree artifacts outputs have been enabled)
Sadly, bazel run
can't be configured to add environment variables or arguments to a script, so the substitution is the only possible path forward for now
@sergiocampama it's absolutely fine to use substitution
Things have changed a lot since this original issue, but I think it would make sense for us to support this somehow
while being widely used, it used to be that libimobiledevice wasn't maintained much. would it make sense for https://github.com/steeve/itool to replace it ? Which I made because it libimobiledevice wasn't maintained at the time.
I'm not sure we want to add a dependency on rules_go directly, but maybe we could depend on a binary from github releases?
Yes, depending on a pre-built binary was the objective at the time
So I made build targets for
libimobiledevice
, in order to use from bazel. Are you guys interested in a PR ? That would enablebazel run
ing on devices too.