[Review] SE-0038 Package Manager C Language Target Support

Hello Swift community,

A review of “Package Manager C Language Target Support” for the Swift Package Manager begins now and runs through Monday, February 22th. The proposal is available here:

  swift-evolution/0038-swiftpm-c-language-targets.md at master · apple/swift-evolution · GitHub

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to the Swift Package Manager?
  * Does this proposal fit well with the feel and direction of the Swift Package Manager?
  * If you have you used other package managers with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  swift-evolution/process.md at master · apple/swift-evolution · GitHub

Thank you,

  - Rick
    Review Manager

I haven't had time to read this yet but I do have a question. You mention
C++ here but that is explicitly not a Swift 3 feature, right? Is this just
part of the groundwork for C++ support?

···

On Tue, Feb 16, 2016 at 9:12 PM, Rick Ballard via swift-build-dev < swift-build-dev@swift.org> wrote:

Hello Swift community,

A review of “Package Manager C Language Target Support” for the Swift
Package Manager begins now and runs through Monday, February 22th. The
proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0038-swiftpm-c-language-targets.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

        https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:

        * What is your evaluation of the proposal?
        * Is the problem being addressed significant enough to warrant a
change to the Swift Package Manager?
        * Does this proposal fit well with the feel and direction of the
Swift Package Manager?
        * If you have you used other package managers with a similar
feature, how do you feel that this proposal compares to those?
        * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

More information about the Swift evolution process is available at

        https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

        - Rick
          Review Manager

_______________________________________________
swift-build-dev mailing list
swift-build-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-build-dev

Looks pretty good! My one comment is that I think there should be support for umbrella headers, which allow more control over include order within a module. Maybe it's not strictly necessary, but if someone wants to develop a package that can be used by modular and non-modular build environments, they probably also want a way to keep the behavior as close as possible.

Suggestion: "foo/foo.h" in the include/ folder for "foo" is treated as an umbrella header if present; overriding this requires writing your own module map.

Having the "include/" folder inside the "src/" folder seems weird to me, but I guess it's the most consistent thing for packages that omit the src/ folder altogether.

What if there's more than one folder in the include/ folder? How are modules constructed? I wouldn't want "llvm/" and "llvm-c/" to be put in one module.

Jordan

···

On Feb 16, 2016, at 18:12, Rick Ballard via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

A review of “Package Manager C Language Target Support” for the Swift Package Manager begins now and runs through Monday, February 22th. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0038-swiftpm-c-language-targets.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to the Swift Package Manager?
  * Does this proposal fit well with the feel and direction of the Swift Package Manager?
  * If you have you used other package managers with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

  - Rick
    Review Manager

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

Hi Rick:

Thanks for putting this proposal together - having the ability to build
and link to C dependencies is going to be a huge step forward and this
very much looks like a step in the right direction.

I know there's been some discussion about being able to invoke custom
build targets and/or link to local dependencies. I agree that we don't
want to pre-design the entire solution but iterate in the right direction
and get feedback as we go. One thing we can do is look at some of the
challenges and solutions from other languages.

If we look at Node.js/NPM, as the most used language package manager, it
highlights the high usage of native modules. Most native modules have a
dependency on "nan" which has >6.5M downloads a month and approaching 1000
dependent modules.

As an example, one of those dependents is "zmq" (30K+ downloads/month)
which provides Node.js bindings for ZeroMQ. This provides a Node.js
wrapper around the zeromq library (installable via homebrew, apt-get etc).
The NPM approach is that at install/build time, the binding.gyp file can
be configured to check for the presence of the library, and to add the
necessary include and link flags.

I know that supporting that kind of scenario is outside of the scope of
this proposal - is it however a direction we're headed to?

Thanks,

Chris

···

From: Rick Ballard via swift-build-dev <swift-build-dev@swift.org>
To: swift-evolution-announce@swift.org
Cc: swift-evolution <swift-evolution@swift.org>,
swift-build-dev@swift.org
Date: 17/02/2016 02:12
Subject: [swift-build-dev] [Review] SE-0038 Package Manager C
Language Target Support
Sent by: swift-build-dev-bounces@swift.org

Hello Swift community,

A review of “Package Manager C Language Target Support” for the Swift
Package Manager begins now and runs through Monday, February 22th. The
proposal is available here:

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

                 https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:

                 * What is your evaluation of the proposal?
                 * Is the problem being addressed significant enough to
