cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Santana <csantan...@gmail.com>
Subject Re: [ios/osx] Adding framework/library as framework subproject
Date Mon, 21 Sep 2015 05:05:29 GMT
HI Tobias having a .framework should work.
If you are having problems please open an issue, it might be just a doc
problem

How are you publishing your plugin to npm registry?

Does the plugin installs correctly if if you install "cordova plugin add
<folder>" from a folder ?
And it doesn't work if you install by fetching from npm registry? "cordova
plugin add <npm-pkg-name>"?

I think the problem is the way you packaged your npm package to the
registry you loosed your symlinks inside the .framework.

I think the last advice in this mailing list was, to first created a tgz
from the content of your plugin first,
Then pass the tgz which should capture the symlinks inside, pass to npm
with npm publish <tarball>
Don't do npm publish <folder>



On Sun, Sep 20, 2015 at 11:50 PM Tobias Bocanegra <tripod@apache.org> wrote:

> Hi Carlos,
>
> thanks for the solutions, see my remarks inline.
>
> On Sun, Sep 20, 2015 at 11:07 AM, Carlos Santana <csantana23@gmail.com>
> wrote:
> > Hi Tobias
> >   You should be able to achieve what you want today.
> > I have done it here in some our project's.
> >
> > Today you should be able to include and distribute a library inside a
> > plugin.
> > 1) Best choice is to compile and package your library as a .framework
> > here is sample on how to specify:
> > <framework src="src/ios/WorklightSDK/Frameworks/sqlcipher.framework"
> > custom="true" />
> >
> > Distributing a framework is better than a static lib, it allows better
> > flexibility and better handle for different architectures
>
> That's what I have today - but I had problems with the symlinks (from
> Versions/Current -> Versions/A) and with npm. I also had problems with
> codesigning - although it works, the codesign -verify complains.
>
> >
> > 2) Second choice will be compile and package your library as a static lib
> > SomethingLib.a
> > <source-file src="src/ios/WorklightSDK/libWorklightStaticLibProject.a"
> > compiler-flags="-Obj-C" framework="true" />
>
> that would have been my fallback.
>
> >
> > This is is an old example, we moved away from static libs, and now using
> > .framework for everything
>
> >
> > 3) Third choice is to distribute your source code by itself .h and .m
> > You can see any of the core cordova plugins (i.e. camera, contacts)
> >
> > No need to distribute you .xcodeproj if you can do it with one of these 3
> > options
>
> yes. but my lib has 40 files...this gives a rather big plugin.xml.
> however, having the .xcodeproj also makes it easier for development.
>
> >
> > If you are having trouble getting this done today, please open a JIRA
> issue
> > to see how can we fix it.
> >
> > Distributing a .xcodeproj it can be a bit complex, and we know we package
> > CordovaLib as xcodeproj :-).
> >
> > Today cordova doesn't support workspaces, that's plan for cordova-ios@5
> [1]
> > I think after cordova supports workspaces will be easier to manage
> multiple
> > xcodeprojects inside a single workspace, to able to compile a target
> > resolving all dependencies within the workspace.
>
> that would be cool.
> >
> > At work we are looking closely at workspaces, after this is done then we
> > can see how can distribute our native ios code (i.e. in source code) once
> > to cococapods, and then have a cordova plugin depend on it [2].
> >
> > Maybe all this doesn't cover your exact use case, so maybe you can open a
> > enhancement lira item, and put some seudo code there on what exactly you
> > want to achieve.
> >
> > I know Windows supported the attribute type="projectReference" [3] for
> the
> > <framework> element, the tricky part with ios is dealing with
> dependencies
> > conflicts of other puglins, and the user's own code.
>
> I don't think it is too complicated. If I compare the pbxproj before
> and after I add my library manually,
> it only has a few additions. adding the project to the frameworks is
> already handled - the only thing missing is copying the sources and
> adding the proxy target to the link section. I will look into it when
> I get some spare time.
>
> >
> > In terms of copying files that you can't do with <assets> or
> > <resource-file> you can use a plugin hook, do it there at plugin install
> > event. we have done this also at work.
>
> ok. I'll try this as well.
> thanks alot.
>
> regards, toby
>
> >
> > [1]: https://issues.apache.org/jira/browse/CB-5921
> > [2]: https://issues.apache.org/jira/browse/CB-7942
> > [3]:
> >
> http://cordova.apache.org/docs/en/edge/plugin_ref_spec.md.html#Plugin%20Specification_framework_element
> >
> > -- Carlos
> >
> > On Sat, Sep 19, 2015 at 4:38 PM Anis KADRI <anis.kadri@gmail.com> wrote:
> >
> >> The library that we use (node-xcode) supports: System Frameworks, Custom
> >> Frameworks (ones you would drag&drop into your project) and static
> >> libraries. It does not support XCode subprojects as far as I know.
> >> If you want to add support for it, you're more than welcome. Repository
> is
> >> right here: https://github.com/alunny/node-xcode
> >>
> >> Anis
> >>
> >> On Fri, Sep 18, 2015 at 11:14 PM Tobias Bocanegra <tripod@apache.org>
> >> wrote:
> >>
> >> > Hi,
> >> >
> >> > I want to add a plugin to a ios/osx project. the plugin contains a
> >> > .xcodeproj of a static library, incuding the sources. I want to avoid
> >> > distributing the binary .a in the plugin.
> >> >
> >> > I tried various ways of how to specify this library, with <framework>
> >> > with <src framework=true> etc. but it never adds the lib.a to the
> >> > linker section in build phases.
> >> >
> >> > looking at the pbxproj, it looks like it would have to specify a proxy
> >> > reference to the library project. which is a bit more complex than
> >> > just add the framwork reference.
> >> >
> >> > Is this something that would be desired by others? If so, I can try to
> >> > improve the plugman script to deal property with the library.
> >> >
> >> > the 2nd problem is, that xcode usually has the sources beside the
> >> > xcodeproj. so for example:
> >> >
> >> > mylib.xcodeprj/
> >> > mylib/
> >> >
> >> > but there is no tag to copy an entire directory. using the <framework>
> >> > tag also for the sources, would embed it to the frameworks section,
> >> > which is also wrong.
> >> >
> >> > ideally we would be able to specify the source directory, like
> >> >
> >> > <framework src="frameworks/osx/mylib.xcodeproj" custom="true"
> >> > sources="frameworks/osx/mylib" />
> >> >
> >> > OR
> >> >
> >> > add a new sub-project tag, like:
> >> >
> >> > <sub-project src="frameworks/osx/mylib"
> >> > project="frameworks/osx/mylib.xcodeproj" framework="true"
> >> > link-targets="libMyLib.a" />
> >> >
> >> > WDYT?
> >> >
> >> > Regards, Toby
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> > For additional commands, e-mail: dev-help@cordova.apache.org
> >> >
> >> >
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message