Re: [swift-users] Incorrect Fisher-Yates shuffle in example code

[Ankit Aggarwal via swift-users]

Thank you for working on this!

On Sun, Dec 17, 2017 at 11:07 PM, Saagar Jha via swift-users <
swift-users@swift.org> wrote:

>
> Saagar Jha
>
> On Dec 17, 2017, at 22:24, Nevin Brackett-Rozinsky via swift-users <
> swift-users@swift.org> wrote:
>
> …well that was more complicated than I anticipated.
>
> The “random” function was (Int) -> Int, so when I removed the
> “IndexDistance == Int” constraint on “shuffle” I either had to add several
> “numericCast” calls or make “random” generic.
>
> So I made “random” generic. And also fixed the modulo bias issue in the
> Glibc version that Saagar mentioned. Or at least I hope I did. I haven’t
> tested that part (nor any of the non-Swift-4 / non-macOS parts). Also, I am
> not sure why “random” had been a closure value stored in a “let” constant,
> but I changed it to a function.
>
>
> Great! I'll close my pull request, then.
>
>
> While I was at it, I removed the random-access constraint I had placed on
> “shuffle”. It will now shuffle any MutableCollection, with complexity O(n)
> for a RandomAccessCollection and O(n²) otherwise. (The constraint was
> different in different Swift versions, so the entire extension had to be
> duplicated. Without the constraint the implementation is much sleeker.)
>
> Nevin
>
>
> On Sun, Dec 17, 2017 at 9:26 PM, Nevin Brackett-Rozinsky <
> nevin.brackettrozin...@gmail.com> wrote:
>
>> On Sun, Dec 17, 2017 at 7:37 PM, Dave Abrahams 
>> wrote:
>>
>>>
>>> On Dec 16, 2017, at 4:34 PM, Nevin Brackett-Rozinsky via swift-users <
>>> swift-users@swift.org> wrote:
>>>
>>> public extension MutableCollection where Self: RandomAccessCollection,
>>> IndexDistance == Int {
>>>
>>>
>>> IndexDistance == Int is an over-constraint, FWIW.  Adding it is
>>> generally a mistake.  Not a serious one, but it does limit utility somewhat.
>>>
>>> HTH,
>>> Dave
>>>
>>
>> You are correct, however there is an accepted-and-implemented proposal (
>> SE–0191
>> )
>> to eliminate IndexDistance and replace it with Int, so the constraint will
>> always be satisfied starting in Swift 4.1.
>>
>> I wrote a version of shuffle() without that constraint, but it is less
>> elegant: the line “for n in 0 ..< count - 1” no longer compiles, and
>> writing “0 as IndexDistance” doesn’t fix it because the resulting Range is
>> not a Sequence, since IndexDistance.Stride does not conform to
>> SignedInteger (at least in Swift 4.0 according to Xcode 9.2).
>>
>> A while loop works of course, though a direct conversion requires writing
>> “var n = 0 as IndexDistance” before the loop. Luckily, with a bit of
>> cleverness we can eliminate all mention of IndexDistance, and this time we
>> really and truly don’t need the “guard !isEmpty” line:
>>
>> extension MutableCollection where Self: RandomAccessCollection {
>> mutating func shuffle() {
>> var n = count
>> while n > 1 {
>> let i = index(startIndex, offsetBy: count - n)
>> let j = index(i, offsetBy: random(n))
>> n -= 1
>> swapAt(i, j)
>> }
>> }
>> }
>>
>> Essentially, the constraint is there to make the code nicer on pre-4.1
>> versions of Swift, though I’m happy to remove it if you think that’s
>> better. If nothing else, removing the constraint means people reading the
>> example code in the future won’t be misled into thinking they need to use
>> it themselves, so perhaps it should go just on that account.
>>
>> Okay, you’ve convinced me, I’ll update the PR. :-)
>>
>> Nevin
>>
>
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>
>
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Wrapping ImageMagick in a Swift Package