warrant a change to the Swift Package Manager?
                 * Does this proposal fit well with the feel and direction
of the Swift Package Manager?
                 * If you have you used other package managers with a
similar feature, how do you feel that this proposal compares to those?
                 * How much effort did you put into your review? A glance,
a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

Thank you,

                 - Rick
                   Review Manager

_______________________________________________
swift-build-dev mailing list
swift-build-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-build-dev

Hi Rick:

Thanks for putting this proposal together - having the ability to build
and link to C dependencies is going to be a huge step forward and this
very much looks like a step in the right direction.

I know there's been some discussion about being able to invoke custom
build targets and/or link to local dependencies. I agree that we don't
want to pre-design the entire solution but iterate in the right direction
and get feedback as we go. One thing we can do is look at some of the
challenges and solutions from other languages.

If we look at Node.js/NPM, as the most used language package manager, it
highlights the high usage of native modules. Most native modules have a
dependency on "nan" which has >6.5M downloads a month and approaching 1000
dependent modules.

As an example, one of those dependents is "zmq" (30K+ downloads/month)
which provides Node.js bindings for ZeroMQ. This provides a Node.js
wrapper around the zeromq library (installable via homebrew, apt-get etc).
The NPM approach is that at install/build time, the binding.gyp file can
be configured to check for the presence of the library, and to add the
necessary include and link flags.

I know that supporting that kind of scenario is outside of the scope of
this proposal - is it however a direction we're headed to?

Thanks,

Chris

···

From: Rick Ballard via swift-build-dev <swift-build-dev@swift.org>
To: swift-evolution-announce@swift.org
Cc: swift-evolution <swift-evolution@swift.org>,
swift-build-dev@swift.org
Date: 17/02/2016 02:12
Subject: [swift-build-dev] [Review] SE-0038 Package Manager C
Language Target Support
Sent by: swift-build-dev-bounces@swift.org

Hello Swift community,

A review of “Package Manager C Language Target Support” for the Swift
Package Manager begins now and runs through Monday, February 22th. The
proposal is available here:

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

                 https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:

                 * What is your evaluation of the proposal?
                 * Is the problem being addressed significant enough to
warrant a change to the Swift Package Manager?
                 * Does this proposal fit well with the feel and direction
of the Swift Package Manager?
                 * If you have you used other package managers with a
similar feature, how do you feel that this proposal compares to those?
                 * How much effort did you put into your review? A glance,
a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

Thank you,

                 - Rick
                   Review Manager

_______________________________________________
swift-build-dev mailing list
swift-build-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-build-dev

Hi T.J.,

This proposal is not about mixed Swift-C++ code. It's about allowing a Swift package to depend on and build a pure C/C++ module.

I hope that clarifies,

  - Rick

···

On Feb 17, 2016, at 9:34 PM, T.J. Usiyan <griotspeak@gmail.com> wrote:

I haven't had time to read this yet but I do have a question. You mention C++ here but that is explicitly not a Swift 3 feature, right? Is this just part of the groundwork for C++ support?

On Tue, Feb 16, 2016 at 9:12 PM, Rick Ballard via swift-build-dev <swift-build-dev@swift.org <mailto:swift-build-dev@swift.org>> wrote:
Hello Swift community,

A review of “Package Manager C Language Target Support” for the Swift Package Manager begins now and runs through Monday, February 22th. The proposal is available here:

        https://github.com/apple/swift-evolution/blob/master/proposals/0038-swiftpm-c-language-targets.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

        https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

        * What is your evaluation of the proposal?
        * Is the problem being addressed significant enough to warrant a change to the Swift Package Manager?
        * Does this proposal fit well with the feel and direction of the Swift Package Manager?
        * If you have you used other package managers with a similar feature, how do you feel that this proposal compares to those?
        * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

        https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

        - Rick
          Review Manager

_______________________________________________
swift-build-dev mailing list
swift-build-dev@swift.org <mailto:swift-build-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-build-dev

Ah, you *did* state that explicitly in the proposal. Sorry. This is still
looks like a great addition.

TJ

···

On Thu, Feb 18, 2016 at 12:36 AM, Rick Ballard <rballard@apple.com> wrote:

Hi T.J.,

