I suppose this is fine. I think a logical alternative would be to use <src>
and have plugman know that .a means add it to your linker flags. It's not a
framework (since it doesn't have a .framework extension), so the name is a
bit confusing.



On Mon, Aug 26, 2013 at 3:57 AM, Shazron <[email protected]> wrote:

> I'm the culprit behind the request for source-file framework=true :)
>
> This was started in the pre-3.0.0 days, and is still a concern in 3.0.0.
> For example look at this plugin:
> https://github.com/shazron/TestFlightPlugin/blob/master/plugin.xml
>
> The libTestFlight.a file is a file that needs to be copied over
> (<source-file>), and also installed in the "Link Binary with Libraries"
> section (<framework>. It cannot be added as just a <framework> because that
> just adds it to "Link Binary with Libraries" (this is mainly for System
> frameworks, e.g CoreMedia.framework).
>
>
>
>
>
>
> On Thu, Aug 15, 2013 at 4:37 AM, Andrew Grieve <[email protected]>
> wrote:
>
> > #1 <lib-file> == dynamically linked libs that exist in your plugin ==
> .so,
> > .dll, .dylib, .jar
> > #2 <framework> == dynamically linked libs provided by the OS == .so,
> .dll,
> > .dylib, .framework
> > #3 <src> == precompiled object file / lib that exists in you plugins ==
> .a,
> > .o
> > #4 <src framework="true"> == ???... Might refer to the fake .framework
> > files that some iOS projects distribute (that have .a in them instead of
> > .dylib). Example might just be wrong (should say .framework not .a)
> >
> > so... I think all four do different things, but maybe we can coalesce
> them
> > better?
> >
> > e.g. we could have have framework=true be unnecessary by just looking at
> > the file extension.
> > Not sure about a sane way to combine the others... Maybe add a section to
> > the docs that highlights the differences?
> >
> >
> > On Wed, Aug 14, 2013 at 3:53 PM, Michal Mocny <[email protected]>
> wrote:
> >
> > > I would think it will be more confusing to use the same tag name that
> > does
> > > something different depending on which platform its used on, so I'de
> vote
> > > to leave them specific and not try to unify.
> > >
> > > I do think thats its hard to tell which tag applies to which platform,
> so
> > > perhaps a platform prefix or platform attribute that is verified by a
> > > schema (ie, <framework platform=ios ...>, <lib-file platform=bb10 ...>)
> > >
> > > Not sure about the sourrce-file framework=true issue, but that sounds
> > > confusing :)
> > >
> > >
> > > On Wed, Aug 14, 2013 at 3:41 PM, Filip Maj <[email protected]> wrote:
> > >
> > > > Hey all,
> > > >
> > > > There's an issue filed for plugman [1], wherein a user had an issue
> > > > authoring a plugin.xml file for a plugin and got tripped up with
> > > > <framework> [2] and <lib-file> [3] support on different platforms.
> > > >
> > > > Currently: <framework> only applies to iOS. <lib-file> only for BB10.
> > To
> > > > confuse matters further, we also support <source-file> elements with
> a
> > > > framework=true attribute (that is iOS-only).
> > > >
> > > > :)
> > > >
> > > > Any ideas on how to consolidate all this stuff? How to make this
> > > > specification clearer/more readable/more intuitive?
> > > >
> > > > [1] https://issues.apache.org/jira/browse/CB-4430
> > > > [2]
> > > >
> > >
> >
> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html#Plugin%20Sp
> > > > ecification_framework
> > > > [3]
> > > >
> > >
> >
> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html#Plugin%20Sp
> > > > ecification_lib_file
> > > > [4]
> > > >
> > >
> >
> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html#Plugin%20Sp
> > > > ecification_source_file
> > > >
> > > >
> > >
> >
>

Reply via email to