Extra compiler/linker options in Package.swift

[OutOfBedlam]

Add otherCompilerOptions and otherLinkerOptions in Package for Package.swift

[Danappelxx]

Worth noting that there was some previous discussion over at #73 and SR-145.

[mxcl]

Thanks, this is something that maybe we need. However, please provide a usecase that justifies this so we can discuss the ramifications.

[Danappelxx]

@mxcl Take a look at SR-145 SR-15 SR-83, which I believe are related (there are probably more). Also, I emailed you about this describing my situation in depth a few days ago as well.

[mxcl]

Thanks, for these issues we'd like to solve this with modifications to how module map packages work.

I will be writing up a proposal for this hopefully today.

We are not opposed to supporting arbitrary command line options but we want to avoid it as long as possible, supporting such things offers power and flexibility to developers they may need, but it also causes build problems that can be difficult to fix for end-users who don't understand the packages they are consuming that well.

[TomasLinhart]

@mxcl How is different at the end? If we specify header path in modules, it will still cause problems if something is missing and it will be hard to consume it anyway.

I understand your rationale but I am not sure how module maps can improve it. Plus changing the way how module maps work require changes in Clang if I am not mistaken.

Anyway looking forward to your proposal.

[mxcl]

1. Passing arbitrary commands does not allow us any control or mitigation. Specifying paths in the module map allows us to control how and where these paths are input to the toolchain.
2. Allowing packages to specify any flags they like allows more control than we think is sensible. While we respect the fact sometimes it is frustrating when you have less control we have learned from the mistakes of previous build-systems and packaging systems and would like to be restrictive in order to prevent exotic and hard-to-fix dependency hell scenarios.

[OutOfBedlam]

@mxcl I agree that module.modulemap is the right place to define all required headers and libraries for the specific module, this should be done by the module.

Even though module.modulemap will bring this ability and eliminate needs to specify -I <header_path> in Package.swift, it is still good to have a way passing options to underlying build system.

This is the use case that I consider about this 'other compiler/linker options'. (of course this case might be just for system module developers, not for all users)
While I write module.modulemap of some library for my tiny project as POC, it is really annoying that I should commit/tag whenever it is modified/tested. so, I took advantage of my PR changes of Package.swift like below...

import PackageDescription

let LIB_ROOT = "<place of my development version of lib instead of OS lib path>"
let SRC_ROOT = "<place of my project>"

let cflags = [
    "-I\(LIB_ROOT)/include",
    "-I\(SRC_ROOT)/ModuleMaps",
    "-F-module-map=\(SRC_ROOT)/ModuleMaps/CZeroMQ/module.modulemap",
]

let lflags = [
    "-L\(LIB_ROOT)/lib",
    "-lzmq",
   "-lczmq",
]

let package = Package(
    name:"Hello",
    // dependencies: [
    //  .Package(url:"../CZeroMQ", majorVersion:1),
    // ],
    otherCompilerOptions:cflags,
    otherLinkerOptions:lflags
)

Of course I could separate system module when it is ready for release, but while module.modulemap is not yet concreted, it is really useful that I can specify module.modulemap file with -F-module-map. This is not proper way for end user but the point is it can help system developer not to commit/tag every time he/she edit/test the file.

Since SPM produces llbuild.yaml as final output for low level build system, I hope SPM could have enough flexibility.

[mxcl]

I think there is value in discussing the possibility of this feature for terminus-packages (ie. root-packages, the package swift-build builds but not for any packages it fetches). My main concern is avoiding dependency hell scenarios. My secondary concern is preventing packages at any part of the graph from demanding build settings that are fragile.

Build toolchains are fundamentally fragile. One only has to browse the comments and ratings for popular IDEs to appreciate that. We strongly desire to reduce fragility.

We can solve your motivating problem: that it is tedious to tag packages you are developing, and have intention to do so with some concept of "dev packages".

[ddunbar]

It is worth noting that the existing of arbitrary search paths is exactly one thing which makes good module support very difficult (because modules from the Clang perspective are intimately intertwined with header search paths, and allowing any project to contribute them is a recipe for disaster). One of our goals in trying to maintain tight control over the dependencies is to try and deliver a much more reliable experience in the long run...

[OutOfBedlam]

@mxcl @ddunbar Thanks for clarifying SPM's direction. It is helpful to understand it.
Look forward modulemap to solve the issue.