This proposal is not about mixed Swift-C++ code. It's about allowing a
Swift package to depend on and build a pure C/C++ module.

I hope that clarifies,

- Rick

On Feb 17, 2016, at 9:34 PM, T.J. Usiyan <griotspeak@gmail.com> wrote:

I haven't had time to read this yet but I do have a question. You mention
C++ here but that is explicitly not a Swift 3 feature, right? Is this just
part of the groundwork for C++ support?

On Tue, Feb 16, 2016 at 9:12 PM, Rick Ballard via swift-build-dev < > swift-build-dev@swift.org> wrote:

Hello Swift community,

A review of “Package Manager C Language Target Support” for the Swift
Package Manager begins now and runs through Monday, February 22th. The
proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0038-swiftpm-c-language-targets.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

        https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:

        * What is your evaluation of the proposal?
        * Is the problem being addressed significant enough to warrant a
change to the Swift Package Manager?
        * Does this proposal fit well with the feel and direction of the
Swift Package Manager?
        * If you have you used other package managers with a similar
feature, how do you feel that this proposal compares to those?
        * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

More information about the Swift evolution process is available at

        https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

        - Rick
          Review Manager

_______________________________________________
swift-build-dev mailing list
swift-build-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-build-dev

As an example, one of those dependents is "zmq" (30K+ downloads/month) which provides Node.js bindings for ZeroMQ. This provides a Node.js wrapper around the zeromq library (installable via homebrew, apt-get etc). The NPM approach is that at install/build time, the binding.gyp file can be configured to check for the presence of the library, and to add the necessary include and link flags.

System libraries are handled by our System Module Map Package system which is separate to this proposal.

C targets under this proposal cannot directly depend on system libraries (though they could depend on a system-library-module-map-package).

The module-map package situation is not great at this time, but we will shortly have another proposal that seeks to improve that, I suggest watching out for that proposal.

Hi Chris,

Hi Rick:

Thanks for putting this proposal together - having the ability to build
and link to C dependencies is going to be a huge step forward and this very
much looks like a step in the right direction.

I know there's been some discussion about being able to invoke custom
build targets and/or link to local dependencies. I agree that we don't want
to pre-design the entire solution but iterate in the right direction and
get feedback as we go. One thing we can do is look at some of the
challenges and solutions from other languages.

If we look at Node.js/NPM, as the most used language package manager, it
highlights the high usage of native modules. Most native modules have a
dependency on "nan" which has >6.5M downloads a month and approaching 1000
dependent modules.

As an example, one of those dependents is "zmq" (30K+ downloads/month)
which provides Node.js bindings for ZeroMQ. This provides a Node.js wrapper
around the zeromq library (installable via homebrew, apt-get etc). The NPM
approach is that at install/build time, the binding.gyp file can be
configured to check for the presence of the library, and to add the
necessary include and link flags.

I know that supporting that kind of scenario is outside of the scope of
this proposal - is it however a direction we're headed to?

We have three parallel features that all target this area, and I think that
eventually they will converge:

1. Our existing system module maps feature is designed to allow integrating
installed software with the package ecosystem. I am sure it will grow more
"conditional" features over time.

2. For projects which have a straightforward enough build process to be
fully described via our built in support (possibly using manifest override
features not yet designed), then I would like for them to be able to be
described as packages following this proposal (e.g., maybe there could be a
package which describes ZeroMQ that we could build it fully inside the
ecosystem).

3. There will be other projects outside that scope, but which we want to
also allow to participate in the ecosystem. For them, I suspect the best
solution is an alternate "adaptor" mechanism for integrating them into the
ecosystem. Some of my thoughts on that are in this thread:

https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160104/000154.html

- Daniel

···

On Thu, Feb 18, 2016 at 1:25 PM, Chris Bailey via swift-build-dev < swift-build-dev@swift.org> wrote:

Thanks,

Chris

From: Rick Ballard via swift-build-dev <swift-build-dev@swift.org>
To: swift-evolution-announce@swift.org
Cc: swift-evolution <swift-evolution@swift.org>,
swift-build-dev@swift.org
Date: 17/02/2016 02:12
Subject: [swift-build-dev] [Review] SE-0038 Package Manager C
Language Target Support
Sent by: swift-build-dev-bounces@swift.org
------------------------------

