Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues building on Linux with swift 3.0.1 #42

Open
Ponyboy47 opened this issue Feb 16, 2017 · 13 comments
Open

Issues building on Linux with swift 3.0.1 #42

Ponyboy47 opened this issue Feb 16, 2017 · 13 comments

Comments

@Ponyboy47
Copy link

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
Copy link
Author

Ponyboy47 commented Feb 16, 2017

This compiles correctly, with only minor warnings on macOS

@ghost
Copy link

ghost commented Apr 21, 2017

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

@nvzqz
Copy link
Owner

nvzqz commented May 13, 2017

What's the status on this? @Ponyboy47

@Ponyboy47
Copy link
Author

@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
Copy link
Owner

nvzqz commented Jul 5, 2017

@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
Copy link
Author

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
Copy link
Owner

nvzqz commented Jul 5, 2017

That's an oddly specific bug. 😅

@Ponyboy47
Copy link
Author

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
Copy link
Owner

nvzqz commented Jul 6, 2017

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
Copy link
Author

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
Copy link
Author

Ponyboy47 commented Jul 6, 2017

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
Copy link
Owner

nvzqz commented Jul 6, 2017

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 nvzqz/RandomKit@0c06830

@Ponyboy47
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants