Re: [swift-evolution] [swift-build-dev] [swiftpm] Add proposal for C language support

[Daniel Dunbar via swift-evolution]

> On Jan 3, 2016, at 6:34 AM, Maury Markowitz via swift-evolution 
>  wrote:
> 
>> On Jan 2, 2016, at 9:00 AM, Daniel Dunbar via swift-build-dev 
>>  wrote:
>> 
>> Happy 2016!
>> 
>> I am working on an initial proposal for adding support for C language 
>> targets to the Swift package manager, and am interested in feedback:
> 
> The idea of including C libraries/code in Swift projects *without* having to 
> use Xcode strikes me as *very* valuable. Two questions:
> 
> a) for item (2) in "solution" I see the advantages of placing the bridging in 
> a separate directory, but I want to point out that this may make the 
> interactions between various devenvs and things like GitHub more annoying. 
> Xcode's Bridging-Header solution has it's own problems, but may be easier to 
> work with in complex projects. Generally I think more flexibility here might 
> be valuable, even going so far as a ".bh" for the bridging files, allowing 
> them to be placed anywhere.

We anticipate directly adding support for targets with both C and Swift code, 
at some point (which is where the bridging header comes in), but that is more 
involved and something I wanted to explicitly tackle separately. This proposal 
is very focused at adding support for building C source code that is a part of 
the project, and exposing the headers that declare the interfaces to that code. 
It is not really intended to tackle the problem of using C headers to expose 
*other* code.

> b) for (3), I'm facing this problem right now porting some very old C that 
> has a main.c that includes main() as well as other more general code that the 
> rest of the system uses. I solved this by changing main(), but that's not 
> ideal, I would greatly prefer to use the original code verbatim. So for the 
> 10% of cases where this is a problem, perhaps a compiler directive would be 
> useful?

If you are integrating the code directly into your project I feel like it makes 
more sense to require some adaption in order to keep the conventions simple. 
There are likely a large number of adaptions necessary to integrate existing C 
projects into these conventions, over time I expect we will allow customization 
for common problems (and ones that are easy to define a syntax for 
customizing), but I'm not sure if this one would bubble up to that level of 
importance.

 - Daniel

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

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

Re: [swift-evolution] [swift-build-dev] [swiftpm] Add proposal for C language support

[Maury Markowitz via swift-evolution]

> On Jan 2, 2016, at 9:00 AM, Daniel Dunbar via swift-build-dev 
>  wrote:
> 
> Happy 2016!
> 
> I am working on an initial proposal for adding support for C language targets 
> to the Swift package manager, and am interested in feedback:

The idea of including C libraries/code in Swift projects *without* having to 
use Xcode strikes me as *very* valuable. Two questions:

a) for item (2) in "solution" I see the advantages of placing the bridging in a 
separate directory, but I want to point out that this may make the interactions 
between various devenvs and things like GitHub more annoying. Xcode's 
Bridging-Header solution has it's own problems, but may be easier to work with 
in complex projects. Generally I think more flexibility here might be valuable, 
even going so far as a ".bh" for the bridging files, allowing them to be placed 
anywhere.

b) for (3), I'm facing this problem right now porting some very old C that has 
a main.c that includes main() as well as other more general code that the rest 
of the system uses. I solved this by changing main(), but that's not ideal, I 
would greatly prefer to use the original code verbatim. So for the 10% of cases 
where this is a problem, perhaps a compiler directive would be useful?


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

Re: [swift-evolution] [swift-build-dev] [swiftpm] Add proposal for C language support

[David Owens II via swift-evolution]

Seems like a good start for Swift developers that need to write some C code for 
their project. 

-David

Sent from my iPhone

> On Jan 2, 2016, at 9:00 AM, Daniel Dunbar via swift-build-dev 
>  wrote:
> 
> Happy 2016!
> 
> I am working on an initial proposal for adding support for C language targets 
> to the Swift package manager, and am interested in feedback:
>  
> https://github.com/ddunbar/swift-evolution/blob/master/proposals/-swiftpm-c-language-targets.md
> 
> Some TL;DR:
> - The proposal defines a basic convention for pure C language targets (no 
> Swift/C mix and match, but other Swift targets can use the C targets).
> - This is just intended to be the minimal initial feature, there will be a 
> lot of add on work which I expect should be tackled in follow on 
> PRs/proposals.
> - The proposal doesn't try and outline every single nitty detail (e.g., 
> exactly what C++ standard we will compile with). My intention is to pick a 
> sensible default at implementation time and refine incrementally.
> 
> Unless there are serious objections, I am hoping to hope to land this 
> proposal soon and start work on the feature shortly after.
> 
> Cheers,
> - Daniel
> 
> 
> ___
> swift-build-dev mailing list
> swift-build-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-build-dev
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-build-dev] [swiftpm] Add proposal for C language support

[Drew Crawford via swift-evolution]

Thanks for directing me to this, I missed it.

> Most projects will not conform to these conventions.

Giggle.  Kind of an understatement, no?

Like, okay.  Here is a project I'd like to package.  (Read: I do package it, 
with features not in mainline swiftPM.)  https://github.com/jedisct1/libsodium 


Let's take a look at how this package realistically builds:

* It has tests ("make check")
* It has various --enable-foo flags
* It swaps in special implementations depending on if you have AMD64 

 or AVX instructions 

 or SSE2 

 etc.
