I'm running Xcode 11 Beta 4.
I'm using CocoaPods, and wanted to use one of my dependencies with Swift Package Manager as a static library instead of as a framework.
On a fresh project created with Xcode 11, the dependency can be imported successfully, but on my existing CocoaPods workspace, it does not.
I think it's likely related, but I'm also getting this link warning in Xcode:
directory not found for option '-L/Users/username/Library/Developer/Xcode/DerivedData/App-axanznliwntexmdfdskitsxlfypz/Build/Products/Release-iphoneos
I went to see if the directory exists after the warning is emitted, and it does.
I could not find any meaningful difference between the newly-created project and my old one, other than the existence of CocoaPods.
Would appreciate any pointers.
After adding a library (FASwiftUI in my case) through Swift Package Manager I had to add it to
Project Settings -> My Target ->
General -> Frameworks, Libraries, and Embedded Content
to be visible in the import statement.
I did not add any scripts for it to work.
Based on #AlexandreMorgado answer it seems like it is better to run this script in Build phases before Compile Sources. Then it works when archiving.
if [ -d "${SYMROOT}/Release${EFFECTIVE_PLATFORM_NAME}/" ] && [ "${SYMROOT}/Release${EFFECTIVE_PLATFORM_NAME}/" != "${SYMROOT}/${CONFIGURATION}${EFFECTIVE_PLATFORM_NAME}/" ]
then
cp -f -R "${SYMROOT}/Release${EFFECTIVE_PLATFORM_NAME}/" "${SYMROOT}/${CONFIGURATION}${EFFECTIVE_PLATFORM_NAME}/"
fi
Solution
let package = Package(
name: "PackageName",
dependencies: [
// YOU MUST ADD THE DEPENDENCY BOTH HERE [1] AND BELOW [2]
.package(url: "https://github.com/mattmaddux/FASwiftUI", from: "1.0.4")
],
targets: [
.target(
name: "PackageName",
/*[2]*/ dependencies: ["FASwiftUI"], // [2] <<<--------- Added here as well
]
)
Explanation
I'm developing a Swift package that must provide FontAwesome Icons to whoever imports it.
I was getting "No such module 'FASwiftUI'" in my SwiftUI preview canvas.
I solved it by adding "FASwiftUI" to BOTH the dependencies array of the package AS WELL AS to the dependencies array in the target itself.
Full Package.swift File
// swift-tools-version:5.3
// The swift-tools-version declares the minimum version of Swift required to build this package.
import PackageDescription
let package = Package(
name: "PackageName",
platforms: [
.macOS(.v11),
.iOS(.v14)
],
products: [
// Products define the executables and libraries a package produces, and make them visible to other packages.
.library(
name: "PackageName",
targets: ["PackageName"])
],
dependencies: [
// Dependencies declare other packages that this package depends on.
.package(url: "https://github.com/nalexn/ViewInspector", from: "0.8.1"),
.package(url: "https://github.com/mattmaddux/FASwiftUI", from: "1.0.4")
],
targets: [
// Targets are the basic building blocks of a package. A target can define a module or a test suite.
// Targets can depend on other targets in this package, and on products in packages this package depends on.
.target(
name: "PackageName",
dependencies: ["FASwiftUI"], // <<<--------- Added this here
resources: [
.process("Assets")
]
),
.testTarget(
name: "PackageNameTests",
dependencies: ["PackageName", "ViewInspector"])
]
)
It turned out that Swift Package Manager implicitly depends on the project's Configuration names. I had them at live/qa instead of Release/Debug, and changing them back resolved the issue. Very odd, but I hope it saves you some trouble dear reader.
After a whole week fighting this issue, I developed a workaround using schemes and pre-actions.
I have a configuration called "Beta", so Xcode can't compile SPM dependencies. I realised Xcode compile SPM dependencies as Swift modules and add the files in Build/Products/Release-iphoneos folder in DeriverData.
So I created a scheme in Xcode and added this run script on build pre-actions:
cp -f -R "${SYMROOT}/Release${EFFECTIVE_PLATFORM_NAME}/" "${SYMROOT}/${CONFIGURATION}${EFFECTIVE_PLATFORM_NAME}/"
This script run before the build process, copying files and modules generated by Xcode on default Release-iphoneos folder to configuration folder, Beta-iphoneos, in my case.
After coping the content from Release-iphoneos to your $configuration$-iphoneos folder Xcode should correctly compile, build and run your project.
I just ran into a similar problem and discovered that my schemes referenced old configurations, configurations that no longer existed. Once I updated them to the correct configurations the build succeeded.
(I'm leaving this comment more than a year after the original post. It's possible that what I ran into is completely different from what was originally reported. Still, it took me quite a while to track the problem down, so I wanted to leave a note that might save others time.)
Clearing the derived data solved the issue in my case. I have Microsoft Azure Devops CI Pipeline, to clear the derived data I have to edit the Xcode build task and in the "Actions" field add this command: clean.
What worked for me: I removed my import WebMIDIKit line and added it again.
Based on #sliwinski.lukas's answer, in my case the ${CONFIGURATION} was outputting "Release", so it was just copying the Release folder itself which was no good. I simply hardcoded my configuration name, and flipped Release and MyConfiguration, and it worked. I put the following code right before "Compile Sources" in the "Build Phases" tab:
cp -f -R "${SYMROOT}/MyConfiguration${EFFECTIVE_PLATFORM_NAME}/" "${SYMROOT}/Release${EFFECTIVE_PLATFORM_NAME}/" || true
Also importantly, I had to add this in the project that used the SPM and not in the main app.
I just ran into a similar problem when running xcodebuild from the command line. I was passing CONFIGURATION_BUILD_DIR=build but found that it needs to be an absolute path: CONFIGURATION_BUILD_DIR=$(pwd)/build solved the problem.
Might I shed a bit more light on your plight...
I'm working on a fairly large iOS app (6680 files) whose result is composed of many frameworks and a mixed bag of podfiles, swift packages, legacy ObjC code (that still outnumbers newer Swift stuff).
Whenever we deal with swift packages, we need to wrap them in frameworks because it simplifies podfile & dependency resolutions when we have our remote (Jenkins) build system eat everything up to spew binaries for internal QA & ultimately, Enterprise & AppStore publishing.
Earlier today, I was dealing with one such swift package wrapped in a framework and all the issues listed above hit me square in the face.
After stashing, pushing usable code and then reapplying my stashed framework wrapper to the swift package, I used a different route than opening our project's workspace where a bunch of projects and targets are collected.
Opening the lone framework wrapper seems to have kicked XCode (13.3.1) into submission and at that point, the target settings "Frameworks, Libraries and Embeddable" section was actually able to display the swift package's "Foo" binary. Added it, and then everything was playing nice.
So, if you're still having problems, try simplifying the problem by opening smaller morsles if you can. Or start making these wrapper frameworks (if it's at all possible) so that you can actually manage smaller bites before integrating them on XC's platter.
For me, I go to Xcode -> File (The one on mac top bar) -> Packages -> Update to Latest Package Versions. This solved my problem.
In order to keep incremental builds working I had to specify the output files of "Fix SPM" build phase like so:
I have a shared project and a iOS, Android and Console project.
I have a DbClient.fs that call AppConfig.fs inside the shared project, however if I compile the iOS or Android project I get:
../DbClient.fs(39,39): Error FS0039: The value, namespace, type or module 'AppConfig' is not defined. Maybe you want one of the following: Config AppContext (FS0039) (Cobros.Droid)
This is a sample of the code:
DbClient.fs
module DbClient
..
..
let _buildDeb(con, deuda:DebtRecord, after:Int64) =
let cobro = Zone.queryByName(AppConfig.defaultZone())
AppConfig.fs
module AppConfig
open Plugin.Settings
open Plugin.Settings.Abstractions
...
let defaultZone() =
read("zone", "Sample").ToUpper()
After the comment of #Fyodor Soikin I recheck.
In the Visual Stuid Mac files were in alphabetic order and reorder it using the IDE not change anything.
So I change the order directly in the xml .projitems file and now it compile!
I am working with the Swift Package Manager. I have a project which I can successfully build via "swift build". I have created an Xcode project via "swift package generate-xcodeproj". When I open the project in Xcode it builds successfully.
The Xcode project includes two modules A and B.
Module A has the following map:
module ModuleA {
umbrella header "/Users/Robert/Temp/MyProject/Sources/ModuleA/include/ModuleA.h"
link "ModuleA"
export *
}
Module B depends upon A and has the following import:
import ModuleA
So far so good; everything builds successfully. Now I want to change the module map so that it uses a relative path, such as:
module ModuleA {
umbrella header "ModuleA.h"
link "ModuleA"
export *
}
However, when I do that I cannot get Module B to build: Error - Umbrella header 'ModuleA.h' not found. I have tried everything that I can think of in Build Settings -> Search Paths -> Header Search Paths and User Header Search Paths. I've found similar issues online, here and elsewhere, and have tried what I read but so far no go.
This has reached the hair pulling stage. Any advice will be much appreciated!
My guess is you're modifying the generated modulemap. Create a modulemap file at /Users/Robert/Temp/MyProject/Sources/ModuleA/include/module.modulemap containing:
module ModuleA {
umbrella header "ModuleA.h"
link "ModuleA"
export *
}
Run $ swift package clean to remove the old generated modulemap in .build directory and $ swift build to confirm that the custom modulemap works.
Then delete the generated Xcode project and re-generate it.
I write my code on Go. I build my project in Idea Intellij with plugin for golang. I have a package main. In main import different packages.
import (
"RF"
"flag"
"io"
"net/http"
"os"
"runtime"
"depot"
"info"
"logger"
"logic"
"poly"
"ranker"
"revgeocoder"
"search"
"search/engine"
"stat"
"views"
"fmt"
)
This packages very well linked if I write paths in $GOPATH. In Idea Intellij it makes such way:
Now, I want:
Build my project without warning
Debugging my project
First point. I make a 'build' and than I have: "Package is not specified"
If I write to Package name main, than warning doesn't disappear:
What I can do?
Point number two. The assembly is successful. After that part of package I can debug, another package I cannot debug. For example package engine I can debug. Path to this package:
/home/INT.PV.KM/urvanov/hedgehogues/distr/mapsfullsearch/src/search/engine/engine.go
Next file I cannot debug.
/home/INT.PV.KM/urvanov/hedgehogues/distr/mapsfullsearch/src/search/context.go
I cannot set a breaks point in this file:
Please, help me with my problems.
Build my project without warning -> you need to use the full package name (for example you need to use "github.com/dlsniper/demo" for a package under the GOPATH /home/florin/go and full path $GOPATH/src/github.com/dlsniper/demo. Alternatively, you can use the Run Kind directory and point it to the directory or simply just use the green arrow near the func main, click on it, select Run ... and then select Go Application
Debugging my project -> once you get your Run Configuration of type Go Application to run the application then to debug it you'll just need to use the Debug option instead of Run. Alternatively, you can click on the green arrow near the func main and choose Debug... to debug your application.
The answer to the first question
Any project in Go consist of packages. There is nothing except for packages. All packages are located in the same directory, which one is project. Other directories are libraries. They set through environment variable $GOPATH. IDEA IntelliJ let make it as:
File->Settings:
There are two type of libs in Go: globals and locals. You read about this here.
In the build time is necessary to specify which package we want to gather and line up all the dependencies themselves. In my project, there are n packets. For example, I can build mapsfullsearch package. I can build mfsimporter package. Or I can build any other, in which there is func main () {/*...*/}. To build just specify the appropriate configuration.
After that, all Imports (if relevant packages exist), resolved.
About configurations. Go to Run -> Edit Configurations...
Name: name of compilled file.
Run kind: which type of building (file or package).
Package: package name that matches the name of the directory in which the main(). There are drop-down list in IDEA IntelliJ. It appears, if you start to write his name.
Output directory: directory where the binary.
Environments: variables of environments
Go Tool arguments: compiler's arguments
Program arguments: program's arguments
For more information about config can be read here.
The answer to the second question
In the IDEA may be poorly specified file path. In that case, to which I referred in her question, the problem was related to the fact that the path to the library is specified via the home directory, which is denoted by ~. IDEA does not perceive such format. Repeat this problem I did not succeed. Although up to the moment until I put the project in the root file system, my project didn't work.
We're running eXist-db version 3.0 and want to try running XProc within it.
We found that the XProcxq Module is now part of eXist: http://exist-db.org/exist/apps/doc/extensions.xml#module_xprocxq
However, in attempting to use it we get the error below and wondered if anyone had suggestions for where we could be going wrong?
As specified at the top of the module page linked to, we added the module to the conf.xml file and restarted eXist. (This could be where we went wrong, but that's a guess on our part)
This is what the module we added looks like in conf.xml:
<module uri="http://xproc.net/xproc" class="org.exist.xquery.modules.xprocxq.XProcxq/>
Here is the simple started XQuery I've attempted to use:
xquery version "1.0" encoding "UTF-8";
import module namespace const = "http://xproc.net/xproc/const";
import module namespace xproc = "http://xproc.net/xproc";
import module namespace u = "http://xproc.net/xproc/util";
declare variable $local:XPROCXQ_EXAMPLES := "/db/examples"; (:CHANGE ME:)
let $stdin :=document{<test>Hello World</test>}
let $pipeline :=document{
<p:pipeline name="pipeline"
xmlns:p="http://www.w3.org/ns/xproc"
xmlns:c="http://www.w3.org/ns/xproc-step">
<p:identity/>
</p:pipeline>
}
return
xproc:run($pipeline,$stdin)
Here is the error:
error found while loading module xproc: IO exception while loading module 'http://xproc.net/xproc' from 'http://xproc.net/xproc'
I posed your question to the exist-open mailing list (where I'd encourage you to join for future eXist-db questions), and it appears XProc support in eXist is currently between a rock and a hard place. The xprocxq library you mentioned is woefully underdeveloped (abandoned by its original creator), and the much better developed Calabash module is incompatible with the current version of Saxon used in eXist, due to a dependency on that version of Saxon. I'd welcome you to join exist-open to discuss further. Perhaps there's some other workaround for you.
It needs to be rebuilt.
According to http://exist-db.org/exist/apps/wiki/blogs/eXist/eXist30RC1
EXPath packages that incorporate Java libraries may no longer work with eXist 3.0 and may need to be recompiled for our API changes; packages should now explicitly specify the eXist versions that they are compatible with.
I am working on the update to the XProc EXPath module.
The XMLCalabash module for eXist has now been rebuilt for a newer version of eXist and Calabash and should work with eXist 3.0.RC1.
To build your own Jar package for eXist 3.0.RC1 run:
$ git clone https://github.com/eXist-db/eXist-XMLCalabash.git
$ cd eXist-XMLCalabash
$ rm -rf src/test
$ mvn package
The Jar is then in the target/ folder. You should copy it to $EXIST_HOME/lib/user modify $EXIST_HOME/conf.xml to load the module and then restart eXist.
Updated
The XML Calabash module for eXist, now also has a PR so that it will support the upcoming eXist 3.0.RC2 -
https://github.com/eXist-db/eXist-XMLCalabash/pull/2
However you cannot built it remotely until eXist 3.0.RC2 is released.