Hi! I’m unable to build on OS X 10.11
Using make:
../private/voucher_activity_private.h:493:10: fatal error: 'os/lock_private.h'
file not found
#include <os/lock_private.h>
^
Using Xcode:
/Users/dzianis/Documents/my_code/libs/swift-corelibs-libdispatch/private/voucher_activity_private.h:493:10: 'os/lock_private.h' file not found
PS On ubuntu 14.04 project is also generally unbuildable (despite title of commit:33b735c5330b5a97d029bccfff9a7d78ef1f214 ;)).
Hi,
Hi! I’m unable to build on OS X 10.11
Using make:
../private/voucher_activity_private.h:493:10: fatal error: 'os/lock_private.h'
file not found
#include <os/lock_private.h>
^Using Xcode:
/Users/dzianis/Documents/my_code/libs/swift-corelibs-libdispatch/private/voucher_activity_private.h:493:10: 'os/lock_private.h' file not found
Yes, this is known and we’re working on resolving that issue.
PS On ubuntu 14.04 project is also generally unbuildable (despite title of commit:33b735c5330b5a97d029bccfff9a7d78ef1f214 ;)).
The linux port is in progress, and even if it built, right now, it wouldn’t be functional.
-Pierre
On Dec 11, 2015, at 12:17 AM, f-dz-f via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
Hi,
Right now the Linux build is assuming you've installed some pre-req
packages. In particular,
sudo apt-get install libblocksruntime-dev libkqueue-dev
libpthread-workqueue-dev
I've been building on 15.10; haven't tried 14.04 recently. Maybe
try install the pre-reqs on 14.04 and see what happens?
I'll put together a quick check sheet with build pre-reqs and
instructions and submit a pull request to include it.
--dave
swift-corelibs-dev-bounces@swift.org wrote on 12/11/2015 03:17:47 AM: > From: f-dz-f via swift-corelibs-dev <swift-corelibs-dev@swift.org>
To: swift-corelibs-dev@swift.org
Date: 12/11/2015 03:18 AM
Subject: [swift-corelibs-dev] libdispatch build issue
Sent by: swift-corelibs-dev-bounces@swift.org
PS On ubuntu 14.04 project is also generally unbuildable (despite
title of commit:33b735c5330b5a97d029bccfff9a7d78ef1f214 ;)).
Actually, I’ve built library on 14.04 but it required some hack’s like adding dummy #define and calling libtool with different arguments after make failed with errors.
First try:
user$ sudo apt-get install libblocksruntime-dev libkqueue-dev libpthread-workqueue-dev
Reading package lists...
Building dependency tree...
Reading state information...
libblocksruntime-dev is already the newest version.
libkqueue-dev is already the newest version.
libpthread-workqueue-dev is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.
user$ git clone GitHub - apple/swift-corelibs-libdispatch: The libdispatch Project, (a.k.a. Grand Central Dispatch), for concurrency on multicore hardware && cd swift-corelibs-libdispatch
user$ sh autogen.sh
user$ ./configure --with-blocks-runtime
user$ make
queue.c:216:22: error: use of undeclared identifier 'WORKQ_BG_PRIOQUEUE'
.dgq_wq_priority = WORKQ_BG_PRIOQUEUE,
^
queue.c:227:22: error: use of undeclared identifier 'WORKQ_BG_PRIOQUEUE'
.dgq_wq_priority = WORKQ_BG_PRIOQUEUE,
^
queue.c:926:18: error: invalid application of 'sizeof' to an incomplete type 'struct dispatch_root_queue_context_s '
dispatch_assert(countof(_dispatch_root_queue_contexts) ==
~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
queue.c:926:18: error: invalid application of 'sizeof' to an incomplete type 'struct dispatch_root_queue_context_s '
dispatch_assert(countof(_dispatch_root_queue_contexts) ==
^
queue.c:926:18: error: invalid application of 'sizeof' to an incomplete type 'struct dispatch_root_queue_context_s '
dispatch_assert(countof(_dispatch_root_queue_contexts) ==
~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
queue.c:926:18: error: invalid application of 'sizeof' to an incomplete type 'struct dispatch_root_queue_context_s '
dispatch_assert(countof(_dispatch_root_queue_contexts) ==
^
5 warnings and 6 errors generated.
Second try (with manually defined WORKQ_BG_PRIOQUEUE macro ;)):
user$ make
/bin/bash ../libtool --tag=CXX --mode=link clang++ -g -O2 -avoid-version -o libdispatch.la -rpath /usr/local/lib allocator.lo apply.lo benchmark.lo data.lo introspection.lo init.lo io.lo object.lo once.lo queue.lo semaphore.lo source.lo time.lo transform.lo voucher.lo shims/linux_stubs.lo -lpthread -Lyes -lBlocksRuntime
../libtool: line 6000: cd: yes: No such file or directory
libtool: link: cannot determine absolute directory name of `yes'
make[2]: *** [libdispatch.la] Error 1
make[2]: Leaving directory `/home/user/code/libs/tmp/swift-corelibs-libdispatch/src'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/user/code/libs/tmp/swift-corelibs-libdispatch/src'
make: *** [all-recursive] Error 1
Third try (after running libtool without -Lyes option):
user$ make
bsdtests.c:28:10: fatal error: 'crt_externs.h' file not found
#include <crt_externs.h>
^
1 error generated.
Few… At least libdispatch was built ;)
11 дек. 2015 г., в 18:02, David P Grove via swift-corelibs-dev <swift-corelibs-dev@swift.org> написал(а):
swift-corelibs-dev-bounces@swift.org wrote on 12/11/2015 03:17:47 AM: > > > From: f-dz-f via swift-corelibs-dev <swift-corelibs-dev@swift.org>
> To: swift-corelibs-dev@swift.org
> Date: 12/11/2015 03:18 AM
> Subject: [swift-corelibs-dev] libdispatch build issue
> Sent by: swift-corelibs-dev-bounces@swift.org> PS On ubuntu 14.04 project is also generally unbuildable (despite
> title of commit:33b735c5330b5a97d029bccfff9a7d78ef1f214 ;)).Hi,
Right now the Linux build is assuming you've installed some pre-req packages. In particular,
sudo apt-get install libblocksruntime-dev libkqueue-dev libpthread-workqueue-dev
I've been building on 15.10; haven't tried 14.04 recently. Maybe try install the pre-reqs on 14.04 and see what happens?
I'll put together a quick check sheet with build pre-reqs and instructions and submit a pull request to include it.
--dave
_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
11 дек. 2015 г., в 18:36, Pierre Habouzit <phabouzit@apple.com> написал(а):
The linux port is in progress, and even if it built, right now, it wouldn’t be functional.
-Pierre
Yes. I completely understand that there linux port is not functional. So I want to contribute to it. But it's practically impossible since there is no usable build system :(.
That’s the point, porting starts with making it build ;)
-Pierre
On Dec 11, 2015, at 8:19 AM, Dzianis Fedarenka via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
11 дек. 2015 г., в 18:36, Pierre Habouzit <phabouzit@apple.com <mailto:phabouzit@apple.com>> написал(а):
The linux port is in progress, and even if it built, right now, it wouldn’t be functional.
-Pierre
Yes. I completely understand that there linux port is not functional. So I want to contribute to it. But it's practically impossible since there is no usable build system :(.
This is only tangentially related: but I was attempting to build dispatch as well to start work on CFRunLoop and a few other dispatch bound features in Foundation on linux. I was seeing similar failures as Dzianis Fedarenka. Is there a branch/fork that I can grab to test this stuff out w/ bringing stuff up in Foundation?
My question is that of design and status of where things are at; CFRunLoop requires a method to interoperate with the main dispatch queue via _dispatch_get_main_queue_port_4CF and _dispatch_main_queue_callback_4CF. CFRunLoop will need to transact upon the same event source type as dispatch to ensure the main queue behaves correctly - so what type of event source should we be using? A socket? A producer/consumer notification via pthread conditions?
On Dec 11, 2015, at 8:27 AM, David P Grove via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
swift-corelibs-dev-bounces@swift.org wrote on 12/11/2015 11:19:15 AM:
>
> The linux port is in progress, and even if it built, right now, it
> wouldn’t be functional.
>
> -Pierre
>
> Yes. I completely understand that there linux port is not
> functional. So I want to contribute to it. But it's practically
> impossible since there is no usable build system :(.It's limping along. We've managed to run a few programs successfully.
I think the next step is actually to get the test suite to compile & build so we can see what functionally isn't working yet.
Pierre and Daniel, we could use some guidance on how to approach this. The tests have quite a few unguarded includes of mach header files, uses of mach types, and includes of Foundation. How would you like this porting to proceed? Hubertus has already done some initial poking at it, but getting direction on the intended outcome would be very helpful.
thanks,
--dave
_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
This is only tangentially related: but I was attempting to build dispatch as well to start work on CFRunLoop and a few other dispatch bound features in Foundation on linux. I was seeing similar failures as Dzianis Fedarenka. Is there a branch/fork that I can grab to test this stuff out w/ bringing stuff up in Foundation?
My question is that of design and status of where things are at; CFRunLoop requires a method to interoperate with the main dispatch queue via _dispatch_get_main_queue_port_4CF and _dispatch_main_queue_callback_4CF. CFRunLoop will need to transact upon the same event source type as dispatch to ensure the main queue behaves correctly - so what type of event source should we be using? A socket? A producer/consumer notification via pthread conditions?
The linux equivalent to what we’re doing for the runloop is to use an eventfd() to replace sending messages to its port.
On Dec 11, 2015, at 9:02 AM, Philippe Hausler via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
On Dec 11, 2015, at 8:27 AM, David P Grove via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
swift-corelibs-dev-bounces@swift.org <mailto:swift-corelibs-dev-bounces@swift.org> wrote on 12/11/2015 11:19:15 AM:
>
> The linux port is in progress, and even if it built, right now, it
> wouldn’t be functional.
>
> -Pierre
>
> Yes. I completely understand that there linux port is not
> functional. So I want to contribute to it. But it's practically
> impossible since there is no usable build system :(.It's limping along. We've managed to run a few programs successfully.
I think the next step is actually to get the test suite to compile & build so we can see what functionally isn't working yet.
Pierre and Daniel, we could use some guidance on how to approach this. The tests have quite a few unguarded includes of mach header files, uses of mach types, and includes of Foundation. How would you like this porting to proceed? Hubertus has already done some initial poking at it, but getting direction on the intended outcome would be very helpful.
thanks,
--dave
_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
We do have an internal test-suite that we can’t share because it rely on internal Apple infrastructure. I haven’t closed the loop with Daniel completely on this but our position I think is that these should be made portable even if that means dropping anything mach related stuff by hiding it behind a if __APPLE__ or similar.
-Pierre
On Dec 11, 2015, at 8:27 AM, David P Grove via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
swift-corelibs-dev-bounces@swift.org wrote on 12/11/2015 11:19:15 AM:
>
> The linux port is in progress, and even if it built, right now, it
> wouldn’t be functional.
>
> -Pierre
>
> Yes. I completely understand that there linux port is not
> functional. So I want to contribute to it. But it's practically
> impossible since there is no usable build system :(.It's limping along. We've managed to run a few programs successfully.
I think the next step is actually to get the test suite to compile & build so we can see what functionally isn't working yet.
Pierre and Daniel, we could use some guidance on how to approach this. The tests have quite a few unguarded includes of mach header files, uses of mach types, and includes of Foundation. How would you like this porting to proceed? Hubertus has already done some initial poking at it, but getting direction on the intended outcome would be very helpful.
Though the runloop code should be disabled on linux right now, as it’s highly dependent on mach ports, and we should discuss whether having a dispatch queue attached to the runloop makes sense for the non mach version, and if it does, should it have exactly the same queue_runloop implementation as today. I think not, and the simplest way to port the implementation is to have a different implementation for linux completely and not rely on the weird 4CF hooks that we have on OS X.
-Pierre
On Dec 11, 2015, at 9:57 AM, Pierre Habouzit via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
On Dec 11, 2015, at 9:02 AM, Philippe Hausler via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
This is only tangentially related: but I was attempting to build dispatch as well to start work on CFRunLoop and a few other dispatch bound features in Foundation on linux. I was seeing similar failures as Dzianis Fedarenka. Is there a branch/fork that I can grab to test this stuff out w/ bringing stuff up in Foundation?
My question is that of design and status of where things are at; CFRunLoop requires a method to interoperate with the main dispatch queue via _dispatch_get_main_queue_port_4CF and _dispatch_main_queue_callback_4CF. CFRunLoop will need to transact upon the same event source type as dispatch to ensure the main queue behaves correctly - so what type of event source should we be using? A socket? A producer/consumer notification via pthread conditions?
The linux equivalent to what we’re doing for the runloop is to use an eventfd() to replace sending messages to its port.
It's limping along. We've managed to run a few programs successfully.
I think the next step is actually to get the test suite to compile & build
so we can see what functionally isn't working yet.
Pierre and Daniel, we could use some guidance on how to approach this. The
tests have quite a few unguarded includes of mach header files, uses of
mach types, and includes of Foundation. How would you like this porting to
proceed? Hubertus has already done some initial poking at it, but getting
direction on the intended outcome would be very helpful.
thanks,
--dave
swift-corelibs-dev-bounces@swift.org wrote on 12/11/2015 11:19:15 AM:
The linux port is in progress, and even if it built, right now, it
wouldn’t be functional.-Pierre
Yes. I completely understand that there linux port is not
functional. So I want to contribute to it. But it's practically
impossible since there is no usable build system :(.
We already have a Windows implementation in there that uses HANDLE, so we are not completely dependent on mach ports.
I think it’s critical for portability that we maintain the concept of dispatch_main and CFRunLoop main thread integration. The exact mechanism is something we can design, but we have a fairly proven pattern here that would be straightforward to port.
- Tony
On Dec 11, 2015, at 11:25 AM, Pierre Habouzit via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
On Dec 11, 2015, at 9:57 AM, Pierre Habouzit via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
On Dec 11, 2015, at 9:02 AM, Philippe Hausler via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
This is only tangentially related: but I was attempting to build dispatch as well to start work on CFRunLoop and a few other dispatch bound features in Foundation on linux. I was seeing similar failures as Dzianis Fedarenka. Is there a branch/fork that I can grab to test this stuff out w/ bringing stuff up in Foundation?
My question is that of design and status of where things are at; CFRunLoop requires a method to interoperate with the main dispatch queue via _dispatch_get_main_queue_port_4CF and _dispatch_main_queue_callback_4CF. CFRunLoop will need to transact upon the same event source type as dispatch to ensure the main queue behaves correctly - so what type of event source should we be using? A socket? A producer/consumer notification via pthread conditions?
The linux equivalent to what we’re doing for the runloop is to use an eventfd() to replace sending messages to its port.
Though the runloop code should be disabled on linux right now, as it’s highly dependent on mach ports, and we should discuss whether having a dispatch queue attached to the runloop makes sense for the non mach version, and if it does, should it have exactly the same queue_runloop implementation as today. I think not, and the simplest way to port the implementation is to have a different implementation for linux completely and not rely on the weird 4CF hooks that we have on OS X.
-Pierre
I was talking about the *dispatch* run loop code. I'm not sure it's needed. The main queue is a different story.
-Pierre on his iPhone
On 11 déc. 2015, at 11:28, Tony Parker via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
On Dec 11, 2015, at 11:25 AM, Pierre Habouzit via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
On Dec 11, 2015, at 9:57 AM, Pierre Habouzit via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
On Dec 11, 2015, at 9:02 AM, Philippe Hausler via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
This is only tangentially related: but I was attempting to build dispatch as well to start work on CFRunLoop and a few other dispatch bound features in Foundation on linux. I was seeing similar failures as Dzianis Fedarenka. Is there a branch/fork that I can grab to test this stuff out w/ bringing stuff up in Foundation?
My question is that of design and status of where things are at; CFRunLoop requires a method to interoperate with the main dispatch queue via _dispatch_get_main_queue_port_4CF and _dispatch_main_queue_callback_4CF. CFRunLoop will need to transact upon the same event source type as dispatch to ensure the main queue behaves correctly - so what type of event source should we be using? A socket? A producer/consumer notification via pthread conditions?
The linux equivalent to what we’re doing for the runloop is to use an eventfd() to replace sending messages to its port.
Though the runloop code should be disabled on linux right now, as it’s highly dependent on mach ports, and we should discuss whether having a dispatch queue attached to the runloop makes sense for the non mach version, and if it does, should it have exactly the same queue_runloop implementation as today. I think not, and the simplest way to port the implementation is to have a different implementation for linux completely and not rely on the weird 4CF hooks that we have on OS X.
-Pierre
We already have a Windows implementation in there that uses HANDLE, so we are not completely dependent on mach ports.
I think it’s critical for portability that we maintain the concept of dispatch_main and CFRunLoop main thread integration. The exact mechanism is something we can design, but we have a fairly proven pattern here that would be straightforward to port.
- Tony
_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
dispatch as well to start work on CFRunLoop and a few other dispatch
bound features in Foundation on linux. I was seeing similar failures
as Dzianis Fedarenka. Is there a branch/fork that I can grab to test
this stuff out w/ bringing stuff up in Foundation?
If you grab the master branch it should build libdispatch.so on ubuntu
15.04.
I've put a quick cheat sheet in a pull request:
There's a patch from Hubertus to get timers at least partially working that
you may want too:
My question is that of design and status of where things are at;
CFRunLoop requires a method to interoperate with the main dispatch
queue via _dispatch_get_main_queue_port_4CF and
_dispatch_main_queue_callback_4CF. CFRunLoop will need to transact
upon the same event source type as dispatch to ensure the main queue
behaves correctly - so what type of event source should we be using?
A socket? A producer/consumer notification via pthread conditions?
Sorry, I don't understand the code well enough yet to answer this
one :( I'm sure Pierre or Daniel can.
--dave
phausler@apple.com wrote on 12/11/2015 12:02:30 PM: > This is only tangentially related: but I was attempting to build
Thanks Pierre.
We made a little progress on getting tests to compile this afternoon:
https://github.com/dgrove-oss/swift-corelibs-libdispatch/tree/fixtests
Absolutely not ready for a pull request, but mentioning it in case anyone
else was starting on the same task and wanted to collaborate.
--dave
From: Pierre Habouzit <phabouzit@apple.com>
To: David P Grove/Watson/IBM@IBMUS
Cc: Dzianis Fedarenka <f.dz.v.gh@gmail.com>,
swift-corelibs-dev@swift.org
Date: 12/11/2015 12:59 PM
Subject: Re: [swift-corelibs-dev] libdispatch build issue
Sent by: phabouzit@apple.com
On Dec 11, 2015, at 8:27 AM, David P Grove via swift-corelibs-dev < swift-corelibs-dev@swift.org> wrote:
swift-corelibs-dev-bounces@swift.org wrote on 12/11/2015 11:19:15 AM:
>
> The linux port is in progress, and even if it built, right now, it
> wouldn’t be functional.
>
> -Pierre
>
> Yes. I completely understand that there linux port is not
> functional. So I want to contribute to it. But it's practically
> impossible since there is no usable build system :(.
It's limping along. We've managed to run a few programs
successfully.
I think the next step is actually to get the test suite to compile &
build so we can see what functionally isn't working yet.
Pierre and Daniel, we could use some guidance on how to approach
this. The tests have quite a few unguarded includes of mach header
files, uses of mach types, and includes of Foundation. How would you
like this porting to proceed? Hubertus has already done some initial
poking at it, but getting direction on the intended outcome would be
very helpful.
We do have an internal test-suite that we can’t share because it rely on
internal Apple infrastructure. I haven’t closed the loop with Daniel
completely on this but our position I think is that these should be made
portable even if that means dropping anything mach related stuff by hiding
it behind a #if __APPLE__ or similar.
-Pierre
Cool, I’ll have a look later this week or when it gets more ready ;)
btw, we got a pull request that seem good to me (https://github.com/apple/swift-corelibs-libdispatch/pull/13\) but I don’t have the linux setup to check it’s good, would you mind review it, I’ve not seen anything wrong with it from the dispatch or from what I remember from autotools best practices from my debian developer past.
-Pierre
On Dec 11, 2015, at 3:03 PM, David P Grove via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
Thanks Pierre.
We made a little progress on getting tests to compile this afternoon: https://github.com/dgrove-oss/swift-corelibs-libdispatch/tree/fixtests
Absolutely not ready for a pull request, but mentioning it in case anyone else was starting on the same task and wanted to collaborate.
--dave
<graycol.gif>Pierre Habouzit ---12/11/2015 12:59:51 PM---> On Dec 11, 2015, at 8:27 AM, David P Grove via swift-corelibs-dev <swift-corelibs-dev@swift.org> w
From: Pierre Habouzit <phabouzit@apple.com>
To: David P Grove/Watson/IBM@IBMUS
Cc: Dzianis Fedarenka <f.dz.v.gh@gmail.com>, swift-corelibs-dev@swift.org
Date: 12/11/2015 12:59 PM
Subject: Re: [swift-corelibs-dev] libdispatch build issue
Sent by: phabouzit@apple.comOn Dec 11, 2015, at 8:27 AM, David P Grove via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
swift-corelibs-dev-bounces@swift.org <mailto:swift-corelibs-dev-bounces@swift.org> wrote on 12/11/2015 11:19:15 AM:
>
> The linux port is in progress, and even if it built, right now, it
> wouldn’t be functional.
>
> -Pierre
>
> Yes. I completely understand that there linux port is not
> functional. So I want to contribute to it. But it's practically
> impossible since there is no usable build system :(.It's limping along. We've managed to run a few programs successfully.
I think the next step is actually to get the test suite to compile & build so we can see what functionally isn't working yet.
Pierre and Daniel, we could use some guidance on how to approach this. The tests have quite a few unguarded includes of mach header files, uses of mach types, and includes of Foundation. How would you like this porting to proceed? Hubertus has already done some initial poking at it, but getting direction on the intended outcome would be very helpful.
We do have an internal test-suite that we can’t share because it rely on internal Apple infrastructure. I haven’t closed the loop with Daniel completely on this but our position I think is that these should be made portable even if that means dropping anything mach related stuff by hiding it behind a if __APPLE__ or similar.
-Pierre
_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
-Pierre
Cool, I’ll have a look later this week or when it gets more ready ;)
btw, we got a pull request that seem good to me (https://github.com/apple/swift-corelibs-libdispatch/pull/13\) but I don’t have the linux setup to check it’s good, would you mind review it, I’ve not seen anything wrong with it from the dispatch or from what I remember from autotools best practices from my debian developer past.
wow that sentence makes no sense. I meant I see nothing wrong from the dispatch *perspective*. works better with all words ;)
On Dec 14, 2015, at 9:18 AM, Pierre Habouzit via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:
-Pierre
On Dec 11, 2015, at 3:03 PM, David P Grove via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
Thanks Pierre.
We made a little progress on getting tests to compile this afternoon: https://github.com/dgrove-oss/swift-corelibs-libdispatch/tree/fixtests
Absolutely not ready for a pull request, but mentioning it in case anyone else was starting on the same task and wanted to collaborate.
--dave
<graycol.gif>Pierre Habouzit ---12/11/2015 12:59:51 PM---> On Dec 11, 2015, at 8:27 AM, David P Grove via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> w
From: Pierre Habouzit <phabouzit@apple.com <mailto:phabouzit@apple.com>>
To: David P Grove/Watson/IBM@IBMUS
Cc: Dzianis Fedarenka <f.dz.v.gh@gmail.com <mailto:f.dz.v.gh@gmail.com>>, swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
Date: 12/11/2015 12:59 PM
Subject: Re: [swift-corelibs-dev] libdispatch build issue
Sent by: phabouzit@apple.com <mailto:phabouzit@apple.com>On Dec 11, 2015, at 8:27 AM, David P Grove via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
swift-corelibs-dev-bounces@swift.org <mailto:swift-corelibs-dev-bounces@swift.org> wrote on 12/11/2015 11:19:15 AM:
>
> The linux port is in progress, and even if it built, right now, it
> wouldn’t be functional.
>
> -Pierre
>
> Yes. I completely understand that there linux port is not
> functional. So I want to contribute to it. But it's practically
> impossible since there is no usable build system :(.It's limping along. We've managed to run a few programs successfully.
I think the next step is actually to get the test suite to compile & build so we can see what functionally isn't working yet.
Pierre and Daniel, we could use some guidance on how to approach this. The tests have quite a few unguarded includes of mach header files, uses of mach types, and includes of Foundation. How would you like this porting to proceed? Hubertus has already done some initial poking at it, but getting direction on the intended outcome would be very helpful.
We do have an internal test-suite that we can’t share because it rely on internal Apple infrastructure. I haven’t closed the loop with Daniel completely on this but our position I think is that these should be made portable even if that means dropping anything mach related stuff by hiding it behind a if __APPLE__ or similar.
-Pierre
_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev