search

nvzqz / FileKit

Simple and expressive file management in Swift
https://nvzqz.github.io/FileKit/docs/
MIT License
2.34k stars 207 forks source link

Issues building on Linux with swift 3.0.1 #42

Open Ponyboy47 opened 7 years ago

Ponyboy47 commented 7 years ago

I just tried building this on an linux machine running Ubuntu 16.04 with swift 3.0.1 and there were several build errors.

failures.txt

I will attempt running this on my macOS laptop to see if I get the same failures

Ponyboy47 commented 7 years ago

This compiles correctly, with only minor warnings on macOS

ghost commented 7 years ago

What branch did you try on macOS and was it converted to Swift 3 syntax in Xcode? Thanks.

nvzqz commented 7 years ago

What's the status on this? @Ponyboy47

Ponyboy47 commented 7 years ago

@trips-app I was using the master branch on macOS. I just cloned the repo and tried building it.

@nvzqz It's been a long time since I even looked at this repo. I started using kylef/PathKit, but I'm going to look into this one and give it another shot and see if I can't get it compiling on Linux.

nvzqz commented 7 years ago

@Ponyboy47 part of my plan for this month is to make some improvements to FileKit + improve compatibility issues + add Swift 4 support. So I'll try to tackle this as soon as I can.

Ponyboy47 commented 7 years ago

Well I just noticed some weird swift behavior on linux and ended up filing a bug (https://bugs.swift.org/browse/SR-5382).

For whatever reason, the file TextFile.swift cannot be named that or else it thinks String does not conform to ReadableWritable. Renaming TextFile.swift to StringFile.swift solves those build issues, but I have no idea why. Just thought I'd mention the bug ticket I filed for swift and gave the heads up about renaming that file (at least until the swift devs identify/fix the problem).

nvzqz commented 7 years ago

That's an oddly specific bug. 😅

Ponyboy47 commented 7 years ago

So I've gotten most everything fixed for linux on my local fork except for 4 errors.

1) For whatever reason, on linux, the FileManager delegate property is read-only. So the _FMWrapper doesn't work. @nvzqz Is there a specific reason for the _FMWrapper in Path.swift instead of just using the default file manager? I can probably work around that if it is necessary, but it would be easier if I didn't. 2) NSData cannot be constructed using a non-required initializer NSData.init(contentsOfFile: String). 3) NSArray cannot be constructed using a non-required initializer NSArray.init(contentsOfFile: String). 4) NSDicitonary.init(contentsOfFile: String) has become deprecated. This functionality will probably be broken until the update to Swift 4 using the new JSON encoder. As such, I may start working on the update to swift 4 myself. I really would like to see this working on Linux

I'm tempted to remove everything related to NSData/NSArray/NSDictionary for linux anyways since linux users generally try to stick with the newer swift types Data, Array, & Dictionary. There's still a lot of missing functionality from Foundation on Linux and the linux swift community finds that it's easier to avoid Foundation wherever possible.

nvzqz commented 7 years ago

I don't remember exactly why I made _FMWrapper. I believe it was because I wanted to allow assigning a delegate to a specific path. This feels like a waste looking back at it. It should definitely be removed in a 5.0 version.

Regarding the NS-APIs, some of it should also go. I'm thinking I may reinvent the wheel a bit and remove the need for FileManager and use the C API directly if this doesn't rely on any FileManager-specific functionality.

Admittedly, there's many of aspects that I want to change but just haven't felt like changing or had the time to. I've been playing around with Rust quite a bit and I love how file management is implemented in their standard library.

Ponyboy47 commented 7 years ago

I would love to remove most of the reliance on Foundation. That would be the best way to ensure this is cross-platform. Obviously we will need a little bit of Foundation for things like the Data type and probably a couple other things. I don't have a problem with using FileManager because it does let us avoid reinventing the wheel, but if that's what you want to do then I'd be more than happy to get my hands dirty.

I can't wait for the day when the objective c layer has been completely rewritten in swift and everything in the swift standard library has been implemented for all platforms...I dream of that day. The Swift Server Side community is pushing pretty hard to get a lot of standard library completed for linux.

Ponyboy47 commented 7 years ago

Well I'm going to go crazy on my branch and do some pretty substantial refactoring to get this working on linux and to remove a bunch of stuff that just won't work in linux

I'll even throw in my own swift 4 updates...wish me luck

nvzqz commented 7 years ago

Getting #48 sorted out while FileKit is 4.x would be great.

Regarding cross platform compatibility, it's interesting how some things aren't just on an implementation level but also a compiler level. Here's a perfect example https://github.com/nvzqz/RandomKit/commit/0c0683016f64ad7506f3550cf850b5b75c3a9236

Ponyboy47 commented 7 years ago

I'll probably wait for linux support until 5.0 since it will probably take a pretty substantial effort to remove _FMWrapper and several of the NSTypes. I'll focus on #48 and getting FileKit Swift 4 ready for now