So it used to be that from the command line, swift build --clean would clean the build by removing the .build directory. You could also pass --clean=dist to get rid of the packages as well.
I just upgraded to Swift 4 and these are apparently gone. Has it been rolled into a subcommand or something? Can anyone point me to some docs on this? I couldn't find them...
Actually, I couldn't find docs on the subcommands at all. I know swift run and swift package were introduced. Anyone know where a complete documentation of these and other commands are? I find bits and pieces described in various places, but haven't found the complete doc (that hopefully exists somewhere)
swift build --clean has been replaced with swift package clean in swift 4. We made that change here: https://bugs.swift.org/browse/SR-2082
Documentation for stuff like this should be at https://github.com/apple/swift-package-manager/blob/master/Documentation/Usage.md, but it's lacking in some respects. We've just filed an issue to track that:
I also went ahead and filed:
Swift usage message should mention swiftpm commands
SwiftPM command usage messages should mention other top-level commands
Thanks for bringing this up!
Related
I starting to look into porting my application from Gtkmm 3.24 to Gtkmm 4.x (not sure which version yet). For now, I am only trying to understand what exactly is deprecated and how much work is needed for planning. One way to ease porting is to look into all deprecated usages in the Gtkmm 3.24 version and update them to the newer flavor before porting. I have found several macros that can help with that:
GTKMM_DISABLE_DEPRECATED
GDKMM_DISABLE_DEPRECATED
GLIBMM_DISABLE_DEPRECATED
GIOMM_DISABLE_DEPRECATED
When I #define these, the compiler throws error when meeting deprecated stuff because they have been disabled. This is nice, once the code is leveled up, to make sure the code stays free of deprecated usages.
In my case, however, the code is still full of deprecations and the compiler stops compilation on the first deprecation it meets. This does not help me much in understanding where the deprecations lie and how much work is needed. I could go about and solve every error, one by one, until there is no more (this is ultimately what I will do) but I can't know ahead how much time this will take.
What I would really like are macros that throw warnings when meeting deprecation, but let the compiler go on about building. This way I could get a list of everything that is deprecated in my codebase and plan work appropriately. I have browsed the Gtkmm documentation and codebase but found nothing.
Do such macros exist and if so, what are they?
The solution was to use
GTKMM_DISABLE_DEPRECATED
GDKMM_DISABLE_DEPRECATED
GLIBMM_DISABLE_DEPRECATED
GIOMM_DISABLE_DEPRECATED
like I did but to use the -k flag with make. From man make:
-k, --keep-going
Continue as much as possible after an error. While the target
that failed, and those that depend on it, cannot be remade, the
other dependencies of these targets can be processed all the same.
Source: Inkscape GTK+ 3 migration wiki page.
When I publish a Swift Package, I like to include some Playgrounds to show examples of how to use the package. Prior to Swift 5.4, I was able to do this in a relatively straightforward way, but now none of my Playgrounds ever sees the contents of my package module. It doesn't make any sense to me.
I've followed the exact pattern illustrated by Apple's own WWDC videos, which is to have a Playgrounds/ folder as a peer to your Sources/ folder, and then just import the package module.
The import works, but the Playground always reports that it cannot find any of the types from inside the module. They are all marked public, and as I mentioned before, these used to work just fine.
This doesn't work for me in Swift 5.4 or 5.5, in Xcode 12.5 or 13 Beta.
I assume there must be some setting or configuration I am not understanding. Can somebody please explain the best practice here?
For reference, here is one of my simple Swift Packages that has Playgrounds that currently do not work:
https://github.com/dunesailer/Wordsmith
EDIT: It gets even stranger. I have a different Swift Package structured what appears to me to be the exact same way, but its Playgrounds work fine. Whaaat? That one is here:
https://github.com/dunesailer/Aesthete
If you move/ delete the folders Chemical Names, Work Titles and Person Names inside Playgrounds/, all the playgrounds work fine. It looks like Xcode doesn't support folders in Playgrounds/ (/ it's a bug).
So to work around this issue, just put all your playgrounds in the same folder.
EDIT: It looks like this works inconsistently. I've submitted a bug report/ Feedback for Developer Tools in Feedback Assistant.
A longer term workaround is to use DocC (arrived in Xcode 13 beta), which will support more advanced tutorials/ articles in the repo.
Use workspace.
(Xcode: File: New: Workspace)
You use it as "container" for both your package, playground (or app target for that matter). The important thing is to add each of these to the workspace by using "Add files to ..." button in the lower-left section of the Xcode, and from there on, open the .xcworkspace file:
to edit your package
to run playground file.
You can follow instructions from here.
https://stackoverflow.com/a/67580251/13292535
I'm trying to import an SPM package in Xcode11. I can fetch the library and see it in the project as Swift Package Dependencies but when trying to import, Xcode doesn't find it.
I read that the problem could be custom configurations and not the standard e.g. Debug.
Does anyone know how to solve this without renaming the configuration names?
The best advice at the moment is this post on the Swift forums where Ankit says:
This is a known issue that Apple folks are tracking internally. Currently, Swift packages default to the "Release" configuration when anything other than Debug and Release is used. In theory, adding $(BUILD_DIR)/Release to SWIFT_INCLUDE_PATHS build setting for the custom configurations should work around this issue but it can lead to some weird errors in case something unexpected gets picked from that directory.
Anyone please let me know what is this all about? I am stuck since a week on this and no help from searching. I posted my query to the developer of Alamofire but still no response. Please help! I am totally confused what is wrong in the integration of Alamofire. I have followed every step and this issue is coming with XCode 6.3 as before it was running properly.
When I am adding the Framework under "Copy Frameworks", it is adding the Framework twice showing different paths but when I am Going to there location, it is taking me to the same location. Here is the screen shot.
I have also created the video for that issue. May be that can help in a better way. Please see HERE
Moreover, latest SDK contains framework for MAC OS as well but I didn't add that. I hope all the above information will help you in helping me. Thanks!
This is going to be incredibly difficult to debug without a sample project that is set up in the same manner as your actual one. If you had imported Alamofire project into your project, you wouldn't see two versions of Alamofire appear when you add it to the Copy Frameworks build phase. If you truly want to resolve this quickly, you have two options.
Option 1
Push up a sample project to Github and link it here. We can then take a look at the project and pretty quickly access what the issue is. The main reason it's so difficult here is that there are roughly 10 different things that could be the cause of the issue. Therefore, it's much faster for you to create a sample project than for us to go round-and-round (which we've already started with #Masterfego).
Option 2
Take the leap and try out CocoaPods. It is a fantastic dependency management system that will forever alleviate these annoying types of project management issues. CocoaPods itself has fantastic documentation. Also, the Alamofire README breaks down in detail how to add Alamofire to your project using CocoaPods.
Recommendation
I would highly encourage you to choose Option 2. That is definitely the fastest way forward and you won't regret moving to a more robust dependency management system. It makes managing library updates and new installations extremely simple.
If you do end up going with Option 1, then I'll take a look at your sample project and revise my answer.
I'm interested in Swift programming, but I'd prefer not to use Xcode as it is too bloated for my practical use.
I know this is possible to do with Objective-C with something like
clang -fobjc-arc main.m myclass.m -o prog1
where the different .m files are just listed out, but I don't know how to do this with Swift. I can use the basic Swift command-line tool, like swift MyProgram.swift which just produces a binary called MyProgram.
As far as I can tell, this command won't let you compile multiple .swift files together.
Ideally, a system like makefiles for C++ would be ideal. Is there any way to do this with Swift currently from the command line?
While you can use swiftc, the recommended way after Swift 2.1 is open-sourced is to use swift build as described at Swift Package Manager documentation.
An important note from that document:
Please note, that the 2.2 release snapshot does not come with
swift-build-tool, either download the development snapshot or build
your own copy of swift-llbuild.
By developer snapshot they mean a developer snapshot installer from the official package or anything that's newer than Swift 2.2 at the moment.
I recommend swift build for convenience, if however you want to do it by hand still, then run swift build -v and you will see the commands that are run by swift build so you can construct your own command lines.