I am faced with warning that actually does nothing for me in this case, but is a bit anoying.
The project is combined with several subprojects via Cocoapods, so the structure is
Root folder
Main project (that combines all the others and is used to deliver the build to the end-users. Imports Subproject 1, Subproject
2, Core)
Subproject 1 (dependent on Core, imports it via Podfile)
Subproject 2 (dependent on Core, imports it via Podfile)
Core project (independent)
Module.podspec (describes subspecs, let's assume it declares the name of the framework - Module)
The development happens in Subproject 1/2, and to use some Core classes I need to import Module to the swift file. And it works fine. Because the development happens in the project directly and Cocoapods assembles Module.framework based on Podfile imports and Module.podspec
But when I am building the project from Main project - the Subproject 1/2 and Core are all in the Module.framework. Thus, the xCode displays warning:
⚠️ File 'FileFromOtherSubModule.swift' is part of module
'Module'; ignoring import
Is there any way to handle it? I haven't found such a warning in clang flags
Related
I am developing a SDK and use SPM to modularise my code. All code is written in Swift.
My project structure is like this:
SampleApp (Workspace) -> SDK (SPM) -> ModuleA (SPM)
I can build and run the sample app locally successfully.
Now I want to archive/build the SDK package into a dynamic xcframework that my other clients can just drag and drop into their Xcode to consume.
I'm using xcodebuild -create-xcframework for that purpose and can successfully build a sdk.xcframework file.
But in a separated sample app where I embed the sdk.xcframework there, when import SDK module, I get this error
No such module 'ModuleA'
Failed to build module 'SDK' for importation due to the errors above; the textual interface may be broken by project issues or a compiler bug
I assume here, this is because the compiler can't find ModuleA
Is there anyway that I can bundle the ModuleA into sdk.xcframework statically, so that my clients can just drag only sdk.xcframework into their projects to consume the SDK module?
The question is pretty much: How can I bundle ModuleA and SDK into a single .xcframework for distribution
My project is separated on multiple parts:
* core project
* utils (as example) project
Both of them have some unit-tests, and "core project" relies on code in "utils" project by "dependsOn" mechanism of sbt.
I am using sbt-assembly plugin for building "uber-jar"/"fat-jar", but sbt assembly task does`t run test on utils project - which is what I am trying to achieve (I can not see any tests from "utils project" in logs)
Changing "dependsOn" to "aggregate" introduce new problem:
sbt assembly aggregate deduplicate
something similar to this issue-on-github
So my question is how to organize multimodule project which can be assembled by sbt-assembly and all of the tests are executed during assembly task?
My guess is that you should have both dependsOn and aggregate relationships between your subprojects. They are not mutually exclusive, only serve different purposes.
DependsOn introduces code dependency, so if core depends on utils it means that you can reference types from utils in core.
Aggregate introduces task dependency. That means if you execute compile or test on core and it aggregates utils then the task will be executed on both subprojects.
Problems with deduplicate are another beast - it means, that there are duplicates in resources or classes when attempting to create one jar. The reasons for this may be various and you can tackle them by verifying the library dependencies in the build or creating MergeStrategy - https://github.com/sbt/sbt-assembly#merge-strategy
I have workspace contains subprojects and one of the subproject generates static lib which is linked to main project. I have created a swift in static lib subproject and I get below build error.
library not found for -lswiftCoreFoundation for architecture x86_64
Solution: Add one .swift file to application target and it works
Our project features a kind of adhoc "plugin" that reads csv files and stuffs the contents into a database.
This code is defined in /project/DataMigrate.scala
We had our own poorly implemented version of a CSV parser that isn't up to the task anymore so I tried to add this https://github.com/tototoshi/scala-csv to the libraryDependencies in /project/Build.scala but that did not make it importable from DataMigrate.scala. I also tried putting the library dependency in /project/build.sbt as I read something about "Build definition of a build definition", but that did not seem to help either.
Is it at all possible to add dependencies for code that lives in /project?
SBT is recursive, so just as you can define dependencies and settings of the actual project in [something].sbt or project/[something].scala you can define dependencies and settings of the projects project (any ad hoc plugins etc) in project/[something].sbt or project/project/[something].scala
How can I include generated source files when my Play routes and views are compiled?
My Play 2.3 application uses a plugin that generates source files under a sourceManaged subdir (target/scala-2.11/src_managed/main/subdir). These source files include controllers and models that are referenced in my routes files and views. But when I compile my application, I get errors like this:
[error] myapp/conf/routes:14: object Contacts is not a member of package controllers
[error] GET /contacts controllers.Contacts.blank()
and this:
[error] myapp/app/views/contact/form.scala.html:1: not found: type Contact
[error] #(contactForm: Form[Contact])
[error] ^
Because controllers/Contacts.java and models/Contact.java reside under sourceManaged.
I've tried manually adding the appropriate managed sources subdir to sourceDirectory in Compile and javaSource in Compile in my build.sbt but it did not improve things.
I have considered making the managed source subdir a subproject and then using aggreate(), but it does not have the necessary build.sbt or project files -- it only has Java sources. And it seemed that making a managed source directory into a subproject from might be inappropriate. Should I reconsider this?
First make sure the plugin has a way to be added to sourceGenerators in Compile by your Play project. You can find how to do this here in the sbt documentation. I also have an example in a plugin I wrote, but note that it uses 0.12.x syntax.
Once you've done that, be sure one of your Play project build files adds the settings. This will be as simple as adding the name you used for the settings in the plugin to the build file, like this example of my plugin shows.