Re: [swift-users] [swift-build-dev] Importing C system libraries

2017-03-29 Thread Ankit Aggarwal via swift-users
Yep, we need to have better support for system packages. Unfortunately it is not covered in the Swift 4 Package Manager roadmap , but community driven proposal are always welcomed! > On 30-Mar-2017, at 12:25 AM

Re: [swift-users] [swift-build-dev] Importing C system libraries

2017-03-29 Thread Kelvin Ma via swift-users
I agree that portability is valuable and that it’s something that’s lacking in the c/makefile workflow. I just don’t think empty git repositories are the right solution. Perhaps we can get the best of both worlds with something like this in the SwiftPM: .Package(include: "cairo.h", link: "cai

Re: [swift-users] [swift-build-dev] Importing C system libraries

2017-03-29 Thread Ankit Aggarwal via swift-users
I agree that libressl isn't a good example because of the security questions it raises, but libYAML is a good self contained package IMO. With custom targets layout proposal, the forks can be replaced by submodules. The problem with apt-get approach is, it takes away the "portability" from the p

Re: [swift-users] [swift-build-dev] Importing C system libraries

2017-03-29 Thread Joseph Heck via swift-users
Given the effort behind wrapping all of the functionality in swift package manager into an API (libPackageManager) so that in the future it can be used by IDE style tools, I don't think you need to be seriously concerned. It's convenient for the swift package folks, especially while supporting L

Re: [swift-users] [swift-build-dev] Importing C system libraries

2017-03-29 Thread Kelvin Ma via swift-users
I don’t think this is a good approach, the libressl repo is pretty much just the source code of the C library copied and pasted into a Swift module. That’s not a good thing™. The linux build paradigm is, the library maintains its own *official* source repository

Re: [swift-users] [swift-build-dev] Importing C system libraries

2017-03-28 Thread Ankit Aggarwal via swift-users
> On 29-Mar-2017, at 11:22 AM, kelvinsthirt...@gmail.com wrote: > > I figured that was the intention, but we can’t be too surprised that everyone > is maintaining personal modulemap repositories (and polluting search results > — just try googling for a Swift PNG library!), especially when this

Re: [swift-users] [swift-build-dev] Importing C system libraries

2017-03-28 Thread taylor swift via swift-users
I figured that was the intention, but we can’t be too surprised that everyone is maintaining personal modulemap repositories (and polluting search results — just try googling for a Swift PNG library!), especially when this central repo still doesn’t exist yet. If Swift ever comes on par with C

Re: [swift-users] [swift-build-dev] Importing C system libraries

2017-03-28 Thread Ankit Aggarwal via swift-users
I think the idea was that there will be one such repository which other packages can use, that too only until the system libraries start shipping their standard modulemap. I thought we had this written down in our documentation somewhere but couldn't find it. Maybe Daniel can expand on this. On W

Re: [swift-users] [swift-build-dev] Importing C system libraries

2017-03-28 Thread Kelvin Ma via swift-users
This worked! Thanks! But why is having empty git repositories strewn about the “correct” way? System libraries should be imported from within the project, as they are in C. You have to admit it’s getting quite silly that Swift devs keep repositories like these

Re: [swift-users] [swift-build-dev] Importing C system libraries

2017-03-28 Thread Ankit Aggarwal via swift-users
In this case, these are just umbrella headers. If your modulemap contains absolute path to the header, then you don't need the header files, but SwiftPM will probably warn about this. Note that this is a "hack" to have system packages inside a single repository. The correct way is to have system

Re: [swift-users] [swift-build-dev] Importing C system libraries

2017-03-28 Thread Kelvin Ma via swift-users
I will try this, but why are the header files inside the Sources directory? System headers should live in /usr/include… On Tue, Mar 28, 2017 at 11:48 PM, Ankit Aggarwal wrote: > Hi, > > Apologies for not replying to this earlier. > > You can have multiple targets in a single package. Each target

Re: [swift-users] [swift-build-dev] Importing C system libraries

2017-03-28 Thread Ankit Aggarwal via swift-users
Hi, Apologies for not replying to this earlier. You can have multiple targets in a single package. Each target can either be Swift or C-family. The type of target is determined by the sources contained in it (*.c/*.cpp etc means C target, *.swift means Swift target). So if you want to create mult

Re: [swift-users] [swift-build-dev] Importing C system libraries

2017-03-28 Thread Kelvin Ma via swift-users
I can only fit one monitor in my dorm and it’s honestly tragic… On Tue, Mar 28, 2017 at 2:58 PM, David Sweeris wrote: > > On Mar 28, 2017, at 1:58 AM, Rien via swift-build-dev < > swift-build-...@swift.org> wrote: > > I feel your pain ;-) > > Just embrace the dark side, it takes a little time to

Re: [swift-users] [swift-build-dev] Importing C system libraries

2017-03-28 Thread David Sweeris via swift-users
> On Mar 28, 2017, at 1:58 AM, Rien via swift-build-dev > wrote: > > I feel your pain ;-) > > Just embrace the dark side, it takes a little time to get used to, but > chances are you won’t regret it. > > Btw: I still do my development in Xcode, its just that using the SPM (Swift > Package M