[Ankit Aggarwal via swift-users]

Hi Toni,

You're not supposed to build the system module package (because there is
nothing to build). Tag and add this package as a dependency and then try to
import the `TestPkg` module that you defined in the modulemap. The error
here is bogus and is tracked by https://bugs.swift.org/browse/SR-5383

On Tue, Oct 3, 2017 at 12:32 AM, Toni Suter via swift-users <
swift-users@swift.org> wrote:

> Hi,
>
> I am trying to create a Swift Package that wraps the ImageMagick C API. So
> I installed ImageMagick using MacPorts and
> I was then able to build the sample program with the following commands:
>
> export PKG_CONFIG_PATH=/opt/local/lib/pkgconfig
> cc main.c `pkg-config --cflags --libs MagickWand`
>
> Then I created a package with the command "swift package init
> --type=system-module" and I modified Package.swift to look
> like this:
>
> // swift-tools-version:4.0
>
> import PackageDescription
>
> let package = Package(
> name: "TestPkg",
> pkgConfig: "MagickWand"
> )
>
> and I modified module.modulemap to the following:
>
> module TestPkg [system] {
>   header "/opt/local/include/ImageMagick-6/wand/MagickWand.h"
>   link "MagickWand-6.Q16"
>   link "MagickCore-6.Q16"
>   export *
> }
>
> Now when I run "swift build", I get the following error message:
>
> :0: error: unexpected 'commands' value (expected map)
> :0: error: unable to load build file
> error: terminated(1): /Library/Developer/Toolchains/swift-4.0-DEVELOPMENT-
> SNAPSHOT-2017-08-27-a.xctoolchain/usr/bin/swift-build-tool -f
> /Users/tonisuter/Desktop/TestPkg/.build/debug.yaml main
>
> Does anybody know how I can fix this error?
>
> Thanks and best regards
> Toni
>
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] SwiftPM on Linux Failed

[Ankit Aggarwal via swift-users]

Thanks for the detailed info. I was able to reproduce this. There seems to be 
some problem with importing modules without their swiftdoc in Ubuntu 14.04. 
I've filed https://bugs.swift.org/browse/SR-5800

> On 30-Aug-2017, at 1:26 PM, adelzh...@qq.com wrote:
> 
> export SWIFT_HOME=/opt/swift/4.0-dev
> export PATH="$SWIFT_HOME/usr/bin":"${PATH}"


--
Ankit

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] SwiftPM on Linux Failed

[Ankit Aggarwal via swift-users]

Hey,

Can you post the steps you followed to install the Swift toolchain?

Also, can you post the output of:
$ swift build -v

Thanks!

On Tue, Aug 29, 2017 at 8:14 PM, adelzhang via swift-users <
swift-users@swift.org> wrote:

>
> Hi, everyone.
>
> Installing swift on linux is not that easy. Following
> https://swift.org/getting-started/#using-the-package-manager instruction,
> but `swift build` failed:
>
> ```
> error: manifest parse error(s):
> /home/vagrant/hello/Package.swift:4:8: error: no such module
> 'PackageDescription'
> import PackageDescription
>^
> ```
>
> I installed Swift 4.0
>
> ```
> $swift version
> Swift version 4.0-dev (LLVM 2dedb62a0b, Clang b9d76a314c, Swift 0899bd328a)
> Target: x86_64-unknown-linux-gnu
> ```
>
> Ubuntu 14.04 is running on VirtualBox using vagrant.
>
> ```
> $lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.5 LTS
> Release:14.04
> Codename:   trusty
> ```
>
> Does someone happen to know the work-around?
>
> --
> Regards
>
> adelzhang
>
>
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] SwiftPM manual dependency management

[Ankit Aggarwal via swift-users]

