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

Wed Mar 29 00:42:06 CDT 2017

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 Wed, Mar 29, 2017 at 10:48 AM, Kelvin Ma via swift-build-dev <
swift-build-dev at swift.org> wrote:

> 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
> <https://github.com/kelvin13/swift-zlib> on our github accounts. That
> zlib repository contains exactly ten lines of code. I used to have 6 or 7
> repos like that one up there before I got rid of them and switched to local
> repos.
>
> On Wed, Mar 29, 2017 at 12:03 AM, Ankit Aggarwal <ankit_aggarwal at apple.com
> > wrote:
>
>> 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 package as a separate published package which you only need to do
>> once.
>>
>> On 29-Mar-2017, at 10:26 AM, Kelvin Ma <kelvinsthirteen at gmail.com> wrote:
>>
>> 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 <
>> ankit_aggarwal at apple.com> wrote:
>>
>>> 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 multiple C targets, this layout should
>>> work:
>>>
>>> Package.swift
>>> Sources/
>>>     Bitmap
>>>     Cubify
>>>     Cairo/anchor.c <---- This is just an empty file to tell SwiftPM that
>>> this is a C target.
>>>     Cairo/include/Cairo.h
>>>     Cairo/include/module.modulemap
>>>     GLFW/anchor.c
>>>     GLFW/include/GLFW.h
>>>     GLFW/include/module.modulemap
>>>
>>> The modulemap is automatically generated, if not provided. This is a
>>> package which contains two targets (one C and one Swift):
>>> https://github.com/jpsim/Yams
>>>
>>> If you need to pass a bunch of compiler flags, you can use SwiftPM's
>>> pkgConfig feature but that will require you to have a separate repository
>>> for Cario and GLFW. You can experiment without creating tags using the edit
>>> feature
>>> <https://github.com/apple/swift-package-manager/blob/master/Documentation/Usage.md#editable-packages>
>>> .
>>>
>>> PS: You can join SwiftPM slack channel for quicker turn around time:
>>> https://lists.swift.org/pipermail/swift-build-dev/Week
>>> -of-Mon-20160530/000497.html
>>>
>>> Thanks,
>>> Ankit
>>>
>>>
>>> On Wed, Mar 29, 2017 at 6:06 AM, Michael Ilseman via swift-build-dev <
>>> swift-build-dev at swift.org> wrote:
>>>
>>>> This is into uncharted territory for me, but it seems you’re building
>>>> with SwiftPM. You’ll probably want to configure extra compiler flags if
>>>> that’s possible. You could also bite the bullet and build your C libraries
>>>> with SwiftPM as well. Hopefully someone on swift-build-dev can help you out.
>>>>
>>>> CC-ing Ankit
>>>>
>>>>
>>>> On Mar 28, 2017, at 5:09 PM, Kelvin Ma <kelvinsthirteen at gmail.com>
>>>> wrote:
>>>>
>>>> How do I compile a project with many modules? My tree looks like this:
>>>>
>>>> <Selection_001.png>
>>>> 
>>>>
>>>> On Tue, Mar 28, 2017 at 12:47 PM, Michael Ilseman <milseman at apple.com>
>>>> wrote:
>>>>
>>>>> Sure! In this example, I have built libgit2. I have a directory called
>>>>> Git, and inside that I have the following module map:
>>>>>
>>>>> module Git [system] {
>>>>>        header "<my path>/libgit2/include/git2.h"
>>>>>        export *
>>>>> }
>>>>>
>>>>> When I run, I use:
>>>>>
>>>>> swift -I <path-to-“Git”-directory> -L <path-to-built-libgit2> -lgit2
>>>>> foo.swift
>>>>>
>>>>> inside foo.swift I can:
>>>>>
>>>>> import Git
>>>>> // … use libGit2
>>>>>
>>>>>
>>>>> Read more about how to write a more appropriate module.map file for
>>>>> your purposes at https://clang.llvm.org/docs/Modules.html. For
>>>>> example, you might be able to define link flags inside the module.map, use
>>>>> umbrella directories, submodules, etc.
>>>>>
>>>>>
>>>>>
>>>>> On Mar 28, 2017, at 6:27 AM, Kelvin Ma <kelvinsthirteen at gmail.com>
>>>>> wrote:
>>>>>
>>>>> Can you give an example?
>>>>>
>>>>> On Mon, Mar 27, 2017 at 3:59 PM, Michael Ilseman <milseman at apple.com>
>>>>> wrote:
>>>>>
>>>>>> Sure. At a low level, you can create a module.map file and use -L/-l
>>>>>> flags in your invocation of Swift. If you want to do so at a higher level,
>>>>>> then perhaps SwiftPM can. CCing swift-build-dev for the SwiftPM part.
>>>>>>
>>>>>>
>>>>>> > On Mar 26, 2017, at 3:20 PM, Kelvin Ma via swift-users <
>>>>>> swift-users at swift.org> wrote:
>>>>>> >
>>>>>> > Idk if this has been asked before, but is there a way to import C
>>>>>> libraries into a Swift project without creating a local git repo?
>>>>>> Preferably something similar to C where you can just `#include` headers and
>>>>>> then specify the link flags (in Package.swift?)
>>>>>> >
>>>>>> > It’s getting very cumbersome to make a bunch of empty git repos
>>>>>> just to use libglfw or libcairo.
>>>>>> > _______________________________________________
>>>>>> > swift-users mailing list
>>>>>> > swift-users at swift.org
>>>>>> > https://lists.swift.org/mailman/listinfo/swift-users
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> swift-build-dev mailing list
>>>> swift-build-dev at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-build-dev
>>>>
>>>>
>>>
>>
>>
>
> _______________________________________________
> swift-build-dev mailing list
> swift-build-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-build-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20170329/76fda10e/attachment.html>