Suport for libimobiledevice

[steeve]

So I made build targets for libimobiledevice, in order to use from bazel. Are you guys interested in a PR ? That would enable bazel runing on devices too.

[steeve]

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,
        ),

[keith]

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

[steeve]

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.

[keith]

FWIW I don't speak for this repo tho so it's up to others if they would accept this

[rahul-malik]

This would be awesome, please put up a PR with everything

[steeve]

@keith yes I saw, but perhaps other people will feel on carrying the torch!

[steeve]

I've opened #364.

[sergiocampama]

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.

[steeve]

@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.

[sergiocampama]

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.

[steeve]

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)

[sergiocampama]

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)

[sergiocampama]

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

[steeve]

@sergiocampama it's absolutely fine to use substitution

[keith]

Things have changed a lot since this original issue, but I think it would make sense for us to support this somehow

[steeve]

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.

[keith]

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?

[steeve]

Yes, depending on a pre-built binary was the objective at the time