<div dir="ltr"><div>Responses inline.</div><div dir="ltr"><br></div><div dir="ltr">On Mon, Dec 31, 2018 at 2:17 PM Ben Boeckel <<a href="mailto:ben.boeckel@kitware.com">ben.boeckel@kitware.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On Sun, Dec 30, 2018 at 13:09:23 -0800, Saleem Abdulrasool wrote:<br>
> I was looking at supporting Swift as a language in CMake. I know that<br>
> CMake has some preliminary support that assumes that you are building on<br>
> macOS with Xcode. I am trying to support building swift libraries and<br>
> executables on Linux and Windows.<br>
<br>
IIRC, the issue before was that the command line interface to swiftc was<br>
basically treated as a black box and not stable (i.e., whatever Xcode<br>
wanted drove the interface, backwards compat was not guaranteed). Is<br>
that different now?<br></blockquote><div><br></div><div>AFAIK, the driver interface is supposed to be stable. The frontend options are not, but, the same holds true for clang as well. The driver options are stable, and we (as the clang developer community) aim to not break that. However, the frontend flags are entirely in the purview of the compiler developers and those change as needed.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
> There is some preliminary work on this that I have put up on GitHub [1].<br>
> One place that I am hitting a roadblock in is the need to reference all the<br>
> target sources in the compile rule for a single object. AFAICT, there is<br>
> no placeholder that will expand to the target sources. Would it be<br>
> acceptable to add a `<TARGET_SOURCES>` place holder? Or is there another<br>
> approach that would be better?<br>
<br>
The problem with that is that per-source file properties cannot be<br>
applied (compile definitions, flags, etc.). I don't know whether or not<br>
this is important for Swift.<br></blockquote><div><br></div><div>I think that there is some confusion over what exactly I need. I am trying to do file at a time compilation, but, each compilation requires the full set of sources to be provided to the driver. This effectively boils down to:</div><div><br></div><div>swiftc -c -primary-file <SOURCE> -o <OBJECT> -emit-module-path <OBJECT>.swiftmodule -emit-module-doc-path <OBJECT>.swiftdoc <TARGET_SOURCES></div><div><br></div><div>This allows the compiler to look through the other sources which will be part of the module and perform semantic analysis across them if/when necessary.</div><div><br></div><div>Adding per file properties would still be possible, and, IMO, desired. That is part of the reason for doing the compilation in this mode rather than a single pass over the complete file set. That said, most of the options really should be at a module level.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Other questions which spring to mind:<br>
<br>
- Does it support making just the compile artifacts from the source<br>
files or does it always do the link step?<br></blockquote><div><br></div><div>The approach that I am taking does a separate compile and link step. This allows for a better behavior when it comes to incremental builds which I care about.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
- If the latter, how do mixed language libraries work?<br></blockquote><div><br></div><div>The latter is what I believe most people have done, partially due to lack of understanding of how the build model works with swift which is completely understandable given that it is relatively opaque and it has not been documented as thoroughly as C/C++.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
- Also, if linking is done by Swift, how would one add a manifest or<br>
.rc file on Windows (e.g., to get an application icon)?<br></blockquote><div><br></div><div>Well, you would still want to link using the swift driver, not the linker directly much like you use the driver to link C/C++. I believe the changes have also been back ported to the 5.0 release to pass options from the [swift] driver to the [clang] driver to have them be translated appropriately for the linker in use. But, the manifest and resource file handling is done by the linker IIRC, so this is largely unchanged beyond the need to pass along the right flags.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
The list of restrictions would need to be well-defined here first I<br>
think.<br></blockquote><div><br></div><div>I think that there aren't very many restrictions that come to mind. The biggest one is that it would be *extremely* helpful to have language specific properties that can be set, but, I really was hoping that there was a way to do this with a backwards compatible manner. It would be helpful to have a property to indicate things like the swift version and the module name.</div><div> </div><div>I'm happy to go into more detail, but, I'm really not sure I have an understanding of what things you may be thinking of as restrictions here.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
--Ben</blockquote></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org</div></div>