I’m wrapping three little native C libraries using SPM to a nice swifty modules. Say cmod1, cmod2, and cmod3. They all in the and are dependencies of a bigger project.
Since these legacy C libraries have headers in various ways incompatible with SPM I’m also providing my own custom module.modulemap inside of Sources/cmod1/include folder which exports only certain headers.
The module.modulemap is in pretty standard form with relative path to the header
module cmod1 {
header “cmod1/header1.h”
export “*”
link “cmod1"
}
When using ``swift build`` to build the module, C sources compile fine but switc bails out when parsing modulemap because it can not find headers referenced from header1.h with an error message like this
<module-includes>:1:10: note: in file included from <module-includes>:1: #include “/projects/something/Sources/cmod1/include/cmod/header1.h"
^
/projects/something/Sources/cmod1/include/cmod1/header1.h:18:10: error: ‘cmod1/header2.h' file not found
Now I know that I can give swiftc correct -Xswiftc -Ipath switch and then it builds cleanly, but this means that plain ``swift build`` never succeeds…
Q1: Is my assumption correct that the ultimate goal of mine is to make the swift package build cleanly using just ``swift build`` without providing any commandline flags?
Q2: When build of a certain package cmod1 requires command line flags -Xcc -Xlinker and -Xswiftc, what’s the correct way to pass them in when such package is a dependency of bigger project and which gets git pulled and compiled as part of outer package build?
thanks for your time, unfortunately the sources of these packages can not be made public yet but I think I can generate a simple broken project on github if anyone wants to take a look...
I’m wrapping three little native C libraries using SPM to a nice swifty modules. Say cmod1, cmod2, and cmod3. They all in the and are dependencies of a bigger project.
Since these legacy C libraries have headers in various ways incompatible with SPM I’m also providing my own custom module.modulemap inside of Sources/cmod1/include folder which exports only certain headers.
The module.modulemap is in pretty standard form with relative path to the header
module cmod1 {
header “cmod1/header1.h”
export “*”
link “cmod1"
}
When using ``swift build`` to build the module, C sources compile fine but switc bails out when parsing modulemap because it can not find headers referenced from header1.h with an error message like this
<module-includes>:1:10: note: in file included from <module-includes>:1: #include “/projects/something/Sources/cmod1/include/cmod/header1.h"
Is this misspelled? cmod/header1.h vs cmod1/header1.h?
Can you show the exact include style used in the module.modulemap and in the project?
^
/projects/something/Sources/cmod1/include/cmod1/header1.h:18:10: error: ‘cmod1/header2.h' file not found
Now I know that I can give swiftc correct -Xswiftc -Ipath switch and then it builds cleanly, but this means that plain ``swift build`` never succeeds…
Q1: Is my assumption correct that the ultimate goal of mine is to make the swift package build cleanly using just ``swift build`` without providing any commandline flags?
Yes.
Q2: When build of a certain package cmod1 requires command line flags -Xcc -Xlinker and -Xswiftc, what’s the correct way to pass them in when such package is a dependency of bigger project and which gets git pulled and compiled as part of outer package build?
We don't have a solution for this yet, eventually we want to find a way that all that data has a proper home in the manifest.
- Daniel
···
On Oct 20, 2016, at 7:25 AM, Martin Man via swift-users <swift-users@swift.org> wrote:
thanks for your time, unfortunately the sources of these packages can not be made public yet but I think I can generate a simple broken project on github if anyone wants to take a look...
``git clone`` and ``swift build`` it and you will see the problem I’m talking about…
please let me know if you need any help, I’ll prepare a more complex project showing the problem with this module being used as a dependency of another more complex module soon…
thanks,
Martin
···
On 20 Oct 2016, at 17:34, Daniel Dunbar <daniel_dunbar@apple.com> wrote:
On Oct 20, 2016, at 7:25 AM, Martin Man via swift-users <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
Hi guys,
I’m wrapping three little native C libraries using SPM to a nice swifty modules. Say cmod1, cmod2, and cmod3. They all in the and are dependencies of a bigger project.
Since these legacy C libraries have headers in various ways incompatible with SPM I’m also providing my own custom module.modulemap inside of Sources/cmod1/include folder which exports only certain headers.
The module.modulemap is in pretty standard form with relative path to the header
module cmod1 {
header “cmod1/header1.h”
export “*”
link “cmod1"
}
When using ``swift build`` to build the module, C sources compile fine but switc bails out when parsing modulemap because it can not find headers referenced from header1.h with an error message like this
<module-includes>:1:10: note: in file included from <module-includes>:1: #include “/projects/something/Sources/cmod1/include/cmod/header1.h"
Is this misspelled? cmod/header1.h vs cmod1/header1.h?
Can you show the exact include style used in the module.modulemap and in the project?
^
/projects/something/Sources/cmod1/include/cmod1/header1.h:18:10: error: ‘cmod1/header2.h' file not found
Now I know that I can give swiftc correct -Xswiftc -Ipath switch and then it builds cleanly, but this means that plain ``swift build`` never succeeds…
Q1: Is my assumption correct that the ultimate goal of mine is to make the swift package build cleanly using just ``swift build`` without providing any commandline flags?
Yes.
Q2: When build of a certain package cmod1 requires command line flags -Xcc -Xlinker and -Xswiftc, what’s the correct way to pass them in when such package is a dependency of bigger project and which gets git pulled and compiled as part of outer package build?
We don't have a solution for this yet, eventually we want to find a way that all that data has a proper home in the manifest.
- Daniel
thanks for your time, unfortunately the sources of these packages can not be made public yet but I think I can generate a simple broken project on github if anyone wants to take a look...