> On Jan 3, 2016, at 6:34 AM, Maury Markowitz via swift-evolution 
> <swift-evolution@swift.org> wrote:
>> On Jan 2, 2016, at 9:00 AM, Daniel Dunbar via swift-build-dev 
>> <swift-build-...@swift.org> 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 

 - Daniel

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

swift-evolution mailing list

Reply via email to