* The optimization level is tuned on a per-architecture basis 

* They build (also) on Windows.  They're not changing how they're packaged for 
"SwiftPM, the Mac/Linux build system".
* Oh and this is cryptography code.  Do you *really* want to touch it?

I think an important feature of any C target proposal is that there will 
actually exist C targets which can be built under the proposal.  Until there 
are C people coming out of the woodwork saying "sure, I will repackage my 
software this way" I think the entire value is debatable.

Getting signoff from libdispatch/CoreFoundation is necessary but not sufficient 
to clear that hurdle.  I would think getting the other C deps in our own 
project family to repackage would be "table stakes" for any new C build system. 
 The real test are projects that are third-party and less friendly.

And I do not see realistically how we are ever going to support a project like 
libsodium, except calling out to automake.  An automake solution coincidentally 
supports both libdispatch and CoreFoundation right now.  IMO something like 
that is a much, much better direction in the short-term, and once we have done 
the first step of "packaging" those software via automake we will have "real" C 
projects in our package manager and we can design our C support around the 
concerns of real projects instead of imaginary ones.

> On Jan 2, 2016, at 11:00 AM, Daniel Dunbar via swift-build-dev 
>  wrote:
> 
> Happy 2016!
> 
> I am working on an initial proposal for adding support for C language targets 
> to the Swift package manager, and am interested in feedback:
>  
> https://github.com/ddunbar/swift-evolution/blob/master/proposals/-swiftpm-c-language-targets.md
> 
> Some TL;DR:
> - The proposal defines a basic convention for pure C language targets (no 
> Swift/C mix and match, but other Swift targets can use the C targets).
> - This is just intended to be the minimal initial feature, there will be a 
> lot of add on work which I expect should be tackled in follow on 
> PRs/proposals.
> - The proposal doesn't try and outline every single nitty detail (e.g., 
> exactly what C++ standard we will compile with). My intention is to pick a 
> sensible default at implementation time and refine incrementally.
> 
> Unless there are serious objections, I am hoping to hope to land this 
> proposal soon and start work on the feature shortly after.
> 
> Cheers,
> - Daniel
> 
> 
> ___
> swift-build-dev mailing list
> swift-build-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-build-dev

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

Re: [swift-evolution] [swift-build-dev] [swiftpm] Add proposal for C language support

[Félix Cloutier via swift-evolution]

This sounds interesting. I don't have time to read it right now but I like the 
idea and I'll give better feedback later.

Félix

> Le 2 janv. 2016 à 12:28:10, Kostiantyn Koval via swift-evolution 
>  a écrit :
> 
> Hi, Happy 2016. 
> 
> The proposal looks great as for me. Very nice starting point to add C family 
> support
> 
> Best Regards,
> Kostiantyn
> 
>> On 02 Jan 2016, at 18:00, Daniel Dunbar via swift-build-dev 
>>  wrote:
>> 
>> Happy 2016!
>> 
>> I am working on an initial proposal for adding support for C language 
>> targets to the Swift package manager, and am interested in feedback:
>> https://github.com/ddunbar/swift-evolution/blob/master/proposals/-swiftpm-c-language-targets.md
>> 
>> Some TL;DR:
>> - The proposal defines a basic convention for pure C language targets (no 
>> Swift/C mix and match, but other Swift targets can use the C targets).
>> - This is just intended to be the minimal initial feature, there will be a 
>> lot of add on work which I expect should be tackled in follow on 
>> PRs/proposals.
>> - The proposal doesn't try and outline every single nitty detail (e.g., 
>> exactly what C++ standard we will compile with). My intention is to pick a 
>> sensible default at implementation time and refine incrementally.
>> 
>> Unless there are serious objections, I am hoping to hope to land this 
>> proposal soon and start work on the feature shortly after.
>> 
>> Cheers,
>> - Daniel
>> 
>> 
>> ___
>> swift-build-dev mailing list
>> swift-build-...@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-build-dev
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [swift-build-dev] [swiftpm] Add proposal for C language support

[Kostiantyn Koval via swift-evolution]

Hi, Happy 2016. 

The proposal looks great as for me. Very nice starting point to add C family 
support

Best Regards,
Kostiantyn

> On 02 Jan 2016, at 18:00, Daniel Dunbar via swift-build-dev 
>  wrote:
> 
> Happy 2016!
> 
> I am working on an initial proposal for adding support for C language targets 
> to the Swift package manager, and am interested in feedback:
>  
> https://github.com/ddunbar/swift-evolution/blob/master/proposals/-swiftpm-c-language-targets.md
> 
> Some TL;DR:
> - The proposal defines a basic convention for pure C language targets (no 
> Swift/C mix and match, but other Swift targets can use the C targets).
> - This is just intended to be the minimal initial feature, there will be a 
> lot of add on work which I expect should be tackled in follow on 
> PRs/proposals.
> - The proposal doesn't try and outline every single nitty detail (e.g., 
> exactly what C++ standard we will compile with). My intention is to pick a 
> sensible default at implementation time and refine incrementally.
> 
> Unless there are serious objections, I am hoping to hope to land this 
> proposal soon and start work on the feature shortly after.
> 
> Cheers,
> - Daniel
> 
> 
> ___
> swift-build-dev mailing list
> swift-build-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-build-dev

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