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-...@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_aggar...@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 <kelvinsthirt...@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_aggar...@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-...@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 <kelvinsthirt...@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 <milse...@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 <kelvinsthirt...@gmail.com> >>>>> wrote: >>>>> >>>>> Can you give an example? >>>>> >>>>> On Mon, Mar 27, 2017 at 3:59 PM, Michael Ilseman <milse...@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@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@swift.org >>>>>> > https://lists.swift.org/mailman/listinfo/swift-users >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> swift-build-dev mailing list >>>> swift-build-...@swift.org >>>> https://lists.swift.org/mailman/listinfo/swift-build-dev >>>> >>>> >>> >> >> > > _______________________________________________ > swift-build-dev mailing list > swift-build-...@swift.org > https://lists.swift.org/mailman/listinfo/swift-build-dev > >
_______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users