In that case I think Platform should implement all the logic it needs in itself, instead of relying Host to callback into it.
I think the point of this patch is to separate dependencies, so Platform should be able to depend on Host, but not vice versa. On Thu, Jan 11, 2018 at 8:05 AM Greg Clayton <clayb...@gmail.com> wrote: > > > On Jan 11, 2018, at 5:12 AM, Pavel Labath <lab...@google.com> wrote: > > > > Thanks for adding the test Jim. I have confirmed that it passes with > > this patch applied (because the bundle is resolved during target > > creating, not launching). > > > > However, this did make me aware of the fact that this patch removed > > the bundle resolution logic from the launcher itself, so I'm going to > > add back that part. > > The platform really does need a part in this. Each platform might have > different files. APK files for Android, .ipa files for iTunes, .app bundles > for all darwin operating systems and more. So the platform really is the > right place for this kind of logic. > > > > > On 10 January 2018 at 23:35, Jim Ingham <jing...@apple.com> wrote: > >> Eh, no, that wasn't right. I don't know how to build and link a mach-o > binary on some random other system. So I made this a Darwin only test till > I can figure out how to do that. > >> > >> Jim > >> > >> > >>> On Jan 10, 2018, at 3:09 PM, Jim Ingham <jing...@apple.com> wrote: > >>> > >>> I added a simple test: macosx/find-app-in-bundle. On non-Darwin > systems it just ensures we find the app in the > >>> app bundle and can set a breakpoint in it. On Darwin, it also ensures > we can launch the app and hit our breakpoint. > >>> > >>> When I get a chance I'll add an iOS app bundle and make a tricky one > with a renamed executable. > >>> > >>> Jim > >>> > >>> > >>>> On Jan 10, 2018, at 2:27 PM, Jim Ingham <jing...@apple.com> wrote: > >>>> > >>>> App bundles are "just directories" but they are actually different on > iOS & OS X. The most interesting part of them is a plist that gives some > information about the bundle. lldb reads that plist to figure out what the > real executable is (it is usually the bundle name minus the .app, but it > doesn't have to be.) So you have to get the plist right, you can't just > pretend the directory is an app bundle. > >>>> > >>>> I don't know if there's anything in llvm to make these, in general > Xcode does the job of laying out the bundle, so I would be surprised if it > has anything along these lines. > >>>> > >>>> I'll add a test that makes a simple app wrapper for darwin and makes > sure we can read from it. We do something similar for Frameworks (another > kind of bundle) in the macosx/add-dsym tests. It's pretty easy to do. > >>>> > >>>> Jim > >>>> > >>>> > >>>> > >>>> > >>>>> On Jan 10, 2018, at 2:18 PM, Zachary Turner <ztur...@google.com> > wrote: > >>>>> > >>>>> > >>>>> > >>>>> On Wed, Jan 10, 2018 at 2:09 PM Jim Ingham <jing...@apple.com> > wrote: > >>>>> The only hard part of writing any kind of test for this is actually > getting a legitimate .app into the testsuite. Doesn't seem fair to ask > Pavel to do that, since he doesn't work on macOS... > >>>>> > >>>>> Jim > >>>>> > >>>>> What exactly *is* a .app file on disk? Is it literally just a > directory? If so then the test can simply create the directory. Or is it > more like "a directory that's actually compressed into a single file, sorta > like a zip file, but using a different format"? > >>>>> > >>>>> If it's the latter, it would be nice if we had an llvm tool that > could create them. As a fallback, perhaps the lldb-test tool could be > given a command line option like --treat-as-bundle, where it pretends an > existing directory is actually a bundle, so that the tests would work > without one. > >>>> > >>> > >> > >
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