> On 22-Jul-2017, at 3:37 PM, Geordie Jay <geo...@gmail.com> wrote:
> 
> 
> Geordie J <geo...@gmail.com <mailto:geo...@gmail.com>> schrieb am Fr. 21. 
> Juli 2017 um 14:39:
> Hi Ankit, thanks for your reply.
> 
>> Am 21.07.2017 um 07:33 schrieb Ankit Aggarwal via swift-users 
>> <swift-users@swift.org <mailto:swift-users@swift.org>>:
>> 
>> 
>> 
>> On Thu, Jul 20, 2017 at 10:34 PM, Geordie J via swift-users 
>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>> Hi all,
>> 
>> My team and I are trying to use SwiftPM to develop a relatively complex app 
>> with multiple dependencies, all of which are being developed locally and in 
>> parallel. The reason for this is compatibility with an existing 
>> module/import structure used by our iOS app. Maybe I’m doing something very 
>> wrong but my experience so far (2 months in) is that this is extremely 
>> difficult with SwiftPM.
>> 
>> What I’d love to be able to do is to just run `git add submodule 
>> http://blah.com/mysubmodule.git` <http://blah.com/mysubmodule.git%60> in the 
>> Packages subdirectory and SwiftPM would just let me manage dependencies from 
>> there myself.
>> 
>> I was excited to see that SwiftPM 4 has a "Top of Tree" development option 
>> for this purpose. So far my experience with this has not been good. Firstly 
>> because SwiftPM still unnecessarily tries to clone my repos itself (some of 
>> which are huge), and secondly because this creates an absolute path 
>> dependency in `.build/dependencies-state.json`, meaning this setup isn’t 
>> sharable within our dev team.
>> 
>> Attempting this with "local" git urls adds an almost absurd level of 
>> complexity, having to tag each commit for SwiftPM to build. The fact that 
>> we'd need to make a commit to test whether the project even builds is insane 
>> enough as is, let alone the tagging and trying to tell the base project to 
>> use a newer minor version etc etc.
>> 
>> Adding multiple subtargets is also not an option because the dependencies 
>> (as dynamic libraries) really are shared between multiple 
>> targets/sub-dependencies, which SwiftPM seems to deal with quite well.
>> 
>> tldr; *Please* let us manage dependencies ourselves. It’d be so easy if 
>> Package.swift had an option along the lines of .Package.local(named: "XYZ") 
>> that it then looked for in ./Packages/XYZ. Again, maybe I’m overlooking 
>> something but this seems like an obvious and vital option to have. It’d also 
>> simplify the introductory SwiftPM docs significantly.
>> 
>> Is anyone else having this issue? Would this change really be as simple and 
>> painless as it sounds? I would be prepared to make a pull request along 
>> these lines.
>> 
>> I think you're not really using the Top of Tree feature. You need to add 
>> each dependency using its canonical URL, hosted at some server like github. 
>> After adding the dependencies, you can use edit feature to put a dependency 
>> in Top of Tree mode. To do so, run:
>> 
>> $ swift package edit  --path 
>> ../path/to/self/managed/checkout/of/the/package
> 
> Yes, this is what I tried this week. I’m pretty sure this is not a case of 
> misunderstanding the feature or the docs.
> 
>> 
>> The package manager will then stop using the cloned repository and use the 
>> checkout present at that path (regardless of the state it is in).
> 
> Yes, but then I have – per dependency – two checkouts of a potentially huge 
> repository. Why force everyone on the dev team to clone a huge repo twice, 
> only to *never* use one of the clones. Also, SwiftPM breaks when —path points 
> at Packages/PackageName, which is exactly where I’d expect the package to be, 
> not in some arbitrary external path (+ some kind of internal checkout cache 
> that will never be used) as well.
> 
> I haven’t tried to test this recently because it’s a slow process but I have 
> the impression the deps could be even be cloned more than twice, depending on 
> how cleverly SwiftPM realises that multiple Packages have the same dependency.
> 
> Also, this makes managing interdependent state of development amongst 
> dependencies more difficult than needed. How do we guarantee that devs are on 
> the same commit when using top of tree development? Tagging and managing 
> version numbers etc for day-to-day development is emphatically not an option 
> for us. Since SwiftPM packages only work from a git context anyway, why not 
> allow use of git’s established pattern of dealing with thi

