I'm building a simple webserver using Swift3 and the Swift Package Manager. Running swift build in your project folder will build all of the sources found in the Sources directory and output an executable. However, I've found that if I create folders within the Sources directory to organize my code, my builds fail. It looks to me like the presence of folders causes swift to treat the source as different modules. Is this the cause, and if so, how can I work around it?
Yes. Putting directories directly under Sources will cause SwiftPM to interpret those as modules. This is described in the package manager reference.
To work around this, use another level of indirection: put a directory for your module inside Sources and your additional directories inside that directory:
Sources/YourApp/Stuff/Source1.swift
Sources/YourApp/Stuff/Source2.swift
Sources/YourApp/MoreStuff/Source3.swift
Sources/YourApp/MoreStuff/Source4.swift
Related
I am trying to compile several scripts in my project into an easier to move and manage DLL file, however several scripts call UnityEngine.UI, and I know that the DLL file used to exist in /Contents/UnityExtensions/Unity/GUISystem/Editor/UnityEditor.UI.dll however the only data I can find for it now are the uncompiled files inside the Package Manager, where is the compiled DLL stored now?
The simplest answer that I just found is to look in the project folder of one of your projects in Library\ScriptAssemblies
When you generate a new Swift project with swift init, you get a Sources folder similar to this. Wondering if there is a way to change the folder structure so it is like this:
main.swift
lib
lib/something.swift
And just get rid of the Sources directory.
I believe that you can use any folder structure that you want. The only thing in that references specific folders in that particular link you provided was the path in the Package.swift file. Which if you want to use, you can just update the path.
The project file keeps track of what swift files have been added into the project and which should be compiled and included in the resulting binary. As long as the files have been added via xcode you should be fine.
Using the really easy to follow instructions for building a NuGet package for an assembly with an associated package of sources for the symbol server, found here on David Ebbo's blog "The easy way to publish NuGet packages with sources" I have indeed created a pair of packages: binary and sources.
However, the sources package is incomplete and the reason is that the sources come from two class library .csproj and I used ILMerge to combine the results of the second into the first. (*) So, using the minimal .nuspec described in this post and pointing nuget.exe at the .csproj for the "main" library, the binary package is fine, but of course the sources package only has sources for the "main" library, not also for the library that was ILMerged into the "main" library.
How do I fix this (and get the sources for both projects included in the symbol package but only the binary for the "main" project in the binary package)?
FYI, the actual nuget.exe command line was: nuget pack CommandLineLexing.csproj -Build -Symbols -Properties Configuration=Release.
(*) The reason I'm doing this, in case you're interested, is that the second library is a cut down version of my accumulated "C# utilities" library - you know, a bunch of extension methods and other helpers - cut down so it only has the bare minimum needed for this particular project. And so, since it is cut down, I don't want there to be separate assembly for it which might eventually get confused with the full assembly (having the same name, and not a strong name). So I used ILMerge to put the utilities methods into the main assembly (and also mark them internal).
Not going to be easy I'm afraid.
NuGet symbol packages are simply your regular package, with pdbs, augmented with source files.
Assuming you already know you can get a merged PDB with ILMerge/ILRepack (/debug), that part is probably working file, I'm assuming your issue is that only the source files from the current project gets included.
You could simply post-process your symbol.nupkg (which is a zip), and include the source files from your other (merged) project in the src folder (you can even try that manually).
Though if you run srctool.exe -r MyMergedAssembly.pdb, you'll see different root paths, where usually (for a non-merged project) they all have a common prefix.
It may work, if SymbolSource copes with having multiple path prefixes in your PDB, that I haven't tried.
I also failed to find any documentation irt to their processing of symbol packages. We can assume they use pdbstr.exe tool to update the PDB srcsrv section of the PDB file to redirect the symbol loading to their website, but one can only tell if they support multiple roots by testing it.
If you upload your augmented symbol package to symbolsource, you can download the updated PDB using a URL similar to http://srv.symbolsource.org/pdb/Public/Castle.Core.pdb/4C81FC30DF584853B9869EAB2FA7D9891/Castle.Core.pd_ (then unzip it to a pdb file)
Then you can use both srctool.exe file.pdb and pdbstr.exe -r -s:srcsrv -p:file.pdb to verify their work.
I'm trying to create a Dart backend framework that developers can download as a dependancy and have the basic folder structure, Dart files and such generated for them in their own project. From what I understand, downloading a dependancy package only places files inside the package directory/ies (although, I may be wrong).
To get around this, I believe Dart can be used like a Bash script, and can place files in the project directory automatically through running the package's bin files in the terminal (illustrated in the Running a script in a dependency https://www.dartlang.org/tools/pub/cmd/pub-run.html).
Would this be the best way to achieve the desired result? Or is there an easier way to download a framework as a project template? (I'd also like to place similar scripts for generating controllers and such in the tools directory, and don't know if keeping this framework as a dependancy would be necessary after 'install').
Thank you for reading.
You can use pub global activate some_package to be able to use pub global run some_package:some_script or just some_script to allow to run a script contained in a Dart package without adding it to the dependencies.
I think this is the best way to distribute it.
I am compiling an app which is a sample app that uses an api. The api contains interface files (java files) and aidl files. Now I have problem in one of the interface file it cannot recognize the one of these aidl files exists in my project.
I have linked the whole api to the build path.
Does anyone has any idea ??
I had the same error, but it was fixed when I cleaned and rebuilded the project.
Projects -> clean project so it can automatically rebuild.
Look closely at your manifest file, check that the package etc are
spelled as you'd expect.
Also dont forget to paste the server's *.aidl and parcelable implementation (java) to your client project. These files has to have the same name and package as they were in the server project.
Here is some similar posts which might help:
ITelephony.aidl not compiling in eclipse
There are basically two possibilities.
(most likely) you need to make the folder that contains aidl files source folder. if you haven't done so, please do it.
You need a clean build.