Hello Swift community,

A review of “Package Manager C Language Target Support” for the Swift
Package Manager begins now and runs through Monday, February 22th. The
proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0038-swiftpm-c-language-targets.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

                https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:

                * What is your evaluation of the proposal?
                * Is the problem being addressed significant enough to
warrant a change to the Swift Package Manager?
                * Does this proposal fit well with the feel and direction
of the Swift Package Manager?
                * If you have you used other package managers with a
similar feature, how do you feel that this proposal compares to those?
                * How much effort did you put into your review? A glance,
a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

                - Rick
                  Review Manager

_______________________________________________
swift-build-dev mailing list
swift-build-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-build-dev

_______________________________________________
swift-build-dev mailing list
swift-build-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-build-dev

Looks pretty good! My one comment is that I think there should be support for umbrella headers, which allow more control over include order within a module. Maybe it's not strictly necessary, but if someone wants to develop a package that can be used by modular and non-modular build environments, they probably also want a way to keep the behavior as close as possible.

I agree, I will amend the proposal to add this.

Suggestion: "foo/foo.h" in the include/ folder for "foo" is treated as an umbrella header if present; overriding this requires writing your own module map.

Agreed.

Having the "include/" folder inside the "src/" folder seems weird to me, but I guess it's the most consistent thing for packages that omit the src/ folder altogether.

Can you elaborate here? Is your concern packages that in traditional UNIX style would have looked something like ROOT/include ROOT/src, and that they are now ROOT/src/include?

I agree that is a little funny. I don't see a great alternative -- we could support ROOT/include and ROOT/src, but that feels odd since as soon as you added a subdirectory to ROOT/src we would start treating them as independent targets. It might be that single-target C packages are useful enough this is worth supporting, but I'm not sure it is worth complicating the conventions for.

What if there's more than one folder in the include/ folder? How are modules constructed? I wouldn't want "llvm/" and "llvm-c/" to be put in one module.

Good point, this is something I didn't fully work out. I see a couple options here:

1. The primary use for module maps is for C targets being used in Swift. Those targets are encouraged strongly to support the foo/include/foo/*.h convention. We could restrict ourselves to only generating module maps in those situations, and in other situations requiring the library author to provide them.

The use case for allowing arbitrary headers under include/ was intended more at legacy C targets, or very complicated targets, both of which it is maybe reasonable to write module maps by hand.

2. We could define a policy that automatically creates different module maps based on the immediate subdirectory structure of the include dir. So, for the LLVM example, we could synthesize one module map for each of llvm and llvm-c.

This seems like it would work pretty well in practice, but then raises other special case questions: those modules then need distinct module names, derived from the directory name presumably. That works fine, but what if you have headers in foo/include/*.h *and* foo/include/foo/*.h? We would have to disallow that, or merge those two groups of headers into one module map, another annoying special case.

My temptation is to start with #1 and refine if it appears useful. What do you think?

- Daniel

···

On Feb 18, 2016, at 1:26 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:

Jordan

On Feb 16, 2016, at 18:12, Rick Ballard via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

A review of “Package Manager C Language Target Support” for the Swift Package Manager begins now and runs through Monday, February 22th. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0038-swiftpm-c-language-targets.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to the Swift Package Manager?
  * Does this proposal fit well with the feel and direction of the Swift Package Manager?
  * If you have you used other package managers with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

  - Rick
    Review Manager

_______________________________________________
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

Oops, review period is over but I guess I should still respond.

Having the "include/" folder inside the "src/" folder seems weird to me, but I guess it's the most consistent thing for packages that omit the src/ folder altogether.

Can you elaborate here? Is your concern packages that in traditional UNIX style would have looked something like ROOT/include ROOT/src, and that they are now ROOT/src/include?

I agree that is a little funny. I don't see a great alternative -- we could support ROOT/include and ROOT/src, but that feels odd since as soon as you added a subdirectory to ROOT/src we would start treating them as independent targets. It might be that single-target C packages are useful enough this is worth supporting, but I'm not sure it is worth complicating the conventions for.

Yeah, that was the concern. I'd expect ROOT/src/include to be private headers and ROOT/include to be public headers. But I agree there's not much to do about it.

What if there's more than one folder in the include/ folder? How are modules constructed? I wouldn't want "llvm/" and "llvm-c/" to be put in one module.

Good point, this is something I didn't fully work out. I see a couple options here:

1. The primary use for module maps is for C targets being used in Swift. Those targets are encouraged strongly to support the foo/include/foo/*.h convention. We could restrict ourselves to only generating module maps in those situations, and in other situations requiring the library author to provide them.

The use case for allowing arbitrary headers under include/ was intended more at legacy C targets, or very complicated targets, both of which it is maybe reasonable to write module maps by hand.

2. We could define a policy that automatically creates different module maps based on the immediate subdirectory structure of the include dir. So, for the LLVM example, we could synthesize one module map for each of llvm and llvm-c.

This seems like it would work pretty well in practice, but then raises other special case questions: those modules then need distinct module names, derived from the directory name presumably. That works fine, but what if you have headers in foo/include/*.h *and* foo/include/foo/*.h? We would have to disallow that, or merge those two groups of headers into one module map, another annoying special case.

My temptation is to start with #1 and refine if it appears useful. What do you think?

I don't actually see how you can do #1 correctly if you were to install the package. (Then again, we don't know how to do top-level headers correctly either if you were to install the package, because we don't know how to add to the /usr/include module map.)

I think I'd just limit it to "we only generate a module map if you have exactly one subdirectory", and wait to see what feature requests come in, i.e. how people are actually structuring their modules.

Jordan

···

On Feb 19, 2016, at 8:27 , Daniel Dunbar <daniel_dunbar@apple.com> wrote:
On Feb 18, 2016, at 1:26 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Oops, review period is over but I guess I should still respond.

Having the "include/" folder inside the "src/" folder seems weird to me, but I guess it's the most consistent thing for packages that omit the src/ folder altogether.

Can you elaborate here? Is your concern packages that in traditional UNIX style would have looked something like ROOT/include ROOT/src, and that they are now ROOT/src/include?

I agree that is a little funny. I don't see a great alternative -- we could support ROOT/include and ROOT/src, but that feels odd since as soon as you added a subdirectory to ROOT/src we would start treating them as independent targets. It might be that single-target C packages are useful enough this is worth supporting, but I'm not sure it is worth complicating the conventions for.

Yeah, that was the concern. I'd expect ROOT/src/include to be private headers and ROOT/include to be public headers. But I agree there's not much to do about it.

What if there's more than one folder in the include/ folder? How are modules constructed? I wouldn't want "llvm/" and "llvm-c/" to be put in one module.

Good point, this is something I didn't fully work out. I see a couple options here:

1. The primary use for module maps is for C targets being used in Swift. Those targets are encouraged strongly to support the foo/include/foo/*.h convention. We could restrict ourselves to only generating module maps in those situations, and in other situations requiring the library author to provide them.

The use case for allowing arbitrary headers under include/ was intended more at legacy C targets, or very complicated targets, both of which it is maybe reasonable to write module maps by hand.

2. We could define a policy that automatically creates different module maps based on the immediate subdirectory structure of the include dir. So, for the LLVM example, we could synthesize one module map for each of llvm and llvm-c.

This seems like it would work pretty well in practice, but then raises other special case questions: those modules then need distinct module names, derived from the directory name presumably. That works fine, but what if you have headers in foo/include/*.h *and* foo/include/foo/*.h? We would have to disallow that, or merge those two groups of headers into one module map, another annoying special case.

My temptation is to start with #1 and refine if it appears useful. What do you think?

I don't actually see how you can do #1 correctly if you were to install the package. (Then again, we don't know how to do top-level headers correctly either if you were to install the package, because we don't know how to add to the /usr/include module map.)

I think I'd just limit it to "we only generate a module map if you have exactly one subdirectory", and wait to see what feature requests come in, i.e. how people are actually structuring their modules.

Agreed.

I've these changes in this PR:
  [SwiftPM/C Language Targets] Add a couple notes on module map synthesis. by ddunbar · Pull Request #173 · apple/swift-evolution · GitHub

- Daniel

···

On Feb 25, 2016, at 9:12 AM, Jordan Rose <jordan_rose@apple.com> wrote:

On Feb 19, 2016, at 8:27 , Daniel Dunbar <daniel_dunbar@apple.com <mailto:daniel_dunbar@apple.com>> wrote:
On Feb 18, 2016, at 1:26 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Jordan