Re: [swift-users] SwiftPM manual dependency management

[Ankit Aggarwal via swift-users]

+swift-build-dev

> On 21-Jul-2017, at 6:09 PM, Geordie J <geo...@gmail.com> wrote:
> 
> Hi Ankit, thanks for your reply.
> 
>> Am 21.07.2017 um 07:33 schrieb Ankit Aggarwal via swift-users 
>> <swift-users@swift.org <mailto:swift-users@swift.org>>:
>> 
>> 
>> 
>> On Thu, Jul 20, 2017 at 10:34 PM, Geordie J via swift-users 
>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>> Hi all,
>> 
>> My team and I are trying to use SwiftPM to develop a relatively complex app 
>> with multiple dependencies, all of which are being developed locally and in 
>> parallel. The reason for this is compatibility with an existing 
>> module/import structure used by our iOS app. Maybe I’m doing something very 
>> wrong but my experience so far (2 months in) is that this is extremely 
>> difficult with SwiftPM.
>> 
>> What I’d love to be able to do is to just run `git add submodule 
>> http://blah.com/mysubmodule.git` <http://blah.com/mysubmodule.git%60> in the 
>> Packages subdirectory and SwiftPM would just let me manage dependencies from 
>> there myself.
>> 
>> I was excited to see that SwiftPM 4 has a "Top of Tree" development option 
>> for this purpose. So far my experience with this has not been good. Firstly 
>> because SwiftPM still unnecessarily tries to clone my repos itself (some of 
>> which are huge), and secondly because this creates an absolute path 
>> dependency in `.build/dependencies-state.json`, meaning this setup isn’t 
>> sharable within our dev team.
>> 
>> Attempting this with "local" git urls adds an almost absurd level of 
>> complexity, having to tag each commit for SwiftPM to build. The fact that 
>> we'd need to make a commit to test whether the project even builds is insane 
>> enough as is, let alone the tagging and trying to tell the base project to 
>> use a newer minor version etc etc.
>> 
>> Adding multiple subtargets is also not an option because the dependencies 
>> (as dynamic libraries) really are shared between multiple 
>> targets/sub-dependencies, which SwiftPM seems to deal with quite well.
>> 
>> tldr; *Please* let us manage dependencies ourselves. It’d be so easy if 
>> Package.swift had an option along the lines of .Package.local(named: "XYZ") 
>> that it then looked for in ./Packages/XYZ. Again, maybe I’m overlooking 
>> something but this seems like an obvious and vital option to have. It’d also 
>> simplify the introductory SwiftPM docs significantly.
>> 
>> Is anyone else having this issue? Would this change really be as simple and 
>> painless as it sounds? I would be prepared to make a pull request along 
>> these lines.
>> 
>> I think you're not really using the Top of Tree feature. You need to add 
>> each dependency using its canonical URL, hosted at some server like github. 
>> After adding the dependencies, you can use edit feature to put a dependency 
>> in Top of Tree mode. To do so, run:
>> 
>> $ swift package edit  --path 
>> ../path/to/self/managed/checkout/of/the/package
> 
> Yes, this is what I tried this week. I’m pretty sure this is not a case of 
> misunderstanding the feature or the docs.
> 

Ah, cool!

>> 
>> The package manager will then stop using the cloned repository and use the 
>> checkout present at that path (regardless of the state it is in).
> 
> Yes, but then I have – per dependency – two checkouts of a potentially huge 
> repository. Why force everyone on the dev team to clone a huge repo twice, 
> only to *never* use one of the clones.

Sure, you could end up with clones but that is only an implementation detail. 
SwiftPM can become smart enough and remove a clone that is not being used.

