I've been trying to add an Xcode project (a static library) as a dependency to another project (a framework). I've read about this issue, but I can't find what I'm looking for. Specifically, what I find is a way to add the static library binary as a dependency (in target dependencies), but this is not what I want. Instead, I have two projects configured in the same workspace. Similar to this:
(Image credits)
What I want is for the MyLib project to build when MyApp builds, if needed. I'm not just interested in adding the static library for linking. Is this possible?
Edit: I'm currently exploring the possibility of doing this using a Run Script. If possible I'd like a better alternative, though
Related
I am using this third-party view control in my project https://github.com/nicklockwood/SwipeView That project does not support CocoaPods or Carthage.
Note: my entire project is Swift and this other code is Objective-C.
To integrate this into my project I just dragged in the .h and .m files into my project.
Is this the proper approach? Instead should I have created a new target and put those files in there? Are there any considerations for me to make this choice?
I've used this technique (separate targets building static libraries) for third party code - even when that library does support CocoaPods or Carthage.
One benefit for me was when there were breaking changes, particularly with newer versions of the tool chain, before the third party code was updated. It was straightforward to disable e.g. certain newer compiler warnings in that target alone while keeping the rest of the project as clean / safe as possible.
It's also reasonably tidy when mixing Obj-C and Swift.
I haven't found a downside, as long as you're happy to manage the project integration yourself (that might otherwise be handled by CocoaPods). I only tend to have one or two third-party libraries in my macOS projects.
I'd like to create my own gradle library, that can be compiled into other projects using gradle compile statement.
Example from Picasso's README:
Download the latest JAR or grab via Gradle:
compile 'com.squareup.picasso:picasso:2.5.2'
I'm developing few applications that share common source: fragments, views, some logic... Sometimes I extend these sources while I'm developing app A, sometimes while I'm developing app B,... And I feel that copy-paste of packages/classes in Android Library Module is not an proper solution.
So I would like to setup my own library, that:
it could be easily deployed to as gradle library that could be used by compile.
I can easily develop/extend it together with currently developed application
Disclaimer: I had been googling it a lot, but without luck.
If you want to reuse a library across completely separate projects then you'll want to publish your library to repository. Assuming this is open source and you don't mind sharing, you could use JCenter, which is already added as a repository to Android projects by default.
https://www.virag.si/2015/01/publishing-gradle-android-library-to-jcenter/
Actually, question was set in the Theme of the message. But yet again,
i have Solution with 3 projects, two of whitch are Static libraries and one is Application. How my Application project could know from where to pull these .libs.
Yeh, i can do it from Linker->Input->Additional libraries, but i think there are must be other way if projects are in one solution.
There is another way, works on VS2010 and up. Right-click your EXE project, Properties, Common Properties, Framework and References. Click the Add New Reference button and select your project that generates the .lib. Repeat as necessary.
This does two things, it takes care of the Additional Dependencies linker setting, automatically adding the output of the library project. And it ensures that projects are built in the right order, normally something you'd have to with the Project Dependencies command. In your given example, with enough machine horsepower, the library projects will build concurrently. And the main project won't start building until they are both done.
I don't understand the difference between these Xcode features.
I'm building and app - but the functionality of the app is being abstracted into libraries (so they can be distributed separately as an "SDK").
So I have a workspace of library projects and the app project. I can add library projects to the app project by doing "link binary with libraries". This gives me a list of .a library projects in the current workspace which I can link to.
I can also add frameworks here.
In the "target dependencies" bit all I can add is other targets in the current project.
What I really want to do is both - I want my app project to build all the other library projects when I build it. I also want to make it verbose what libraries the app (and other libraries) depend on.
So can somebody please explain the difference, and whether what I am doing is the right way to go about it?
Many thanks!
It says here...
Drag your framework product (located in the Products folder) to the existing Link Binary With Libraries build phase of your application
target. This causes the application to link against your framework.
And...
In the General tab of the inspector window, add your framework as a dependency for the application. Adding this dependency causes Xcode to
build the framework target before building the application target.
The build dependency you establish in the application target causes
the framework to be built before the application. This is important
because it guarantees that a built version of your framework will be
available to link against and to embed in the application. Because of
this dependency, you can set the active target of your Xcode project
to your application and leave it there.
So it seems that you're supposed to use both. Seems redundant though, because if you're linking to a framework then its a dependency. I suppose you might want to only link to a library and not build it first. Although Xcode seems to build linked libraries even without them being added to the dependency section. Perhaps that's a result of the "Find Implicit Dependencies" option in a scheme's build settings.
I do something similar and was explicitly setting the 'header search path' and 'library search path' in the final executable target. However this all depended on where the objects were being generated. Initially I had set this to be within the source tree (actually a sibling directory called build), however after changing the location of the Xcode DerivedData directory and telling it to build into that directory, the projects no longer built.
The final solution was simply to remove the explicit setting of the 'header/library search path' and set the target dependencies correctly. This resulted in the project building for debugging and archiving without issue.
I have many projects that use a bunch of exact same class.
Is there a way to add a script to Xcode, so, each time i compile, he go to a network folder and update is files from there... If newer. (i do this step manually, but could be great to automate it)
Thanks
You could add a "run script" build phase to copy over files before compiling if that's really what you want to do. That would catch updates for you but I don't think it would help you if new files are added (though copying them into a location your project has a folder reference rather than a group pointing to might work).
That said I think there's a better solution. It sounds like you're reinventing a process for managing project dependencies when you could use existing tools. I would publish those shared classes as a library and add it to each project using CocoaPods and a reference to the library's git repository. That way you just need to run a pod install to get the latest version of your library. A good dependency manager gives you a clear understanding of which version of your dependencies you're currently using, control over when to update them, handles installing dependencies of your dependencies, and will avoid link errors from multiple static libraries attempting to each include a copy of the same common dependency.