Re: [swift-users] [swift-corelibs-dev] Building swift with xctest and foundation fails

[Mohit Athwani via swift-users]

Hi Philippe,

That doesn't solve the issue either!

Cheers!

Mohit

On Wed, Mar 29, 2017 at 7:21 PM, Philippe Hausler 
wrote:

> You need to also pass --libdispatch but I am not quite sure that will
> fully fix the problem at hand.
>
> Sent from my iPhone
>
> On Mar 29, 2017, at 6:29 PM, Mohit Athwani via swift-corelibs-dev <
> swift-corelibs-...@swift.org> wrote:
>
> I'm trying to get back to work starting from scratch on Swift Foundation
> on my Ubuntu 16.04 LTS system.
>
> I cloned the main swift repo and all of it's dependencies via ssh
>
> ./swift/utils/update-checkout --clone-with-ssh
>
> and after running (taken from instructions from the Foundation site):
>
> swift/utils/build-script --xctest --foundation -t
>
> I get the following error:
>
> + make build-tests
> /bin/bash ../libtool  --tag=CC   --mode=link /home/mohit/Documents/swift-
> source/build/Ninja-DebugAssert/llvm-linux-x86_64/bin/clang -Wall
> -Wno-deprecated-declarations  -fblocks -I/home/mohit/Documents/swift-
> source/swift-corelibs-libdispatch/src/BlocksRuntime -isystem
> /usr/include/bsd -DLIBBSD_OVERLAY   -g -O0 -rpath
> /home/mohit/Documents/swift-source/build/Ninja-
> DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64  -o dispatch_apply
> dispatch_apply.o libbsdtests.la ../src/libdispatch.la  -lbsd
> -L/home/mohit/Documents/swift-source/build/Ninja-
> DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64 -lswiftCore
> -lswiftSwiftOnoneSupport -lpthread
> libtool: link: /home/mohit/Documents/swift-source/build/Ninja-
> DebugAssert/llvm-linux-x86_64/bin/clang -Wall
> -Wno-deprecated-declarations -fblocks -I/home/mohit/Documents/swift-
> source/swift-corelibs-libdispatch/src/BlocksRuntime -isystem
> /usr/include/bsd -DLIBBSD_OVERLAY -g -O0 -o .libs/dispatch_apply
> dispatch_apply.o  ./.libs/libbsdtests.a ../src/.libs/libdispatch.so -lbsd
> -L/home/mohit/Documents/swift-source/build/Ninja-
> DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64 -lswiftCore
> -lswiftSwiftOnoneSupport -lpthread -Wl,-rpath -Wl,//usr/lib/swift/linux
> -Wl,-rpath -Wl,/home/mohit/Documents/swift-source/build/Ninja-
> DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
> /home/mohit/Documents/swift-source/build/Ninja-
> DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64/libswiftCore.so:
> undefined reference to `objc_release'
> clang-4.0: error: linker command failed with exit code 1 (use -v to see
> invocation)
> Makefile:1123: recipe for target 'dispatch_apply' failed
> make: *** [dispatch_apply] Error 1
> swift/utils/build-script: fatal error: command terminated with a non-zero
> exit status 2, aborting
>
> Looks like there is some undefined reference for objc_release in
> libswiftCore.
>
> From the looks of the message it looks like swift was actually built but
> it's just that test cases weren't built. On this hunch, I went into my
> swift-corelibs-foundation folder and tried to execute:
>
> ninja
>
> Which tells me:
>
> ninja: error: loading 'build.ninja': No such file or directory
>
> Given my lack of experience here, I'm not quite sure how to go about
> resolving these issues.
>
> Could somebody help me out here please.
>
> Thanks,
>
> Mohit
>
>
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] [swift-corelibs-dev] Building swift with xctest and foundation fails

[Philippe Hausler via swift-users]

You need to also pass --libdispatch but I am not quite sure that will fully fix 
the problem at hand.

Sent from my iPhone

> On Mar 29, 2017, at 6:29 PM, Mohit Athwani via swift-corelibs-dev 
>  wrote:
> 
> I'm trying to get back to work starting from scratch on Swift Foundation on 
> my Ubuntu 16.04 LTS system.
> 
> I cloned the main swift repo and all of it's dependencies via ssh
> ./swift/utils/update-checkout --clone-with-ssh
> and after running (taken from instructions from the Foundation site):
> 
> swift/utils/build-script --xctest --foundation -t
> 
> I get the following error:
> 
> + make build-tests
> /bin/bash ../libtool  --tag=CC   --mode=link 
> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/llvm-linux-x86_64/bin/clang
>  -Wall -Wno-deprecated-declarations  -fblocks 
> -I/home/mohit/Documents/swift-source/swift-corelibs-libdispatch/src/BlocksRuntime
>  -isystem /usr/include/bsd -DLIBBSD_OVERLAY   -g -O0 -rpath 
> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
>   -o dispatch_apply dispatch_apply.o libbsdtests.la ../src/libdispatch.la  
> -lbsd 
> -L/home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
>  -lswiftCore -lswiftSwiftOnoneSupport -lpthread 
> libtool: link: 
> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/llvm-linux-x86_64/bin/clang
>  -Wall -Wno-deprecated-declarations -fblocks 
> -I/home/mohit/Documents/swift-source/swift-corelibs-libdispatch/src/BlocksRuntime
>  -isystem /usr/include/bsd -DLIBBSD_OVERLAY -g -O0 -o .libs/dispatch_apply 
> dispatch_apply.o  ./.libs/libbsdtests.a ../src/.libs/libdispatch.so -lbsd 
> -L/home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
>  -lswiftCore -lswiftSwiftOnoneSupport -lpthread -Wl,-rpath 
> -Wl,//usr/lib/swift/linux -Wl,-rpath 
> -Wl,/home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64/libswiftCore.so:
>  undefined reference to `objc_release'
> clang-4.0: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> Makefile:1123: recipe for target 'dispatch_apply' failed
> make: *** [dispatch_apply] Error 1
> swift/utils/build-script: fatal error: command terminated with a non-zero 
> exit status 2, aborting
> 
> Looks like there is some undefined reference for objc_release in libswiftCore.
> 
> From the looks of the message it looks like swift was actually built but it's 
> just that test cases weren't built. On this hunch, I went into my 
> swift-corelibs-foundation folder and tried to execute:
> 
> ninja
> 
> Which tells me:
> 
> ninja: error: loading 'build.ninja': No such file or directory
> 
> Given my lack of experience here, I'm not quite sure how to go about 
> resolving these issues.
> 
> Could somebody help me out here please.
> 
> Thanks,
> 
> Mohit
> 
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Forward Class Declaration in Swift...

[Shawn Erickson via swift-users]

The compiler (in a way) has whole module visibility and cross module
visibility when importing modules. No need exists for such a thing as a
result.

-Shawn

On Wed, Mar 29, 2017 at 6:31 PM Peters, Brandon via swift-users <
swift-users@swift.org> wrote:

> Is it possible to do forward class declaration in Swift similar to C++?
> ___
> 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] Forward Class Declaration in Swift...

[Peters, Brandon via swift-users]

Is it possible to do forward class declaration in Swift similar to C++?
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] Building swift with xctest and foundation fails

[Mohit Athwani via swift-users]

I'm trying to get back to work starting from scratch on Swift Foundation on
my Ubuntu 16.04 LTS system.

I cloned the main swift repo and all of it's dependencies via ssh

./swift/utils/update-checkout --clone-with-ssh

and after running (taken from instructions from the Foundation site):

swift/utils/build-script --xctest --foundation -t

I get the following error:

+ make build-tests
/bin/bash ../libtool  --tag=CC   --mode=link
/home/mohit/Documents/swift-source/build/Ninja-DebugAssert/llvm-linux-x86_64/bin/clang
-Wall -Wno-deprecated-declarations  -fblocks
-I/home/mohit/Documents/swift-source/swift-corelibs-libdispatch/src/BlocksRuntime
-isystem /usr/include/bsd -DLIBBSD_OVERLAY   -g -O0 -rpath
/home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
-o dispatch_apply dispatch_apply.o libbsdtests.la ../src/libdispatch.la
-lbsd
-L/home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
-lswiftCore -lswiftSwiftOnoneSupport -lpthread
libtool: link:
/home/mohit/Documents/swift-source/build/Ninja-DebugAssert/llvm-linux-x86_64/bin/clang
-Wall -Wno-deprecated-declarations -fblocks
-I/home/mohit/Documents/swift-source/swift-corelibs-libdispatch/src/BlocksRuntime
-isystem /usr/include/bsd -DLIBBSD_OVERLAY -g -O0 -o .libs/dispatch_apply
dispatch_apply.o  ./.libs/libbsdtests.a ../src/.libs/libdispatch.so -lbsd
-L/home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
-lswiftCore -lswiftSwiftOnoneSupport -lpthread -Wl,-rpath
-Wl,//usr/lib/swift/linux -Wl,-rpath
-Wl,/home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
/home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64/libswiftCore.so:
undefined reference to `objc_release'
clang-4.0: error: linker command failed with exit code 1 (use -v to see
invocation)
Makefile:1123: recipe for target 'dispatch_apply' failed
make: *** [dispatch_apply] Error 1
swift/utils/build-script: fatal error: command terminated with a non-zero
exit status 2, aborting

Looks like there is some undefined reference for objc_release in
libswiftCore.

>From the looks of the message it looks like swift was actually built but
it's just that test cases weren't built. On this hunch, I went into my
swift-corelibs-foundation folder and tried to execute:

ninja

Which tells me:

ninja: error: loading 'build.ninja': No such file or directory

Given my lack of experience here, I'm not quite sure how to go about
resolving these issues.

Could somebody help me out here please.

Thanks,

Mohit
___
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

[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: "cairo" version: "1.1.4", remote: "
git://anongit.freedesktop.org/git/cairo")

It would search for the cairo lib on local machine in /usr/lib and
/usr/local/lib , and if it can’t find it, or if the version doesn’t match,
it will then download the C sources from the Cairo project’s *official* git
repository and build it for you. Options could be added to specify
alternative search paths or user prompts.

On Wed, Mar 29, 2017 at 12:42 PM, Ankit Aggarwal 
wrote:

> 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 

Re: [swift-users] Set with element of NSObject subclasses didn't work as expected

[Hooman Mehr via swift-users]

> On Mar 29, 2017, at 11:36 AM, Joe Groff via swift-users 
>  wrote:
> 
> Perhaps the NSObject implementation of `hashValue` should be final to help 
> with this.


Good idea. And as I mentioned in my other reply, we need further emphasis and 
clarification in the documentation who are starting Apple development with 
Swift with no prior knowledge of ObjC/NSObject stuff.

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

Re: [swift-users] Set with element of NSObject subclasses didn't work as expected

[Joe Groff via swift-users]

> On Mar 28, 2017, at 12:50 PM, Zhao Xin via swift-users 
>  wrote:
> 
> Please see the code first.
> 
> import Foundation
> 
> class Foo:Hashable {
> let value:Int
> 
> public var hashValue: Int { return value }
> public static func ==(lhs: Foo, rhs: Foo) -> Bool {
> return lhs.value == rhs.value
> }
> 
> init(_ value:Int) {
> self.value = value
> }
> }
> 
> let fooSetA:Set = [Foo(8), Foo(9)]
> let fooSetB:Set = [Foo(9), Foo(10)]
> let fooResultC = fooSetA.intersection(fooSetB) // {{value 9}}
> let fooResultD = fooSetA.subtracting(fooSetB) // {{value 8}}
> 
> 
> class Bar:NSObject {
> let value:Int
> 
> override public var hashValue: Int { return value }
> public static func ==(lhs: Bar, rhs: Bar) -> Bool {
> return lhs.value == rhs.value
> }
> 
> init(_ value:Int) {
> self.value = value
> }
> }
> 
> let barSetA:Set = [Bar(8), Bar(9)]
> let barSetB:Set = [Bar(9), Bar(10)]
> let barResultC = barSetA.intersection(barSetB) // Set([])
> let barResultD = barSetA.subtracting(barSetB) // {{NSObject, value 9}, 
> {NSObject, value 8}}
> 
> 
> Behaviors of `func intersection(Set)` and `func 
> subtracting(Set)` were different between normal Swift class and 
> NSObject subclasses. I had thought they should be the same. It seemed that 
> Set relied on addresses of NSObject instances instead of their 
> hashValues. That made the Set useless.

This is a known issue—when you redeclare `static func ==` inside Bar, that does 
not override `NSObject.==`, and moreover *cannot*, since overriding 
`NSObject.==` requires an implementation that accepts two NSObjects. We ought 
to consider this an error, or at least a warning. NSObject conforms to 
Equatable on behalf of all its subclasses by implementing `==` in terms of 
`isEqual:` and `hashValue` in terms of `hash`. Even though you can override 
`hashValue` for Swift, it's probably still safer to override `hash` and 
`isEqual` in order to get common behavior between ObjC and Swift, since ObjC 
will not use Swift's conformances. Perhaps the NSObject implementation of 
`hashValue` should be final to help with this.

-Joe
___
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

[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 Linux 
(which doesn't have the Xcode IDE) to utilize the CLI, and it embeds nicely 
into Xcode build scripts as an interim step (and there's a long history of that 
with clang, llbuild, etc).

I wouldn't call libPackageManager a stable API (and I suspect the SwiftPM team 
wouldn't either), but it's the right structure to support future interactions 
and IDE support - Xcode or other projects that want to leverage it.

 - joe

> On Mar 27, 2017, at 2:10 PM, Jan Neumüller via swift-build-dev 
>  wrote:
> 
> Is it just me, or is Swift moving to much in a command line direction since 
> the open sourcing? I feel being left behind as an Xcode user...
> 
> Jan
> 
>> On 27 Mar 2017, at 22:59, Michael Ilseman via swift-users 
>>  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
>> 
>> ___
>> 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-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

[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, 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 <
> 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 <
>> 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 
>>> 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 

Re: [swift-users] Set with element of NSObject subclasses didn't work as expected

[Hooman Mehr via swift-users]

Yes, this is a serious shortcoming in the transition to Swift as the main 
application programming language for Apple platforms.

With the existing architecture (lack of stable Swift ABI) system frameworks and 
any binary distributed frameworks still have to be written in Objective-C. If 
you are already an experienced developer of Apple platforms, you already know 
the behavior and expectations of ObjC runtime and NSObject family. But new 
developers are coming to the platform everyday and now they are starting with 
Swift. This really needs to be better addressed as more people start developing 
for Apple platforms using Swift with no prior knowledge of ObjC runtime and 
NSObject.

I think the best way to draw some attention to this is by filing bug reports on 
lack of adequate documentation, at least.

Also, please note that if you want to define operators that act on class 
hierarchies, you should put all of the logic of the operator in a method and 
have the operator simply delegate to the method to preserve (some) 
polymorphism. Although infix operators can’t easily be fully polymorphic, given 
the lack of multiple (or at least dual) dispatch. The problematic part of 
getting Equatable right in this case is that any instance of a subclass by 
definition should work as an instance of its superclass and this can create 
bugs if you are not careful. `Equatable` protocol requires both sides of the 
equality test to have identical type for the mathematical definition of 
equality to hold. In practice, you may need to relax this in some situations, 
but you should be fully aware of what you are doing.

> On Mar 29, 2017, at 2:36 AM, Zhao Xin via swift-users  
> wrote:
> 
> Now I understand it. What I don't understand is why there is nowhere 
> metioning this. All docs are talking about Hashable, clearly that NSObject 
> didn't rely on it.
> 
> Zhaoxin
> 
> Get Outlook for iOS 
> From: Saagar Jha 
> Sent: Wednesday, March 29, 2017 11:47:51 AM
> To: Zhao Xin
> Cc: Swift Users List
> Subject: Re: [swift-users] Set with element of NSObject subclasses didn't 
> work as expected
>  
> NSObject’s hash (which Set uses) is done via ObjectIdentifier, which IIRC 
> uses something along the lines of the object's address. That’s why you’re 
> getting the behavior you’re seeing.
> 
> Saagar Jha
> 
>> On Mar 28, 2017, at 20:20, Zhao Xin via swift-users > > wrote:
>> 
>> Turns out that for `NSObject`, protocol `Equatable` wasn't used. Instead, it 
>> used `NSObjectProtocol.isEqual(_ object: Any?)`. Also, override `func 
>> isEqual(_ object: Any?) -> Bool` requires to override `var hash: Int { get 
>> }` as well.
>> 
>> I think this behavior should be mentioned in Swift docs or manual in `Set` 
>> section.
>> 
>> Below code works. 
>> 
>> class Bar:NSObject {
>> let value:Int
>> 
>> override public var hashValue: Int { return value }
>> public static func ==(lhs: Bar, rhs: Bar) -> Bool {
>> return lhs.value == rhs.value
>> }
>> // required by NSObjectProtocol
>> override func isEqual(_ object: Any?) -> Bool {
>> if let rhs = object as? Bar {
>> return self == rhs
>> }
>> return false
>> }
>> override var hash: Int { return self.hashValue }
>> 
>> init(_ value:Int) {
>> self.value = value
>> }
>> }
>> 
>> let barSetA:Set = [Bar(8), Bar(9)]
>> let barSetB:Set = [Bar(9), Bar(10)]
>> let barResultC = barSetA.intersection(barSetB) // {{NSObject, value 9}}
>> let barResultD = barSetA.subtracting(barSetB) // {{NSObject, value 8}}
>> 
>> Gladly I find it here 
>> .
>>  
>> 
>> Zhaoxin
>> 
>> 
>> 
>> On Wed, Mar 29, 2017 at 3:50 AM, Zhao Xin > > wrote:
>> Please see the code first.
>> 
>> import Foundation
>> 
>> class Foo:Hashable {
>> let value:Int
>> 
>> public var hashValue: Int { return value }
>> public static func ==(lhs: Foo, rhs: Foo) -> Bool {
>> return lhs.value == rhs.value
>> }
>> 
>> init(_ value:Int) {
>> self.value = value
>> }
>> }
>> 
>> let fooSetA:Set = [Foo(8), Foo(9)]
>> let fooSetB:Set = [Foo(9), Foo(10)]
>> let fooResultC = fooSetA.intersection(fooSetB) // {{value 9}}
>> let fooResultD = fooSetA.subtracting(fooSetB) // {{value 8}}
>> 
>> 
>> class Bar:NSObject {
>> let value:Int
>> 
>> override public var hashValue: Int { return value }
>> public static func ==(lhs: Bar, rhs: Bar) -> Bool {
>> return lhs.value == rhs.value
>> }
>> 
>> init(_ value:Int) {
>> self.value = value
>> }
>> }
>> 
>> let barSetA:Set = [Bar(8), Bar(9)]
>> let barSetB:Set = [Bar(9), Bar(10)]
>> let barResultC = barSetA.intersection(barSetB) // Set([])
>> let