> Also, SwiftPM breaks when —path points at Packages/PackageName, which is 
> exactly where I’d expect the package to be, not in some arbitrary external 
> path (+ some kind of internal checkout cache that will never be used) as well.

If --path Packages/PackageName doesn't work, that is a bug! Do you mind filing 
a JIRA at bugs.swift.org <http://bugs.swift.org/>? 

I understand internal caches could be an inconvenience if repositories are 
large but we can definitely improve how caching works.

> 
> I haven’t tried to test this recently because it’s a slow process but I have 
> the impression the deps could be even be cloned more than twice, depending on 
> how cleverly SwiftPM realises that multiple Packages have the same dependency.

Right now, SwiftPM will never clone a dependency twice.

> Also, this makes managing interdependent state of development amongst 
>

Re: [swift-users] SwiftPM manual dependency management

[Ankit Aggarwal via swift-users]

On Thu, Jul 20, 2017 at 10:34 PM, Geordie J via swift-users <
swift-users@swift.org> wrote:

> Hi all,
>
> My team and I are trying to use SwiftPM to develop a relatively complex
> app with multiple dependencies, all of which are being developed locally
> and in parallel. The reason for this is compatibility with an existing
> module/import structure used by our iOS app. Maybe I’m doing something very
> wrong but my experience so far (2 months in) is that this is extremely
> difficult with SwiftPM.
>
> What I’d love to be able to do is to just run `git add submodule
> http://blah.com/mysubmodule.git` in the Packages subdirectory and SwiftPM
> would just let me manage dependencies from there myself.
>
> I was excited to see that SwiftPM 4 has a "Top of Tree" development option
> for this purpose. So far my experience with this has not been good. Firstly
> because SwiftPM *still* unnecessarily tries to clone my repos itself
> (some of which are huge), and secondly because this creates an absolute
> path dependency in `.build/dependencies-state.json`, meaning this setup
> isn’t sharable within our dev team.
>
> Attempting this with "local" git urls adds an almost absurd level of
> complexity, having to tag each commit for SwiftPM to build. The fact that
> we'd need to make a commit to test whether the project even builds is
> insane enough as is, let alone the tagging and trying to tell the base
> project to use a newer minor version etc etc.
>
> Adding multiple subtargets is also not an option because the dependencies
> (as dynamic libraries) really are shared between multiple
> targets/sub-dependencies, which SwiftPM seems to deal with quite well.
>
> *tldr;* *Please* let us manage dependencies ourselves. It’d be so easy if
> Package.swift had an option along the lines of *.Package.local(named:
> "XYZ")* that it then looked for in ./Packages/XYZ. Again, maybe I’m
> overlooking something but this seems like an obvious and vital option to
> have. It’d also simplify the introductory SwiftPM docs significantly.
>
> Is anyone else having this issue? Would this change really be as simple
> and painless as it sounds? I would be prepared to make a pull request along
> these lines.
>

I think you're not really using the Top of Tree feature. You need to add
each dependency using its canonical URL, hosted at some server like github.
After adding the dependencies, you can use edit feature to put a dependency
in Top of Tree mode. To do so, run:

$ swift package edit  --path
../path/to/self/managed/checkout/of/the/package

The package manager will then stop using the cloned repository and use the
checkout present at that path (regardless of the state it is in). Sharing
this setup is not automatic, but simple. Each user just needs to run the
above command once per dependency. Also, you only need to do this if you're
actively working on a dependency. The new manifest also supports using
branch instead of version range, which is very helpful during the
development period. Let me know if something is unclear or if you have more
questions!


> Best Regards,
> Geordie
>
>
> PS. In SwiftPM 3 we had been using a hack that worked great: by filling in
> the dependencies' "basedOn" key in `workspace-state.json`, SwiftPM just
> left us alone.. We were able to commit `workspace-state.json` into our base
> project’s git repo and the rest Just Worked™. Now with the absolute paths
> being checked for this doesn’t seem to be an option.
>
>
Please do not rely on internals of the package manager as they're not
stable and will change without notice.



> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] "swift package describe" performs fetch

[Ankit Aggarwal via swift-users]

Hi Toni,

This looks like a bug, can you file a JIRA at bugs.swift.org?

On Thu, Apr 6, 2017 at 9:10 PM, Toni Suter via swift-users <
swift-users@swift.org> wrote:

> Hi everyone,
>
> I would like to obtain detailed information about a package and all its
> dependencies in an automated fashion. At first I thought that the
> two commands "swift package describe" and "swift package show-dependencies"
> are a perfect fit for that. More concretely,
> I wanted to perform the following commands:
>
> 1. Execute the command "swift package fetch" to make sure that all
> dependencies are downloaded
>
> 2. Execute the command "swift package show-dependencies --format json" to
> obtain a description of
> each package (i.e., name, path, etc.) as well as the dependency
> relationship between the packages.
>
> 3. For each package, do the following to obtain information about the
> modules in that package:
> cd path-of-package
> swift package describe --type json
>
> However, if a package has dependencies, the command "swift package
> describe --type json" will perform another fetch.
> I am not sure why this is necessary since the output of that command only
> contains information about the individual modules of
> the package. Unfortunately, this means that the same dependencies are
> downloaded multiple times if a package's dependencies have
> themselves further dependencies, which makes the process above quite slow.
> Is this a bug or is there another way to retrieve the same information?
>
> Thanks and best regards
> Toni
>
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Package Manager and iOS apps

[Ankit Aggarwal via swift-users]

Hi Tim,

You can read about plan for supporting iOS here

and
SwiftPM 4 roadmap here
.
You can write your package in a way that it can be used with SwiftPM,
CocoaPods and Carthage (depending on what all you want to support). This
allows using the package with SwiftPM for the command line application and
other dependency manager(s) for iOS application.

PS: Check out SwiftPlate  which
lets generates a template which can be used to support all dependency
managers. I haven't actually used it but it looks good!



On Thu, Mar 30, 2017 at 6:30 AM, Tim Dean via swift-users <
swift-users@swift.org> wrote:

> Hello Swift Users:
>
> Has the roadmap defined a timeframe for building iOS applications using
> the Swift Package Manager? I am working on a handful of modules that will
> be shared between a Mac command line utility app and a couple different iOS
> apps. I’d like to use SPM for building the shared code as individual
> modules, and then to define packages for the command line utility and each
> iOS application with dependencies on the shared code modules.
>
> All code will be Swift-only
>
> Is the SPM a good options or should I be sticking with CocoaPods or
> Carthage?
>
> Thanks
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

[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 package and it 
doesn't work in cases when you don't have full access to the system. That said, 
we do support this approach upto a certain degree. For e.g., swiftpm allows 
system package authors to declare hints for installing a system package 
dependency (via brew or apt-get). The /usr/include, /usr/lib etc are searched 
by default and non-standard paths are supported using pkg config. See: 
https://github.com/apple/swift-package-manager/blob/master/Documentation/Usage.md#require-system-libraries
 

> On 29-Mar-2017, at 10:55 PM, Kelvin Ma  wrote:
> 
> 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, the OS package distributors build it, users install the 
> built dependencies with `sudo apt-get install libwhatever-dev` and the 
> project source just builds and links to the library managed by the system.
> 
> Here you have to keep the forked library source up to date with the real 
> library source, download it from the internet and build the entire project 
> plus the libraries of which there could be many.
> 
> IMO the ideal way to import system libs would be for the user to install the 
> dependency with `apt`, just as you would for any C program, have the 
> `include` statements within the project source (like you would for any C 
> program), and then have the paths to `/usr/include` and `/usr/lib` and 
> `/usr/local/include` etc in a Makefile (or Package.swift). Usually it’s only 
> “specialty” libraries like libspiro that people download and build manually, 
> and even then, it’s downloaded from the Spiro project’s own official 
> repository, not a third party fork. That’s the “accepted” way to do things, 
> that linux ecosystems are designed around. Of course, this is very similar to 
> the modulemap system that currently works in Swift. I just wish modulemaps 
> could be streamlined a little, maybe combined with the top level 
> Package.swift.
> 
> On Wed, Mar 29, 2017 at 1:03 AM, Ankit Aggarwal  > wrote:
> 
>> 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 central repo still doesn’t exist yet.
> 
> Yeah thats unfortunate, maybe this will improve once we have an index.
> 
>> If Swift ever comes on par with C in terms of being usage and the lingua 
>> franca of the FOSS world, I can see linux distributions shipping standard 
>> modulemaps the same way they ship C headers, but you have to admit this is 
>> years (decades?) away at best.
>> 
>> On the flip side of it, it does wonders in terms of motivating people (me at 
>> least) to start writing pure Swift replacements for some of these C 
>> libraries (like libpng)…
> 
> I think its better to reuse existing libraries than writing from scratch 
> (unless really needed). A good approach that works is "porting" these 
> libraries to build with SwiftPM, see: libYAML 
> , libressl 
> . However, this porting can be difficult 
> to do right but it should become much easier once we have build settings 
> support and custom targets layout 
> .
> 
>> 
>> On Mar 29, 2017, at 12:42 AM, Ankit Aggarwal > > wrote:
>> 
>>> 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 
>>> > 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 
>>> 

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

[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 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
>  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  > 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  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
>>> 
>>> .
>>>
>>> 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 
 wrote:

 How do I compile a project with many modules? My tree looks like this:

 
 ​

 On Tue, Mar 28, 2017 at 12:47 PM, Michael Ilseman 
 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 "/libgit2/include/git2.h"
>export *
> }
>
> When I run, I use:
>
> swift -I  -L  -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 
> wrote:
>
> Can you give an example?
>
> On Mon, Mar 27, 2017 at 3:59 PM, Michael Ilseman 
> 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,
>> 

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

[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 package 
as a separate published package which you only need to do once.

> On 29-Mar-2017, at 10:26 AM, Kelvin Ma  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  > 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 
> .
> 
> 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 
> > 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 > > wrote:
>> 
>> How do I compile a project with many modules? My tree looks like this:
>> 
>> 
>> ​
>> 
>> On Tue, Mar 28, 2017 at 12:47 PM, Michael Ilseman > > 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 "/libgit2/include/git2.h"
>>export *
>> }
>> 
>> When I run, I use:
>> 
>> swift -I  -L  -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 >> > wrote:
>>> 
>>> Can you give an example?
>>> 
>>> On Mon, Mar 27, 2017 at 3:59 PM, Michael Ilseman >> > 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 
>>> > > 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 
>>> > 

Re: [swift-users] SwiftPM package naming question

[Ankit Aggarwal via swift-users]

Feel free to send a sample package you're having issue with!

On Mon, Jan 30, 2017 at 1:47 PM, David Sweeris via swift-users <
swift-users@swift.org> wrote:

>
> On Jan 29, 2017, at 11:56 PM, Ankit Aggarwal 
> wrote:
>
> The package manager will pick name from manifest if the sources are inside
> Sources directory or in the root directory.
>
> Documentation here:  https://github.com/apple/swif
> t-package-manager/blob/master/Documentation/Reference.md#
> module-format-reference
>
>
> Yeah, I thought so… it seems to be working on one set of packages, but not
> on another. I’ll have to poke at it some more.
>
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] SwiftPM package naming question

[Ankit Aggarwal via swift-users]

The package manager will pick name from manifest if the sources are inside
Sources directory or in the root directory.

Documentation here:  https://github.com/apple/swift-package-manager/blob/
master/Documentation/Reference.md#module-format-reference

On Mon, Jan 30, 2017 at 9:48 AM, David Sweeris via swift-users <
swift-users@swift.org> wrote:

