Currently our project are utilising come libraries added through SPM which contains some forbidden symbols, e.g RxTest, so before uploading the build to AppStore Connect we have to remove those libraries manually in Target -> Frameworks and Libraries, but this way we cannot make the upload into an automation process.
Is there any way to configure those libraries to be embedded only in certain build configurations, e.g. Debug but not Release? Or in order to achieve the same goal, is there any command to remove specific libraries?
Related
we are getting really frustrated both financially and also in our project level. The root problem is that we have build an android library project, which uses another aar as a dependency. The clients which integrate our library have to manually include the aar and it does not work in all cases..
I can't understand why does https://bintray.com/ does not allow to publish library with added aar file inside of it? We have tried to create a same maven and even publish additional library, but client still need to include both libraries and not a single one..
Android team endorses multi module approach, so why there are no tools to easily integrate library, which has another library as a dependency?
Maybe someone had solved this issue or knows how to do what I have done?
I have a fairly large multi-project C++ solution in Visual Studio 2015. Some of the projects compile to static libraries which are used by other projects, and most of them use precompiled headers to speed up compilation. Each project also has multiple build configurations: debug, release, and several testing configurations which always build an executable to run the tests (even if the normal configurations build a static library).
When building debug and release configurations, or when doing a full rebuild, everything works well, but when doing an incremental build of a test configuration for a project that uses another project's static library, I get C2859 errors which cause the build to fail.
For example, let's say I have a project peach which builds a static library, and a project cobbler that relies on peach. The precompiled header for cobbler references only system and external libraries (no headers from inside the solution). cobbler's test configuration references peach.lib. peach.lib is created by peach's release configuration, so I have a solution configuration called cobbler-test which specifies that:
peach uses its release project configuration
cobbler uses its test project configuration.
Building cobbler-test from scratch (or rebuilding it, clean & build, etc) works fine. But if I then modify a source file called crust.cpp in cobbler and try to build, I get this error:
c:\...\cobbler\src\crust.cpp(1): error C2859: C:\...\out\cobbler-test.pdb is not the pdb file that was used when this precompiled header was created, recreate the precompiled header.
Again, this only happens when referencing a static library from the same solution that was built with a project configuration name different from the current one. With both projects using release or debug, incremental builds work fine.
Having to do a full rebuild every time defeats the purpose of using precompiled headers in the first place. Is there any way to get incremental testing configurations to work without having to resort to creating extra project configurations for every combination of projects?
My current solution to this problem is not to use testing configurations, and to create separate projects for testing projects that generate static libraries. This allows all dependent projects to use the same project configuration and allows the precompiled headers to work their magic without blowing up when doing incremental builds.
While this works fairly well for the static libraries, since they can easily be imported with #pragma comment(lib, ...), it's a bit more problematic for projects that build standalone executables. Thankfully, in my case most of those projects don't have a lot of stuff that needs testing.
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 an XCode project with 3 targets:
The application
An external build system target that builds my assets
An aggregate target that has 1 and 2 as dependencies.
The functionality that I want is:
Building the application will only build the application
Building the external build system will only build the assets
Building the aggregate will build the external build system first and then the application
Currently the aggregate builds both simultaneously which creates a race condition if the application gets to a certain point before the external build system completes. I can't add the build system as a dependecy for the application, because then building the application would do both. Is there a way to accomplish this without making a copy of my application target?
The following works for me in a similarly arranged project.
Under Build Phases -> Target Dependencies arrange the targets in the order that you want them to compile. (external build system then the application).
Second, in the Edit Scheme window for the aggregate project, under Build, uncheck Parallelize Build.
Additionally, to get the application to build only the application, you may need to uncheck Find Implicit Dependencies in the application project's build scheme.
I have a set of plugins, a plugin framework for common code and a host app. These are each in separate Xcode projects (including separate projects for each plugin). In the end, I need to be able to click build and run on the host app project to build all the plugins, the framework and host app, package them up and launch the app.
I know how to include the framework and plugins into the host app project, set up dependencies, copy actions, etc. What I am not sure about is how to include a single copy of the plugin framework in the host app for the various plugins to use rather than having a copy included in each plugin bundle.
Try weak-linking the plug-ins against the framework, copying the framework into the app's Frameworks folder, and linking, in the regular fashion, the app against that copy.
To have it automatically copy the framework to your application's bundle when the app builds, make a new "Copy Files" build phase. Drag the framework into the build phase. Then, do a Get Info on the Copy Files phase and set the Destination picker to "Frameworks".