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