> I have a package that, on the filesystem, is named “tmpArbWidthInteger”,
> but its Package.swift file looks like this:
> let package = Package(
> name: "ArbWidthInteger"
> )
> In another package, I have the 1st package listed as a dependency, and to
> use it there, I have to write "import tmpArbWidthInteger". I figured
> SwiftPM would pull the library’s name from the Package.swift file rather
> than the package directory's name, but "import ArbWidthInteger” throws a
> “no such module” error.
>
> Have I found a bug, is the “name” feature not implemented yet, or did I
> just miss a couple pages in the manual?
>
> - Dave Sweeris
>
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] SwiftPM: import ncurses -> conflicting types

[Ankit Aggarwal via swift-users]

ncurses is already present in the macOS sdk, so you don't need to install it 
via brew.

In CNCurses package, create a file called "shim.h":
$ cat shim.h
#include "ncurses.h"

and change the modulemap to this: 
$ cat module.modulemap
module CNCurses [system] {
  header "shim.h"
  link "ncurses"
  export *
}

> On 29-Dec-2016, at 1:25 AM, Bouke Haarsma via swift-users 
>  wrote:
> 
> Hi all,
> 
> I'm trying to build something with ncurses. There's this outdated tutorial: 
> http://dev.iachieved.it/iachievedit/ncurses-with-swift-on-linux/. In order to 
> build, a system module map was provided here: 
> https://github.com/iachievedit/CNCURSES. This assumes 
> `/usr/include/ncurses.h`, which is not available on MacOS 10.12. So I've 
> installed ncurses through homebrew and updated the modulemap: 
> https://github.com/Bouke/CNCurses. Sadly though, it doesn't work and I can't 
> figure out how to get it working.
> 
>> brew install homebrew/dupes/ncurses
> 
> Module map:
> 
>> module CNCurses [system] {
>>header "/usr/local/Cellar/ncurses/6.0_2/include/ncurses.h"
>>link "ncurses"
>>export *
>> }
> 
> I'm building with the following command, the flags taken from the package 
> provided ncurses.pc:
> 
>> swift build \
>>  -Xcc -D_DARWIN_C_SOURCE \
>>  -Xcc -I/usr/local/Cellar/ncurses/6.0_2/include \
>>  -Xcc -I/usr/local/Cellar/ncurses/6.0_2/include/ncursesw \
>>  -Xlinker -L/usr/local/Cellar/ncurses/6.0_2/lib
> 
> This produces the following error message (shortened):
> 
>> Compile Swift Module 'TermDraw' (1 sources)
>> :1:9: note: in file included from :1:
>> #import "/usr/local/Cellar/ncurses/6.0_2/include/ncurses.h"
>>^
>> /usr/local/Cellar/ncurses/6.0_2/include/ncurses.h:60:10: error: 
>> 'ncursesw/ncurses_dll.h' file not found with  include; use "quotes" 
>> instead
>> #include 
>> ^
>> :1:9: note: in file included from :1:
>> #import "/usr/local/Cellar/ncurses/6.0_2/include/ncurses.h"
>>^
>> /usr/local/Cellar/ncurses/6.0_2/include/ncurses.h:653:45: error: conflicting 
>> types for 'keyname'
>> extern NCURSES_EXPORT(NCURSES_CONST char *) keyname (int);  /* 
>> implemented */
>>^
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/curses.h:598:45:
>>  note: previous declaration is here
>> extern NCURSES_EXPORT(NCURSES_CONST char *) keyname (int);  /* 
>> implemented */
>>^
>> :1:9: note: in file included from :1:
>> #import "/usr/local/Cellar/ncurses/6.0_2/include/ncurses.h"
>>^
> 
> (and goes on for quite a few other conflicting types)
> 
> Any help on getting this to build is greatly appreciated. Example code can be 
> found here: https://github.com/Bouke/TermDraw
> 
> ---
> Thanks,
> Bouke
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users