[Lldb-commits] [PATCH] D41902: Remove Platform references from the Host module

[Zachary Turner via lldb-commits]

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 <clayborg at gmail.com> wrote:

>
> > On Jan 11, 2018, at 5:12 AM, Pavel Labath <labath at 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 <jingham at 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 <jingham at 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 <jingham at 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 <zturner at google.com>
> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Wed, Jan 10, 2018 at 2:09 PM Jim Ingham <jingham at 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.
> >>>>
> >>>
> >>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20180111/8d7bf91f/attachment-0001.html>