Support Linux and Package manager
hassila opened this issue · comments
It'd be nice to make the package easily buildable on Linux using the Swift 3 package manager and not require Xcode for builds.
Blocked by #65.
I've ported the project to Swift 3 and reorganized it to follow Swift PM directory conventions, on my fork here: https://github.com/TheArtOfEngineering/FlatBuffersSwift. I haven't yet run the tests. I'd like a little clarification on some of the testing, for example bench_direct_access.swift? It seems to be some duplicated code. Is it okay to drop this?
Can things like flatbench.swift be moved over to XCTest?
I assume the CG has to be rewritten for Swift 3 as well.
In fact, it would be super awesome to get it merged in with https://github.com/google/flatbuffers directly.
Nice, looking forward to check it out when back on-grid... @mzaks, I think the manual direct access case could be dropped now as suggested after the last API iteration?
CG would need to be adjusted - the major question is what was discussed in #65, merge this in a branch, or... Personally I wouldn't mind making the full migration to Swift 3 sooner rather than later, the source breaking changes should be locked down on Wednesday according to plan.
About the merge to the main repo, there is google/flatbuffers#3785 ( @mzaks, there is a question there if you missed it)
I think Moving to XCtest for cross platform testing would make sense too as suggested.
Yeah I am currently doing some refactoring:
- removing copy&paste from different types of Readers
- making reading safe (you should not be able to read outside of the buffer regions)
- returning
nilif binary is not readable (current behaviour would be a crash)
Bug fixing:
- seems like memory alignment is much more important than I though :) If you compile with
-Ofor armv7 device you get a nice crash (so everything lower than iPhone5s and iPad Air is not working in release mode, but ok in debug mode🤕 ). ThefullMemoryAlignmentproperty onBinaryBuildConfigis now set totrueper default. And I found out that I had one alignment bug in the current version.
And new features:
- After the reader cleanup it is time to remove
LazyAccessand addFilein order to read the data from file on demand.
I guess the Swift 3 refactoring should be done again after those changes.
I hope to push most of this stuff through today. I guess unit testing will be the most time consuming part.
About Swift package manager and merging with main FlatBuffers project.
Generally the library itself is not important. fbsCG is the main part.
Using the reader and builder without the code generator will be a very painful/"low level" experience.
The generated code is tightly coupled with the infrastructure part anyways. If you upgrade the library you have to upgrade the code generator.
This is why I believe it is the best not to add the library through package manager, but let code generator, generate a self sufficient file which has the classes reflecting the fbs structure and corresponding infrastructure.
This is why I am currently a bit slow on this topics.
Mmm, yes that all makes sense to me. Let me know if and when you need help, I'd be glad to assist if I can.
maybe of help,
I have this gist for a swift 3 development environment / docker file / zsh / ssh
https://gist.github.com/johndpope/01a74ffb93921df48e334097117be1b3
# docker build -t swift3-ssh .
# https://github.com/swiftdocker/docker-swift/issues/9#issuecomment-162172540
# sudo docker run --security-opt seccomp=unconfined -p 2222:22 -i -t swift3-ssh
# docker ps # find container id
# docker exec -it <containerid> /usr/bin/zsh
Now that we are on Swift3 we can start looking into Linux compatibility.
I would still say that there is no need to have package manager support. I think generating self sufficient files is the way to go.
Given that flat buffers now is integrated into the google repo, I think this can be closed...